Latest Event Updates
In the ongoing quest to helpfully frame the dos, don’ts and whys of software engineering to management, every so often we come up with illuminating analogies that do wonders to illustrate why a software team should or should not follow a particular strategy. One very successful one is technical debt (coined by Cunningham and later helpfully expanded on by Steve McConnell). Although they can be misused, analogies generally help us to communicate to non-techies with more clarity. Having pondered on the life of my current 2yr+ project, I’ve come up with another (albeit flippant and high-level) analogy: Software is like Tetris.
A software project, with specific focus on providing ongoing value to the business as the product evolves towards feature plateau, is like a game of tetris but with one alteration: The blocks fall quicker as they stacker higher. What I mean is that the closer you are to conducting zero-overhead iteration after zero-overhead iteration, the more time (read: less pressure) you have to solve problems: engage in root cause analysis, attack process bottlenecks, conduct code reviews, lower technical debt, and several other things that don’t directly add business value but that are obviously invaluable. The converse to all this is what I experienced on the project I’m on now, but with previous management: As deadlines tighten on features having been promised to the business by overexhuberant non-techie managers, those same managers demand that nothing else be done except the implementation of the feature, the quick-and-dirty hacking in of which slows down implementation of future features. Developers are forced into increasing their estimates because implementing features into a messy codebase takes more time and carries higher risk, and managers think the wool is being pulled over their eyes. Trust ebbs away, entropy sets into the codebase, the business get unstable software, morale is sinking and your tetris blocks are piling up fast and falling quicker.
So it seems like the focus should not be on delivering a piece of software. The focus should be building a team of engineers supported by managers, testers, business domain specialists as well as the right tools and a comfortable working environment to create an entity that can sustain the delivery of features with quality and predictability. Peaks and troughs of feature quantity and quality should be rare and small tweaks and improvements should be made to aid the gradual increase of quality and quantity. Effort should be on keeping overhead low and your features should tick away like lines of blocks in a well-running Tetris game.
I have just finished reading Scott Berkun’s Myths of Innovation. It is a really good investigation of what innovative thinking is, how to better yourself at it and crucially, what kind of environmental factors play a critical role in enabling more of it. Scott begins by busting several myths that expose the insight and years of dedicated grafting (not to mention considerable luck) that an inventor needs to be able to arrive at that much vaunted “Eureka Moment” when a new idea is born.
Once Scott has straightened out the facts and illustrated that innovation isn’t neccessarily the domain of the ridiculously clever or impossibly fortunate, he gives concisely distilled advice on who should and how to encourage, foster, cultivate innovation in the work place. Issues such as the “political shield” management should create and low cost of experimentation receive much needed attention.
This is one of those rare titles that crystallizes into fact those suspicions we’ve had for ages, but haven’t begun to act on or formalize because they’ve heretofore only been suspicions. The sooner you evolve your workplace environment towards increasingly innovative processes and practices, the sooner you will increase the quality of your output – start with this book!
Here is a google techtalk with Scott talking about the book (1 hour 10 mins long).