Recently at work I've been revisiting a project and some framework code that I originally architected a couple of years ago, but which had subsequently been managed and added to by other groups of developers.  As I go through the code, I see what (in my opinion) used to be fairly simple and maintainable solutions now covered with warts, monstrosities, and tangled webs of complexity.

This isn't a new thing.  I've seen this pattern before with other codebases and other teams.  But today, it hit me.

Software Development is like Tetris.

It often starts out great!  You put a straight line here, a square there, couple of Ls back to back and padow you've scored a line.  You start to feel you're on a roll.  You're pulling the pieces down instead of waiting for them to drop.  Square, square, straight line, L, straight line...Tetris!

But over time, the pieces (new requirements) start falling faster due to your early success.  It gets harder to manage the pace, especially when you keep getting zig-zags or the wrong L shape.  Where you were anticipating and planning before, now you're just reacting. Things get put somewhere where you think they'll cause the least damage.  As you let these mistakes fester, you still manage to score some lines, but they are becoming fewer and farther between as your base of blocks (codebase) gets larger and larger.  Eventually it can get to the point where you've got too many misplaced blocks to manage and the whole thing spirals out of control.

So what can we learn from Tetris with respect to software development?

Fix Mistakes Quickly

Don't let the let code base keep growing on top of a mistake while you hope for that 1 long straight piece that will give you a Tetris and fix everything.  That piece ain't comin'.  Refactor every chance you get.  Review code frequently so that you can catch mistakes more quickly.

Control The Pace

Don't pull a piece down before you're sure where you're going with it (this is where I always get myself in trouble).  Set reasonable expectations.  Don't overcommit.  Factor in time to fix earlier mistakes.

Limit The Number Of Controllers

Managing the pieces is tough enough for a single player.  But at least in this case, a single player knows where the holes are.  He knows that he had to put a zig-zag over here on the right because he had no choice, and so he covers it with an L, knowing that eventually he may be able to turn that into a line and he's back in business.  Start adding in more players with control of the pieces though and things start getting tougher.  Especially if some players aren't aware of where the earlier problems were.

In the case of multiple players, I think it's best to have a single person or group of people responsible for "piece placement" or architectural type decisions.  The more people that are making these decisions independently, the more likely you are to get incongruent pieces.

That's all I can come up with for now.  But if you've got any others let me know.

Drop it like it's hot

Out.