A while ago I fixed some obscure bugs in one of the search results pages of an enterprise application that I work on. I spent about four hours of focused development time refactoring and cleaning up some of the logic that handles the rendering and paging of the results. The new code worked well.

A couple of weeks later I found myself bug squashing on another search results page. As I dove into the code, I found a nagging sense of deja vu. This page had the same logic errors and mistakes as the page I had worked on weeks earlier. I found myself fixing the same bugs and performing the exact same refactorings as I had before.

I became more frustrated as I realized that the original author had copied all of the logic from the original page. Rather than extracting the common functionality to a reusable location, he took the lazy approach with copy and paste.

This kind of mistake is expensive. By duplicating the code, the cost of maintenance has doubled. Bugs must now be fixed in both places. Merging the common logic after the fact is more difficult than it would have been initially.

We have these wonderful object oriented languages. There are many ways to reuse code. Some of the following come to mind:

• Two subclasses can share common functionality in a parent class.
• Duplicated code can be moved into it’s own class. This can be done in a concrete class or via a static utility class.

I was just reading the Ubuntu development process documentation. In particular the document on Time Based Releases.

I think they really hit the nail on the head with this one. This quote caught my attention:

The overall quality and punctuality of an Ubuntu release are more important than any single feature, and a high-quality feature is superior to a hastily-added one, even if it arrives in a later release. Free software developers are passionate about their work, and it is easy to get carried away by a particular feature, losing sight of the greater goals of Ubuntu. Pause, breathe, and consider whether it is more important to get it now or to get it right.

I couldn’t have said it any better myself. Feature creep is difficult to avoid. When trying to deliver a release it seems that issues keep getting added to the pile. Eventually, the release has taken three times longer to get out the door than initially planned.

Software development needs to be flexible and respond to changes as they arise, but it seems like setting some hard deadlines can go a long way towards delivering useful software.

I just finished my second batch of home-brew. This one was a Porter that turned out to be pretty delicious.

I’ve posted a few pictures. And for those who are interested, I’ve also posted the recipe.