Pulling weeds

Tuesday 11 May 2004This is 19 years old. Be careful.

When I look back on a week of work, and review the code changes I’ve made, there are often a number that are trivial changes to clean up code, often in far-flung areas. I am mocked for this habit. I sometimes mock myself for it. But I think it is important. I call it “pulling weeds”.

Andy Hunt and Dave Thomas, the Pragmatic Programmers, have said Programming is Gardening, and I have to agree with them. As good as their analogy is, they missed the topic of weeds.

One habit I have noticed in truly impassioned gardeners is that they are never idle in their garden. Whenever the opportunity arises, they will pull weeds. They may have headed out to replant, or to prune, or to feed, but while out, if they notice a weed, and they have a free hand, they will pull it.

I’m the same way with code. While pursuing weightier matters, if I notice little things wrong, I will fix them. “Acquire” is misspelled “aquire”. Fix it. A Windows-specific call has crept in where a portable one will do. Fix it. A function prototype has been orphaned after its definition has been removed. Fix it. The code formatting conventions aren’t being followed. Fix it.

This can be taken to absurd lengths, and I have taken it there (I’m remembering a phase where I was methodically working my way through a Java project, alphabetizing the imports). But the more typical extreme is for developers to believe that none of these changes matter, and to leave them be. Who cares about spelling errors? What difference does obsolete code make?

Gardeners pull weeds because they know that if left unchecked, the weeds will take over the garden, and that leaving it all until some optimistic cleanup day will make the job at least very difficult, and possibly never happen at all. Weeds in the code are the same way: they are not inert. They spread gradually but insidiously until removing them becomes a major job in itself.

To draw again from the Pragmatic Programmers, this is a case of broken windows. Small problems left uncorrected lead to lax attitudes about the bigger problems. Only by being diligent about all the problems in the code can you hope to truly nail them. The little ones may not matter in the scheme of things, but little ones become big ones, and the big ones do matter. Get them while they are small.


I totally agree with you, and I do the same thing whenever I can at work. Sadly, I can't always get away with it (yay red tape), but I do my best to clean up the code. Sadly, not everyone on my team agrees with this, and the code isn't exactly in the best shape ever, but I'm doing my part.
Ah, this one has the characteristics of a great weblog post: you say what many are thinking, but don't want to come out and say themselves.

I agree with you. And I take the liberty to weed my own code regularly.

The biggest problem with weeding, though, is it adds a lot of noise to the version control, making it difficult to track significant changes. Alas, nothing ever comes for free.

We used to make fun of Ned's obsessive alphabetizing of Java imports but mainly it was because it was manual and tedious labor. Now we use Eclipse to do it for us. Better still, it will automatically remove (or add) imports for you.

I was going to make a similar point as Doug: the source control system, especially on a large project, can make it painful to do weeding on files that have a lot of people changing them. Ironically, these are often the files that need to be weeded most.
I think this is one of those cases where unit tests come in handy. I've seen a lot of instances where someone (including me) "fixes" some ancillary issue and introduces a new problem. In the worst case, this problem is more serious than the fix that brought you into that portion of the garden in the first place. Usually, fixing a spelling mistake won't do this, but maybe removing some seemingly "dead" code will.

I think if you limit the scope of problems classified as "weed", this is an essential practice.

Strangely, I was weeding the other day and manage to mangle several of my real plants while doing it. Analogy abuse? Perhaps...
A cautionary note when fixing spelling errors:

I well remember inheriting the maintenance of some sludgy Notes database several years back. I noticed that one of the ACL roles was mis-spelt thus: [KnowldegeMgrs].

Being a good chap, I decided to correct the typo. All hell broke loose, as code all over the damn NSF referenced the incorrectly-spelled version.

I had to put in a little overtime to fix this... ;o)

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.