Jenga Programming

I’m coining a new programming discipline, called Jenga Programming, or Jenga Driven Design (JDD). It’s something I see happening all the time, and it’s driving me crazy now and then.

For those of you who don’t know what Jenga is:

Jenga is a game of physical and mental skill, marketed by Hasbro, in which players remove blocks from a tower and put them on top. The word jenga is derived from kujenga, the Swahili verb "to build"; jenga! is the imperative form. (http://en.wikipedia.org/wiki/Jenga)

Basically what you do is you start with a solid tower, and keep removing parts and adding them to the top of the tower until it falls over. It’s a simple game, and quite fun to play. In programming however, this is arguably one of the best ways to create a maintenance nightmare.

At a glance, JDD looks promising. You start with a big solid block of code, and simply start removing the bits that are not needed to keep it standing. After that, you’re adding new things to the top. Sounds like iterative development and refactoring to me. If it was that simple, I wouldn’t have come up with this theory.

So what do I mean with JDD? We’ll dive a bit deeper into Jenga for that.

When you play Jenga, you remove blocks by gut feeling. When you’re removing a block you’re free to bump around the other blocks, or leave a block half removed if you think it will topple the tower. After you removed the block, usually you simply put it on the top in such a way that the tower won’t fall over. The only thing that matters when putting the block on the top is making sure the rest of the tower doesn’t come crashing down.

Superimposing this view of the game on ‘the game of software development’ will make it painfully clear where this goes wrong:

When you’re doing proper refactoring you (ideally) make sure that the code is covered by well-written tests, and that the functionality of the code is known. This is not the case when doing JDD: you remove bits which you think do nothing useful.

When you add new functionality to your application you make sure you know why you’re adding the specific functionality, and that it written well. When playing the JDD game, you add functionality whenever someone asks for it (adding a multitude of meaningless options/settings, anyone?). You don’t really care about the rest of the system, as long as it works.

Of course, JDD doesn’t work so well in compiled languages like Java, C or C#. When you remove something that’s still used, your compiler will cry out in pain, and you won’t be able to deploy the application into the wild. That’s why JDD is a typical (anti)pattern seen in PHP (and other script languages) development. Now, I’m not saying PHP is bad (well, not in this blog at least), but it does tend to let programmers do things like this. I blame it on the programmer though.

To summarize, JDD is programming without a solid plan, adding and removing things without a lot of thought. This is not to be confused with agile/extreme programming methods, where there IS a lot of thought going on.  So next time you encounter an application which falls over after a simple change, there’s only one thing to say:

 

JENGA!