Jenga Methods

Jenga has its time and place. It makes a great drinking game; we’ve played it (dry) at a recent Company Mandated Funtime day outside the office. I’ve played a brilliant variant involving improvised storytelling and poetry (better than it sounds).

But it’s a rubbish game to play in conjunction with computer programming.

The fun of Jenga is the anticipation. It’s going to end in disaster (especially the drinking variant, natch). With each turn we hope our brick will balance perfectly, and that another player’s will not. There’s some skill involved, but ultimately it’s about waiting for someone to make a mess of it. Then follows laughing, pointing, and occasional appearances of that “Loser” hand-on-forehead thing (depending on company).

Working with old, legacy code brings with it the spectre of Jenga Methods. This concept has been around in the programming community for literally hours (at time of writing), and we came across one such Jenga Method during our Bugs Postmortem session this morning.

The method is old, long, and complicated. It’s also vital. It’s responsible for displaying almost all of our images, in dozens of key customer-facing parts of our software. It’s called many times a second and without it our application wouldn’t function.

This weight of expectation is felt by every developer who has touched it over the past ten years. It’s grown more complicated, full of comments and convoluted logic paths. Each developer has made the minimum changes to fix the problem, then held their breath, waiting for the wooden blocks to fall.

A logic path contained an error that was uncovered in our last sprint. The developer fixing the problem fixed the error, but didn’t touch the rest of the method – a Jenga player touches one brick at a time.

This isn’t great in the short term, and it’s terrible in the long term. The method needs refactoring, rewriting and redesigning. This is a difficult task that’s always made easier with a comprehensive suite of unit tests, covering all the expected functionality in all circumstances.

You can probably see where I’m going here – we don’t have that suite. The method isn’t covered. Just typing that sentence makes me nervous. Why not? There’s some complications, of course. The method deals with rendering images, although that’s not the killer – the objects are such that we could pass in dummy images and render them to a dummy context.

Rather, the unit test framework just doesn’t exist for that part of the software. It’s something we just “haven’t got round to”.

So … no happy ending, not yet. The best we can do is accelerate our unit test coverage; add the mechanisms for unit testing this bit of code; and add tasks to our feature tracking system to make sure we refactor this code when we can feel confident to do so.

Today, it’s just one more brick on top of the tower. Careful, now.


About north5

Software developer, larper, father.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s