Code Gardening
Why Code Garden?

Somebody asked me the other day why I thought code gardening was so important - why had I invested my time in this series of blog posts and in a live coding presentation that I’ve given multiple times. That question turned into an interesting conversation and I thought I’d share one of those ideas with you.

Stephen Covey (of Seven Habits of Highly Effective People) fame suggests that we can divide our activities into four groups, classifying them by importance and by urgency:

You’ve probably seen this breakdown before - it’s a popular idea that’s been reused very many times across the entire internet. But have you ever thought about how it might apply to software development?

Where would common activities fall in these quadrants?

• Production support issues - urgent/important.

• Completing feature development on time - urgent/important.

• Writing documentation - nonurgent/important.

• Improving test coverage or reliability - nonurgent/important.

• Browsing interesting questions on Stack Overflow - nonurgent/unimportant

• Deploying a bug fix release for testing just before the test lead goes on holiday - urgent/unimportant.

• Proof of concept work for a proposed feature on our roadmap - nonurgent/important.

• Upgrading third party libraries to avoid known security vulnerabilities - nonurgent/important.

• Switching to use the latest test framework just because it’s new - nonurgent/unimportant.

The key is that time spent in the nonurgent/important quadrant is stuff that makes the future better - saving time, improving security, increasing reliability and so on.

I believe that code gardening is another activity from the nonurgent/important quadrant that makes the future better. Code Gardening improves the maintainability of the codebase by increasing readability, reducing the possibility of inconsistencies, enforcing pre- and post-conditions and so on.

Unlike a technology proof of concept, however, you can incorporate code gardening into your everyday practice, spending just a few minutes on gardening while still doing everything else.

Even if you spend your entire day (or week or month) fighting fires in the urgent/important quadrant, you can still invest a few minutes a day in code gardening, improving the codebase for the future. The very least it will do is give you some sense that things are actually improving.

Besides which, I’ve found that the effort required to carefully understand and make small improvements to the code tends to pay off almost immediately. I’ve seen reduced defect rates through a reduction in code duplication, elimination of inconsistencies and active simplification.