"Measure twice, cut once" is an aphorism used by carpenters.  The idea is that after cutting a piece of lumber, one cannot undo the mistake without throwing away the piece and starting over, so it is important to ensure that one is cutting in the right place.

This same idea underlies BigDesignUpFront.  However, the analogy doesn't necessarily hold for software development, as "making a cut" and then throwing away the result and starting over is often a lot less expensive than doing a lot of prior measuring.

This same idea underlies just thinking about a problem (not necessarily BigDesignUpFront) before diving in and squandering expensive resources, whatever those expensive resources may be.  In software the bits are cheap but the time spent pushing them around isn't.  Of course, neurons are free.

Depending on how one thinks, the cost of the time spent thinking about writing code is about equal to the cost of time spent actually writing and testing code, so one needs to find the point when additional thinking is less valuable than starting to do something.  Or is thinking doing something, but just not committing all of it?  And what about the time it takes to 'uncommit' written but unwanted code, especially when it's all tangled up with wanted code?

-----

Note that this is critical for one to not cut '''too short''', as cutting too long ''can'' be fixed by another cut.  It also reminds me of another saying: ''Measure with a micrometer; mark with chalk; cut with an axe''

Once I cut a 2x4 six times, and it was ''still'' too short!

-----

Neurons are free?!  ''What, you paid for yours?  Oh, I'm so sorry.''

''But minutes are not.''

-----

Also useful in situations involving cutovers from System A to System B where the System supports mission critical functions.  When replacing the machinery that feeds the front desk at a hotel, the impact of 30 minutes' DownTime can be quite harsh.

Before throwing the switch, run the numbers, check the wiring.  Check it all again.

check