a little madness

When I started developing, I used to feel a great sense of achievement in producing large quantities of code. A large line count was a thing to be proud of. Fast forward to today, and I see a large line count a lot differently. Experience has taught me that more code means more to maintain, and more maintenance slows me down. Hence these days I am always looking for ways to get the line count down, rather than being happy to see it climb.

Keeping ‘Em Down

How do you keep the lines down? Well, there are two obvious ways, both of which work well:

1. Don’t write the code the first place. The quantity of open source code available these days is simply incredible. A large part of any but the most unusual project can be solved by gluing together available solutions. The best part is that an active open source project will not only be maintained by someone else, but constantly improved!
2. Just delete it. Don’t be attached to code you have written: always be on the lookout for code that has passed its useful lifetime. I’ve touched on this topic before, in my earlier post on why you should delete your code.

Both solutions have their enemies: Not Invented Here for 1 (a post all of its own) and code attachment for 2.

Blood, Sweat and Tears

But what about all that effort that went into the code in the first place? It is natural to feel a sense of waste when you delete your own code. This is the kind of attachment that you need to fight. The thing is: the effort was not wasted. The code has served a purpose, not least as a stepping stone to the next revision. The real waste occurs when the cost of maintenance outweighs the value of the code that you are reluctant to delete.

What Happened To Pride?

I am not saying you should not take pride in what you create. But what you create is not the code: it is the product. When deleting code, you do it to improve the product. Not just for now, but for the future with the time you will save not maintaining the dead weight. Deleting is a necessary step in the continual improvement of your codebase.

A great recent illustration of this appeared in Jeff Atwood’s post Quantity Always Trumps Quality. The best results are rarely produced on the first attempt!

Making It Habit

Once I cast off my attachment, I found deleting code to be enjoyable. Nothing is better than watching your product grow and expand while the line count stays flat or even drops. In Pulse 2 we took the opportunity to refactor the code that powers the configuration UI. The amount of dead weight we could remove as part of this refactoring was quite incredible. Best of all it was also the most tedious part of the codebase to maintain!

I have also found that without attachment, deleting code becomes habit. It’s not just about major refactoring: it changes how I write code day-to-day. I was reminded of this by James Golick’s recent post Wearing Out My Delete Key, which discusses just how deleting code should be a normal part of your day.

Cut Away the Ball and Chain

If you haven’t discovered the joy of deleting, give it a try. Always question attachment to your code: is it based on what the code is doing for you now or how much effort you put into it in the past?

This entry was posted on Wednesday, August 6th, 2008 at 11:26 am and is filed under Agile, Opinion, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.