Developers shouldn’t measure twice, cut once

[Kent Sharkey]

Haney Codes[^]:

I believe that developers should measure once, quickly, for a rough estimate, and then cut.

Save even more time: don't bother measuring

[PIEBALDconsult]

Measure schmeasure; we have undo, version control, and future releases.

[Rob Grainger]

Just because software is malleable, doesn't mean there is zero cost to maintenance. I believe we could learn a lot from industrial design, where a series of prototypes are frequently made and refined, but the final cut is designed to be durable and maintainable (depending on the project's constraints). There are many types of software projects. Some require the entire thing to be correct on delivery (consider control systems for nuclear reactors, or cars). Others require continual changes (many web applications). The key is to choose an approach that matches the application.

"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.

[Mark_Wallace]

I had to read a lot of this article twice, to ensure that it was as full of bollocks as it seemed on the first read. The writer obviously knows absolutely bugger-all about building, absolutely bugger-all about the meanings/origins/usage of English expressions, nothing about agile/waterfall, and probably bupkiss about program design, although it looks like he/she/it may have done a two-week course on it. Back when I used to do editorial work, I'd have shredded this; I wouldn't have even sent it back.

I wanna be a eunuchs developer! Pass me a bread knife!

[Dan Neely]

Rob Grainger wrote:

Just because software is malleable, doesn't mean there is zero cost to maintenance.

Yep. The one app I maintain's 3 biggest pain points for me are all things that were done due to severe time pressure (partly our underestimating complexity, partly the customer pushing a lot more scope creep/churn before the PM finally drew a line in the sand) that are too complex to fix short of a major update whose budget continues receding into the future. The biggest user painpoint is something that looks like it would be a simple change in the code; but involves breaking a major invariant in the existing platform that no one involved (I wasn't) remembers if was done because the CM lover wanted to Lock Down All The Things, or because it was the quickest way to mitigate a problem found in early testing. That makes its potential unintended consequences broad enough that unlike the dozens of minor hotfixes and tweaks that've been done since release, an update of an full rerun of the manual test plan to mitigate risks. :sigh:

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt

[thrakazog]

I prefer to cut half way. Then look again to see if the measurement is needed.

Hold my drink and watch this.

[Duncan Edwards Jones]

Measure twice cut once is nothing whatsoever to do with estimation - indeed I cannot think of anyone worse at estimation than builders. It is more about preparation and verification before you make an irreversible change. This is why surgeons, pilots and deep sea salvage operatives have checklists - and perhaps that's the bit that software people should seek to emulate.