Gameplay
It might be a while since you played Tetris. Let's brush up on the basics.
The playing field
Your playing field comes preset with an irreducible stack. This is the inherent complexity of the problem space you're operating within. Think of the laws of physics that dictate the interactions of your system, the compliance rules that your system must respect.
The height of the matrix is your team's capacity to manage complexity. There is only so much context a team can truly understand and own. Your goal is to keep your system complexity - the height of the stack - as low as possible to maximize your headroom.
We've got an incoming!
New features and change requests roll in. The timeline is set and you must find the right spot, the most appropriate way to incorporate them.
Your ability to move the incoming block and rotate it to fit in the stack dictates how well you can play the game.
You can only control what you understand. Your knowledge of the domain, the product and the motivation for the change allows you to reformulate it and reveal new options for where it could go.
You don't decide the blocks but you can move them around. The cadence of change is not in your hands, but communication and negotiation with stakeholders: product managers, designers, and customers, can move the block in the right direction.
Mistakes pile up
Incomplete assumptions and project cadence may not allow you to place every change exactly where you want, or where you thought it would fit. Small misjudgments accumulate: You have even less time to place new features and you can feel the system is more complex than it should be.
Game over
The panic spiral
The system has grown so complex you can barely match the cadence of change. Additive bias is running the show. Every feature added makes the next one harder to place.
What the end looks like
Your team's ability to reason about the system has collapsed. Bugs are a regular occurrence, and they're hard to track down. Simple features are a few weeks late and no one knows why. This is how many software projects slowly die.
The art of not losing
In software, we have superpowers that a Tetris player would kill for.
We can incrementally rearrange our stack to create opportunities for simplifications. Refactoring gives you some extra headroom to play the next round with more calm.
Not only that, but with the right system understanding, and a clear product road map, we can see further in the future than the game would allow. Your decisions today are much less likely to leave gaps in the stack.
How to play better
No such thing as winning, you can only avoid losing.
Software engineering, like Tetris, is a game you cannot win. Avoiding defeat for as long as your system is used is what you should aim for.
Keep your controls sharp
Controls are the only way you can exercise agency in the game. Understanding the problem space, the product and the requirements allows you to negotiate, reformulate and find the best spot for every change.
Use the cheat codes
Mistakes are bound to happen. Bad moves pile up fast. Whenever you have some headroom, or whenever the cadence of change slows down, take the time to shift the stack and clear as many lines as you can.
Be curious, dig deep into the system, understand the domain and the business landscape. Keep an open line with the people defining the specs. The more context you have, the better you can see into the future.
The more you wait, the worse it gets
Even at a comfortable cadence, with little headroom, you can only make mistakes. Don't wait until the panic starts.
Just one round
I don't know about you, but all this talk of Tetris made me want to play.
You can play a modern Tetris game or go for a nostalgic game-boy version.
Top comments (0)