<blockquote>
- Being a great manager and English gardening have more in common than you might imagine.
- small, seemingly minor activity
- clip away the dead leaves or diseased areas of a garden to encourage healthy growth.
- done periodically
- The day that you stop pruning is the day that the garden is full of weeds and overrun
-- from What great managers do: Prune - Signal v. Noise
Gardening is a spectacular analogy not only for management, but also for code refactoring. We need to prune our codebase consistently. And the activity of pruning in a software project is called refactoring.
Like pruning, refactoring is a small, seemingly minor activity. Renaming a variable, making a public function private, or moving a function from a module to another. It's the accumulation of all these small, incremental steps that make our codebase a better place to live.
Like pruning, refactoring demands us to remove dead code or technical debt to encourage good design. Broken windows theory is real. Only by constantly fixing the broken windows in our codebase, can we nudge others to not break another window.
Like pruning, refactoring is a periodical activity. We cannot be refactoring all the time, or we have no time for building the real thing. Often, people schedule a repetitive event to tackle the technical debts accumulated along the way. Further more, experimental messy is a necessary evil. Because we need these experiments to tell us if there's a better design.
So if you need to explain refactoring to other non-technical people, you can use pruning as an analogy. And please remember this:
The day that you stop refactoring is the day that the project is full of tech debts and overrun.
P.S. Refactoring is everywhere in our daily life. I even treat optimizing my editor workflow as a refactoring process. Pruning is just one of the best analogies out there.
Top comments (2)
Thanks for posting! I really enjoy this gardening metaphor.
I think refactoring can be done all the time. It even should be done all the time. There’s a lot of of misconception about refactoring where the thought is that refactoring is some Mid-size to big task.
I think it’s about applying tens or hundreds small refactorings over time. Every PR can contain anything from a single refactoring to more.
Yes, I definitely agree with you! We should refactor before & after we change the behaviour of our code. And we should apply multiple small refactorings so that the change to the behaviour is small too.
That being said,
what I meant by "all the time" was literally "all the time",
and by "refactoring", I meant changing code without changing its behaviour.
So if we spend 100% of our time refactoring, we cannot get anything done.