Clarke Ching introduced me to a story of 2 woodcutters – one worked furiously but finished late whilst another stopped frequently to sharpen his tools and finished early. (He tells it better than I do) – I think it’s actually based on an Abraham Lincoln quote:
“If I had eight hours to chop down a tree, I’d spend six hours sharpening my ax.”
Let’s think more about developing software the Lincoln way…
What tool sharpening should you do before you start chopping?
If you paid off or prevented some of the debt you were facing before new work started, would it enable your project to run faster, more smoothly, with reduced risk, a lower chance of defects or a lower maintenance cost?
A previous employer had a great strategy. Every new release of the product had 2 top priority named features on the priority list for “cleaning up” and “levelling up”.
Cleaning up:
- Get all unit and regression tests passing (and keep them there).
- Address all build failures and warnings (and keep them under control).
- Delete all functionality, code and tests that will have been deprecated for more than 3 releases. (and add alerts to functionality that will be removed in the next release)
- Fix all defects that put us below releasable quality before we’ve even started (and keep them there).
Levelling up:
- Raise the tools we use to those that are best supported, newest in the market or offer improvements to our working conditions.
- Raise the libraries we use to the latest supported versions and address any issues.
- Raise the platform versions we’ll support when the product ships and address any issues. (and remove support for obsolete or out of date platforms).
No major release started full-tilt on functional work until these were cleared.
Like all good practices, this isn’t new thinking, it correlates to 3 components of the lean 5S strategy; sort (seiri), straighten (seiton) and shine (seiso). Rather than just describing what was done, here’s some tangible benefits for the clean up & level up approach…
- There were no unpleasant surprises for our customers on a new release. We had a standard platform, support and deprecation policy and kept to it. Our customers liked it when we did predictable things.
- For the development teams levelling up was a common risk. Addressing this at the beginning of a project was a valuable de-risking activity. Where we hit critical problems, we could make clear, early upgrade decisions and where there were fewer issues we would develop full-time on updated versions throughout the project with regression on older supported platforms available from prior development cycles.
- Removing old parts of the product made life significantly easier for the teams. The reduced testing, regression and maintenance load allowed us to speed up development - much like scraping barnacles off the hull of a boat to help it run faster. Cleaning up also allowed us to take some sensible baseline code metrics before any new work started.
- Giving teams space and time to clean and level up before starting functional work had a positive impact on morale. We felt that we were trusted to “do the right thing” rather than “just ship it”. This empowered us to continue doing the right thing throughout the rest of our work.
Give your teams some time out to sharpen their tools and sort, straighten & shine the workshop before new work starts. It will make a difference to the performance of your team and the quality of the end result.
