Tetris and software development

Being a developer is like playing Tetris: Your accomplishments disappear and all of your mistakes build up until you fix them.

— Evan tedesco (@EvanTedesco) December 16, 2014

Ever since hearing Evan say this, Tetris has been stuck in my mind. It isn’t that I long to get a game in, but rather the analogy is lodged in there. It is just so easy to riff on, and it comes up as you go through your day.

When you are having a great day you are in the zone and the flow state
kicks in allowing time to slow down, and the pieces that you need seem to be coming at you. Doesn’t that feel fantastic? The flip side is an incoming shit storm, with pelting requests and a list of work to get done that is more than you can ever get too. You blink and the day is done seemingly moments after it began.

Tying this to software

Tetris is a very simplistic closed system. To play the game well we need to understand the system. What are the rules? What does the board look like? Don’t rush, or be lazy. The small mistakes add up, but also know that you can focus and clean them up. There is much that we can do to package up abstractions and have a clear view of what is happening, preparing for what is coming next.

As software engineers we can hack this system to our advantage in a way that we can’t do as game players. Our game thus becomes meta.

How can we hack the game to our advantage?

Isolate mistakes

You are having a clean game and then you make one silly mistake. Man it makes you mad. A lot of work has to be done to fix that mistake, and the debt needs to be paid. How can you use abstractions in your software to isolate various sections so mistakes can’t get out of hand? What if you could create multiple surfaces where the abstractions aren’t leaky? Take a flesh wound vs. a fatal one, giving you time to clean it up and move on.

Creating new pieces

The rules get you pattern matching the small number of pieces that could come your way. The constraints mean that you quickly learn certain tactics, but what if you could create more pieces that fit in nicely? If you can create any piece the game becomes boring, but in reality that isn’t a huge concern as the pieces are very complex and you don’t fully know how they all fit together.

Morphing pieces

Having new pieces is important, but being able to morph pieces after the fact would be even better. This would allow you to make more mistakes and give you the ability to change the past.

Reset

Sometimes the board is just too messy, and you need to know when it is time for the nuclear option to reset the board. This is an expensive option as it often speeds up the clock while the business waits for value to be created as the debt is collected.

A very common mistake made is to reset, thinking it is the “easy option” vs. doing the work to refactor your way out. A pre-requisite to this move is understanding Second System Syndrome before you implement it.

Immutable state

The strong push for immutable deployable containers has huge advantages. I remember cheering when one of our Linux servers had an uptime long enough that it went around the clock. These days, this is a bug not a feature. The longer a system is running like that the greater the chance that things have been mucked around and a cancer has been created. It is far better to clean up the system regularly as that enables stability.

We often long to be stable, thinking that this means standing still. However, nothing is stable. The environment is always changing, so it is actually far better to give in to that and to instead embrace it.

Homeostasis

I now try to think in terms of homeostasis. Dave Thomas does a fantastic job of talking about this in relation to agility and how you have your hand on a rudder making changes. The best pilots are making many frequent tiny changes to keep a small oscillation around the direction you are looking to grow.

When you set the thermostat at 68 degrees the temperature is never set there. The best thermostat will make subtle changes to the air flow to keep it as stable as possible versus having a system go off and on with large bursts that cause large fluctuations.

Build the habits to deal with the constant change and then trust in your systems, just as you trust your body when you run. You probably aren’t thinking “arrrrr I am fallllllling!” at each step, but that is what is happening.

My mission is to create architectures that allow me to make small changes to get to a better path over time. Now and then we evolve something new that allows and requires a reset, but sometimes the evolution is subtle enough that you can’t see it as it happens.

Now, back to the Tetris game of live and getting Zen enough to deal with the blocks that keep falling!