Morale and working under the hood

Add comment!

August 5th, 2009

When I sit down to work on Overgrowth, I have to decide whether I should implement new features, or whether I should work on under-the-hood improvements such as solidifying, cleaning up, commenting and debugging existing features.

For my older projects I spent most of my time implementing new features, and very little time cleaning anything up. This allowed me to finish my projects quickly, but it caused several problems: I couldn't easily reuse code from one project in another, it was difficult to go back and fix bugs for updates, and it was nearly impossible for other programmers to read my code and contribute to it. Here's a screenshot of the Lugaru source -- note the impenetrable mass of repeated code:

Lugaru code

On the other hand, for Overgrowth, Phillip and I have been spending more time on under-the-hood improvements. This gives us a code base that is cleaner, more optimized, more stable, and more reusable. Here's a screenshot of the code for Overgrowth that handles the same task:

Overgrowth code

However, it's harder to maintain morale while doing clean-up work -- it's not the kind of thing we can point to and say, "Look at this cool thing that I did today!" When I was working on Lugaru, I was always adding new features that I could show off to my friends at home and at school. Look! I added fire! I added a sword! I added wolves! I worked on Lugaru instead of playing games just because it was more fun for me. The under-the-hood morale problem compounds the speed difference, because it's easier to work effectively when you really enjoy what you're doing. Maintaining nicer code may be only twice as hard as writing sloppy code that barely gets the job done, but it may take four times as long just because it's not as exciting.

How can we best strike a balance between making progress, and speeding up future progress? Do you have any ideas on how to make it more satisfying to make under-the-hood improvements?