Table of Contents

Treating your code like a construction site

When attending RailsConf Europe we had a discussion about how construction workers tend to put up temporary solutions when they're working. In Oslo, there are a couple of long running construction projects where I've seen that they construct temporary roads only to tear them down after a month or two. This way the traffic can keep running almost smoothly while big changes are introduced in the area.

This made me think maybe we as programmers should do the same: construct temporary structures to keep things working while we're working on a feature.

Now, this may sound like extra work with very little gain. However, in order to be able to always deliver a product, I don't see any way of avoiding it. Imagine you're working on the rewrite of a feature which you should be able to deliver in two weeks. With a decent source control management system your first impulse would be to create a branch and then release this as soon as it's ready. Which could work just fine. You're able to work with your new feature, even share it with others, and then merge it once you're done.

However, what you just did was to buy yourself time before you let your customers use your new feature. In many cases I find that I develop a new feature that should eventually be used in three or four different parts of the application. By keeping this feature to myself, not integrating it, I prolong the time it takes before a real customer is able to reap benefits from it. So the last couple of days, while working on a major rewrite of a very central part of my current project I decided to introduce the feature in one out of five main parts of the application. I chose the least used of the five parts, in able to minimize the potential damage introduced, still being able to gain real-life experiences with the code.

In order to achieve this, I had to put up some temporary constructions in the code, maintaining two different pieces of code. This has the potential of forcing me to implement other features twice, you might argue. However, this is a lie; I'd have to do this anyway, in order to keep up with the changes in the main branch/trunk of the project. The extra work introduced lies in the temporary constructions I have to make. The cost is gaining feedback earlier.

I'd say it's worth it. Would you?