It's important who's driving

I’m a firm believer that software rots unless you’re very careful; and like apples, once one piece starts to go bad the rest quickly follows. The Pragmatic Programmers talk about Software Entropy and The Broken Window Theory and, unfortunately, this week the refactoring project showed how true this is…

We’ve spent several weeks working on cleaning up this project, but there’s a lot of code and it’s all in a bit of a state. Things are getting better, we have tests, we have a repeatable build and the code is slowly being beaten into something that will be maintainable. But the rot continues.

Now that we have our source control working properly we can safely let developers work on a branch and develop new functionality without worrying about them breaking other developer’s work, or affecting regular releases or bug fixes, etc. Sounds good, but of course the time comes to integrate this new work back into the main branch… Since the other developers aren’t that comfortable using branches and don’t see the point I offered to help with the merge - mainly so that I could make sure that it was done properly…

The interesting thing about doing a merge is seeing what’s been changed. What I found interesting was how the quality of the new code closely resembled the quality of the old code in the area where the changes had been made. Where changes were made in recently refactored code that was now in good shape the new code was nice and clean; where the changes were in parts of the code that were still a mess the changes were, well, in keeping with the existing style…

This wasn’t just a misguided application of the old “make changes in the style of the original code” mantra; it was a quality thing. Where the surrounding code was nicely factored into small functions that did one thing and were named sensibly the changes had been applied in such a way that the new code was also nicely factored, changes were put into their own functions and called appropriately. Yet where a change had to be made to a 300 line function the change was just hacked into the middle of the function.

Where the code was good the developer would keep it good but where it was bad he wouldn’t attempt to improve it. In fact, he’d accelerate the rot. This underlined to me just how important it is for a project’s driver to be someone who cares. If the project had been started with a little more care and attention then these additional developers could have been added and the quality of work been maintained. Since things were allowed to go rotten very early on the additional developers just increased the rot.

We have a lot of work ahead of us…