I’ve been meaning to write up a little post on concept and values of “software gardening”, and I caught an article in my Twitter feed about being The Code Restorer.
I really like the idea behind this, it echoes a lot of my feelings about how we treat out large production multi-contributor code-bases.
There is a subtle difference between the analogies - a restorer by their nature “restores” things to the way they were, whereas to me the analogy of a “garden” evokes more of the way that a code-base evolves and grows.
Photo by Veronica Reverse on Unsplash
Software gardening
In my farewell to Unruly post, I wrote:
The software we write does not simply sit unchanged. The world around it evolves, dependencies go out of date, domain models drift away from reality.
We do our code-bases an injustice, I feel, by spending most of our time on the critical path.
So, for lack of a better description, let’s call this software gardening - the practice of deliberately refactoring, tending, and pruning value-delivering code outside of critical path.
I don’t think I can claim this idea as original, I definitely remember having conversations with Rachel Davies about this concept several years ago, but it’s certainly stuck with me.
Why?
-
Coming back with a more experienced eye: Returning to a particular part of the codebase some months (or years!) afterwards can give a fresh view on it. At the base technical level, there may be language features available now that weren’t when it was written (for example, replacing inner classes with lambda expressions after Java 8).
-
Renew and refresh the domain model before starting work: The domain model will have been created to fit the needs of the model at the time it was created, and as people move on so do our models. A bit of light pre-factoring (a term I was enlightened to the existence of) can save time working around un-documented quirks in the domain model.
-
Weed out the un-needed: I spent some of today doing a bit of “gardening” on one of our codebases, during which I discovered at least one-unused method. Linting tools are normally good at catching this, but you might be surprised at the things that it doesn’t catch.
-
Practice a skillset: Refactoring, deleting, and incrementally modifying are all valuable tools in our toolbox. If there’s a method or function code that looks a bit unloved, smarten it up a bit. Maybe apply some kata rules to yourself, or have a go at Test-Commit-Revert to make it a bit cleaner.
A responsibility to those that follow
Gardens, like codebases, can be shared, can be communal. I know I’m not going to be the only one who works on these code-bases.
A society grows great when the old plant trees whose shade they know they shall never sit in. – Ancient Greek Proverb
Maybe we can take note from this adage and make sure our code is in the best possible state for the developers who will follow us, whether new or experienced.
There’s always a degree of nuance to these things: we fundamentally write software to make money, and that will take precedence most of the time. But in between those times, maybe stop and take a wander in your own garden of software.