Cleaning Out Your Code
By Tom. Filed in Gaming, Programming |
In my spare time, I’m working on a game. (I wonder if there is any programmer who can’t say that to some extent?) The details aren’t important (it’s based on the old Star Frontiers RPG) but if you want to check it out you can find it on my gaming site in it’s own forum topic.
I’ve been working on it off an on for several years now. It’s primarily been a learning exercise for me but it’s getting to the point now where it is actually playable. I’ve implemented something like 90% of the rule set. And therein lies my dillema. My efforts on the project have been in spurts. A couple of weeks spending 10 or more hours on it and then months where I don’t do anything.
During the “on” times, I’m fired up and want to get things implemented and add new features and get them out the door as quickly as possible. And so I do whatever I can to “just make it work” and get it out there for people to play with. And so along the way I’ve incurred a lot of technical debt and the code has accumulated a bit of code cruft as well (well, probably much more than a bit).
I was first introduced to the concept of technical debt when reading Jeff Attwood’s post Paying Down Your Technical Debt. I could defnitely relate to the topic as I was going through the same thing both in my at work code and my game code.
And it seems all I’ve done since then is build up more debt. I’ve got these last little bits of the game’s rules to implement and it seems that every addition requires reworking things I’ve done before. But I’m getting better and have started to pay down the debt and clean up the code to make it better and more modular.
As developers, we probably all have to deal with this at some point. And if we are developing stuff for others to use, they like to see progress and additional functionality with each release. Unless the bugs were show stoppers, a release that just fixes bugs isn’t very interesting to your users, they want it to do something more than the last one.
But you still need to pay down your technical debt and clean up your code. And so for the last couple of releases that I’ve done, I’ve adopted a new strategy for dealing with this. In each release, I’ve added one piece of new functionality, hopefully something that will pique the users’ interest so that they’ll grab the new version and try it out. But at the same time, I’m working really hard in the background to clean up and refactor the code. For every visible addition to the game, there have been two or three backend changes that the user doesn’t see (since it doesn’t impact the UI or game play) but which help me get the code under control and pay down my debt.
And it seems to be working, at least to some extent. In this last go around I fixed several bugs and in the end, the main code was actually smaller than the original and a little easier to understand. So I must have done something right.
It’s an on-going battle. In the end, I guess if you are shipping code, you’re winning. But the faster you can ship, the bigger the win. And cleaning out your code and paying down your technical debt just makes things easier and makes it possible to have the bigger win.
