Management, Refactor, and Prune

        <blockquote>

• Being a great manager and English gardening have more in common than you might imagine.
  1. small, seemingly minor activity
  2. clip away the dead leaves or diseased areas of a garden to encourage healthy growth.
  3. done periodically
  4. 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.