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.

Comments

blog comments powered by Disqus
Next Post
Intention Revealing Bools  02 Jul 2016
Prior Post
Sharpen The Saw #5  19 Jun 2016
Related Posts
Method Archetypes  15 Nov 2016
What is it with Booleans?  08 Oct 2016
Are Boolean Return values Evil?  11 Sep 2016
Null arguments are evil  14 Aug 2016
Don't work too hard  30 Jul 2016
Intention Revealing Bools  02 Jul 2016
Throw Rich Exceptions  11 Jun 2016
Multiple Boolean Parameters are Really Evil  22 May 2016
Boolean Parameters are Evil  15 May 2016
Validate Method Arguments  16 Apr 2016
More code-gardening posts »
Related Pages
June 2016 archive