Member-only story
“Measure Twice, Cut Once” Isn’t Very Agile.
Dad has good advice about irreversible actions, but software isn’t a birdhouse.
“Measure Twice, Cut Once” is one of the few bits of Dad Advice that actually makes sense. Passed from skilled carpenters to wannabe skilled carpenters to all manner of professions for generations, it embodies the mindset that thorough planning can prevent costly mistakes. And it is great advice when you’re looking to literally cut things, though it is also great when nailing, gluing, soldering, welding, drilling, or doing hundreds of other things that are easy to do but hard to undo.
If it costs almost nothing to double check your measurements versus the cost of one piece of lumber if you’re wrong, then that’s a good bet! As the cost of a mistake goes up, so does the reasonable cost to mitigate it. If you’re building a bridge and it doesn’t reach the other side, suddenly you have a very costly mistake to clean up. Spending thousands of dollars to prevent millions of dollars of mistakes is prudent. Physical engineering almost always contains this risk because physical changes are often hard to undo — they are irreversible.
Software is different. If you “cut” in the wrong place with software, there is minimal cost. Undo is one keystroke away. Maybe you’ll need to revert a commit. Software has no materials. It is just shifting some electricity around. Even if you need to rewrite from scratch there are no extra costs to tear down what you’ve built or to buy new material. There’s just the sunk cost of what you’ve already done and the normal cost of building new software. Software engineering changes are largely reversible; Bezos’ “two-way doors” if you’d prefer.
Why measure twice when you can cut twice for free? This sort of disparity is why Agile came about. When change is cheap, “individuals and interactions” becomes a better tradeoff than firm “processes and tools”. When change is cheap, it’s much faster to tinker against working software than reading through comprehensive documentation. When change is cheap, we can accommodate customer collaboration more readily than some heavyweight contract negotiations. When change is cheap, software engineers can actually respond to a shifting marketplace rather than following a plan and hoping for the best…
