Engineering is a continual lesson in axe-sharpening (if you have 6 hours to chop down a tree, spend the first 4 sharpening your axe).
My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”
I don't think you spend all 4 hours up front, friend.
In my experience you're going to want a sharp axe later in the process, once you've dulled it.
Not sure if that ruins the analogy or not.
I have mixed feelings here because on one hand I prefer the “axe” when programming (vim with only the right extensions and options). But for trees… chainsaws are quite a bit easier. Once it is chopped down, maybe rent a wood splitter.
This approach is also what I'm still missing in agentic coding. It's even worse there because the AI can churn out code and never think "I've typed the same thing 5x now. This can't be right.".
So they never make the change easy because every change is easy to them... until the lack of structure and re-use makes any further changes almost impossible.
You semi-regular reminder that Kent Beck was one of the XP brain trust behind the Chrysler Comprehensive Compensation System disaster.
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
Most of my colleagues are content to spend 50 hours chopping up the tree with a pipe. We don't have time to spend making things work properly! This tree has to be finished by tomorrow! Maybe after we've cut up this forest, then we'll have a bit of spare time to sharpen things.
I recently got assigned to enhance some code I've never seen before. The code was so bad that I'd have to fully understand it and change multiple places to make my enhancement. I decided that if I was going to be doing that anyway, I might as well refactor it into a better state first. It feels so good to make things better instead of just making them do an extra thing.