Every shortcut pulls a block

2 min read

I bought a giant Jenga set for the office once, just as a game. At some point we added a rule: if you fixed a bug without writing a test, you had to pull a block. People laughed when it was their turn, and everyone else would come over to watch it wobble.

When something breaks in production, the only goal is to make it stop. Someone patches it so it quits crashing, the ticket gets closed, and everyone moves on. The plan is to come back the next day or the next cycle, find the real cause, and write the test. But there’s always more work, and once the urgent thing is handled, something else urgent or important takes its place. So the real problem stays in there, and the next person to touch that code has no idea.

I’ve run into versions of this everywhere I’ve worked. Alerts fire too often, so someone raises the threshold. The server keeps running out of memory, so someone pays for a bigger one instead of finding out why. After a while nobody knows which fixes are protecting against something real, and people get nervous about removing any of them.

I don’t remember exactly how the tower ended. I think it got knocked over a few times, at least once by someone cleaning, and we’d just stack it back up and keep going. As silly as it was, it worked. People got in the habit of writing tests, and seeing the tower lean reminded everyone what happens when you keep skipping them. If I did it again, I’d let people put a block back when they went back and wrote the test they skipped. And if they went the extra mile and cleaned up the tests around it, or made that part of the code easier to test, they’d get to glue a block in place.

Today you can have an agent write the test along with the fix in the same PR, or have something run afterward that looks for fixes that went out without one.

I also built a digital version if you want to try pulling some blocks.