Software is like Tetris

Posted on

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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s