Developers Shouldn’t Measure Twice, Cut Once

I was working on my fireplace this past weekend. Specifically I had just finished ripping down the old surface to the red brick, and then preparing the brick surface with a layer of thinset for tiling. I spent all of Saturday cutting tiles and then placing them on the fireplace surround and hearth. Even with help it took 11 hours to do, and about 8 hours of it was measuring and cutting tiles.

While I was doing this work, which is just mindless enough that your mind wanders but requires just enough attention that it doesn’t wander freely, I began to recite a common trades mantra. Measure twice, cut once.

This quip – a practical saying – saturates the construction industry. Whether you’re a DIYer like me, or a professional tradesperson, it’s important to measure everything twice and do the work once. This saves you a lot of pain and time down the road, since you can double check your angles and distances and get everything right the first time.

The reason that this practice is important is as simple as considering a tile. Let’s say that I need a 3/4″ width tile, but I measure incorrectly and cut it to 1/2″. There’s no way for me to turn that 1/2″ piece back into a 3/4″ piece, so I just wasted that tile. I need to toss it out (if it can’t be used elsewhere) and cut a new tile to the correct measurement. In short, measuring twice saves you time and money.

As I stood above my trusty wet saw, cutting tile, after tile, after tile, my mind began to wander into the realm of programming. I began to realize something interesting. In my opinion, many IT departments have a policy of measuring twice and cutting once, with the supposed benefit of cost and time savings. One might even call this sort of approach waterfall or agile, where estimates are gathered in detail (measured) long before the work is done (cut).

I believe that this is a fallacy that ironically leads to even more work. Every single developer that I’ve ever met in my career, including myself, cannot accurately estimate anything. We sometimes get close, because we can relate the task at hand to a similar task we accomplished previously, but in general I find that a new task is very much an unknown and the time spent to gather an estimate is pointless since it’s wrong anyway. By measuring twice and cutting once, we waste a ton of time.

I believe that developers should measure once, quickly, for a rough estimate, and then cut. The reason that I believe this is due to a fundamental difference between programming and other kinds of work that is managed with processes and estimates.

Code is not a tile or piece of wood. It is a highly flexible, malleable, mutable, digital thing. If a developer cuts a feature short, they can add on to it later, expanding it seamlessly to the required size. If they overestimate a feature’s length, they can easily chop off the excess and move on to the next feature. There is no significant cost in quick, roughly estimated measurements for programming work.

Immediately your team will regain a ton of time in which they can do their development work. They won’t have to attend hours of planning meetings or requirements gathering sessions. They will just work to get things done as fast and accurately as they can.

The only tradeoff is a lack of estimates that management-types can cite and depend on. I would challenge that any estimates derived are very commonly wrong and useless regardless. More-so, if you do not trust your developers to do the right thing and use their time effectively, why do you keep them employed?

To me, a lot of the process models around development that are popular (waterfall, agile) are derived from the measure twice, cut once methodology. This approach is super practical to physical goods since inaccurate measurements are expensive, but this does not apply to development work. These meetings to gather estimates in the hopes of controlling costs ironically bloat budgets and help to deliver less code and extend goal dates and deadlines. You take people that are hired to code, and tie them up in meetings where they have to try and justify what they’re going to code by the hour. They don’t know how long it will take, but they will have a better idea after a few hours of coding – if you’d just give them a few hours of no meetings to code.

If you’re working on tiling your fireplace, measure twice and cut once. If you’re working on code, take a rough guess at the measurement and get to work!

Tags: , , , ,

28 Responses to “Developers Shouldn’t Measure Twice, Cut Once”

  1. Nouman Shah says :

    Great insight. I re-tiled my bathroom and the analogies to programming were constantly popping up in my head. I guess the mind is trying to relate from the work of programming to this new type of work. Or, maybe it is trying to leverage existing knowledge to form a strategy to apply to the new work. A CNC machine is really where these two worlds collide.

  2. Ed Hillmann says :

    Interesting observation. I would suggest that for IT Departments, the adage should be Cut Once, Validate Twice. Or three times, or four times, depending on the critical nature of the code

  3. Santiago says :

    When I work as a freelancer, the measurement is crucial because the amount of the contract is based on the measuring. However, two measurements is lost time because I’m not sure of time and resources until I finish the project.

    Good insight.

  4. Rob G says :

    I’m not sure you’ve spent enough time in software maintenance if you believe there are no costs to changing software after the initial cut.

    A better parallel is to prototype and refine your design. Most industrial product design works like this, and software could learn some lessons.

  5. Gary Wheeler says :

    I simulate “measure twice, cut once” when I give estimates, when I’m actually doing “rough estimate, go”. I’m an old fart with sufficient experience that my rough estimates are usually accurate.

  6. Marius Minnie says :

    Great Insight I agree! This article comes at the perfect time, since new management has been bothering us development guys with this request: Provide an estimate of how long piece of work will take! Well, they’ll be the next readers of your article.

  7. Paul says :

    Or profession’s inability to estimate work accurately does make it unlike most others. If that means we shouldn’t spend too much time in planning meetings trying to find an accurate number to assign as an estimate then in most cases I agree. The problem with skimping on measuring, if that means not fully determining requirements, is that it is very easy to start building code upon a false assumption which will necessitate an entire rewrite to correct.

  8. Moore says :

    You seem to be talking about two different things
    – measuring/cutting material
    – estimating the time to do the job.
    How long did you allow yourself for the re-tile before you started?
    Almost every tradesman I have met does approximate estimations of how long it will take based upon their experience at the task….. and often get it even more wrong than software developers.

    The equivalent in programming to ignoring M2C1 would perhaps be to not do or to ignore any design> Just cut some code and see if it does what was wanted and if it performs as it needs to do, if it doesn’t then throw it away and cut some more. Programming has no material inputs to waste… not since the days of coding sheets and punched cards .

  9. Randy A MacDonald says :

    Agreed, this is software not wood. Question: why is there cutting at all? Well-written software doesn’t cut at all. Undo is always possible.

  10. h says :

    So how will the manager know if and when he will be able to deliver on time to the customer? if the team leaders can’t give him reliable estimate?

    once I had a project (which I inherited from another developer which left the company).
    the manager thought is almost done and will be delivered in few weeks. (this is what the prev. developer told her). I knew it will never be ready on time. I decided to quit the company instead of putting my self in missery for months. later another programmer was hired and in did it took him at least half a year..

  11. Jason Henderson says :

    The proper analogy to measure twice cut once, would be when a developer begins coding and has to refactor. A Carpenter’s estimates are done in much the same way as a developer’s, although he/she is working with the tangible and we with the intangible. The carpenter knows the cost of wood and labor. Can we ever know the cost of classes, methods, and interfaces?

    It would be better for the developer to take the time to properly design their code and know the use cases (measure twice) before writing a single line of code. Some refactoring will be needed. Even the best carpenter will sometimes make a bad cut or not take into account the width of the saw blade.

  12. Dave says :

    Sounds like you don’t even understand what Agile is, lumping it together with Waterfall as you have. This thesis is really flawed.

  13. Doc Phatty says :

    In my experience with software development, measuring twice before cutting means refining the requirement to the point that devs have a good understanding of what it is they’re gonna build:

    Measure Once: “We need a money transfer thingy”
    [with M1C1, the team now builds a cash register]
    Measure Twice: “We need an ATM”
    [with M2C1, the team builds an ATM]

    So it really comes down to how much time did it take going from “money transfer thingy” to “ATM”, versus how much effort was involved converting the cash register to the ATM. In some cases, one would exceed the other, in other cases they might be closer.

    Call me olde fashioned (and I’m not attempting a waterfall/agile debate), but I’d rather have a clearer idea of what I was building up front rather than spend the time refactoring – the latter of which can have a tendency to introduce further defects into the system.

  14. Mat says :

    This is tricky. No boss would suffer a developer who would not give estimates. Bosses don’t suffer inaccurate estimates for long.

    Accurate estimations in software development have always been a problem. As an industry we seem to be singularly unable to measure anything objectively, let alone relate that into something business heads will understand: time, money & quality.

    I’m fairly sure the trend to not delve into the fine details of any project and just dive into production doesn’t help. Business have to be a lot more honest with themselves about the effort required to analyse the details and the true cost of software.

    Ironically, modern software techniques being developed to counter the business world’s fickle attitude to software (changing requirements, short timeframes and low budgets) should make the whole thing more robust in the long run.

  15. Joey says :

    Howdy, I enjoyed the article. I generally agree. I think it really comes down to not estimating too big a project. Consider your tiles. How long will it take to cut 1 tile? You’ll ask a follow up question, “What kind of cut do you need?” Upon receiving that feedback, you’ll say “5 – 10 minutes.” You come pretty close. w00t!

    Now, consider this: You’re shown a sketch of the fireplace that needs to be tiled. You’re asked, “How long will it take to cut all the tiles for this fireplace?” The problem isn’t estimating. The problem is what’s being estimated. Agile estimation aims to make the “How long will it take?” apply to individual tiles, not a whole fireplace worth of tiles.

    I think the problem you point out isn’t estimating. It’s what we’re trying to estimate, the information we have to estimate with and when we estimate in the process.

    The other thing to consider is where waste really is in a software project. Isn’t the waste really in unnecessary features? Or gold plating. Trying to estimate then build too much at once. And then waiting for everything to be done before any value can be realized. I had this very conversation yesterday. One of my business folks said, “Well, we don’t want it until it’s all done…” I smiled and responded, “Are you saying then that there is no value in ?” Waste is found in work done and not delivered. Estimating is necessary to determine if the value delivered is worth the expense of the effort.

    Finally, remember the golden rule of management. That which gets measured gets done. I trust my team. I also know human nature. The eustress of time constraints is healthy.

  16. Rob Thuleen says :

    I generally agree that inaccuracies in SW estimate abound. This stems primarily from not fully understanding end-user “requirements” (I prefer to call them “needs”). Though the author repeatedly sites agile development as a “measure twice, cut once” process, the primary motivation for using an agile approach is to overcome the lack of understanding of what the final product should be. I think there are times for the measure twice, cut once process in SW development. I used to work on Real-Time embedded systems where SWAP (Space, Weight, and Power) and Timing requirements were absolutely inflexible. In certain situations a developer (and System Engineer, together with the programmer) has to spend time accurately researching and planning the software to meet the requirements. Most mainstream SW development is not in that category though. Interesting read.

  17. Lorenzo says :

    I completely agree with Joey: waste is found in work done and not delivered. Estimating helps in finding out if the value delivered is worth the expense of the effort.
    If the estimate is rough and quick, you can ditch a feature with minimal waste.
    It is curious to see how many developers from major companies see the “too much process” as a waste; there is also the other side, however, which is much more common here (where the great majority of software companies is small, and often not a software company at all; just a department of something that does totally unrelated things, like selling goods or (non-IT) services).

    Here is “this is the measure, make it fit” (I want this with everything by next week). There is no culture of estimation; software is made of thin air, so it should be easy to made. It’s not tiles, those require work, “my son with his laptop did something similar in two days so I will give you one to do it”, etc…

    Problems with estimations aside, I see the “measure twice, cut once” differently. Measuing, in engeneering, is about “getting things right”; it’s not about time, it’s about getting the desired component in the desided specifications (or close enough). For me, this is much more related to (unit) tests: if I need some functions, or API, or component, which needs to be precise (e.g. a graph reduction algorithm, or tax cost computation), I write down the expected results for various special cases, computing them by hand (measure 1), and then I implement the code that makes the tests pass (measure 2). They have to match, otherwise you have something to check. Like you do with tiles.

  18. Simon says :

    Thanks for the article. I worry that by not measuring well we are apt to fall into the trap that is “come on let’s get going”. The personalities of software developers tend to lean towards being action oriented and not being good at stopping and taking stock. I’ve been learning a lot about going slow as of late and it is kind of nice.

    My biggest issue with this article is that I read the whole thing and there was no picture of your fireplace. C- on visual aides.

  19. spdufeu says :

    This got me thinking about the benefits of Backlog Refinement and I’m wondering if you’ve had much experience of such a meeting? Would you class that as “measuring twice”?
    I think truly excellent developers who know the software they’re working on inside out can get away with less measuring, but I’ve not had first hand experience of that happening.
    Maybe the amount of “measuring” a team does during a sprint could be another metric to measure and track.
    Either way, very interesting post, thanks.

    • David Haney says :

      Hello Matt, thanks for writing!

      I have been a part of a scrum team with rigorous backlog grooming and planning. I would say that when done correctly, it is not a “measure twice” scenario. By this I mean if the business accepts the estimates as rough, accepting that they may change in the future, it fits the measure once approach. On the other hand, the explicit goal of scrum is to get accurate estimates, which I feel is actually impossible from a psychological standpoint. We can only ever estimate based on evaluation of similar tasks and scenarios, so new work cannot truly be anticipated. When I was a part of a scrum team, I often found that I would estimate the time needed to do the work as X, only to find that X had no correlation over time to Y, the actual time. Sometimes Y was 0.5 * X, and sometimes it was 5.5 * X (a scenario where at the meeting I said “this looks easy! 4 hours!” and then as I began coding, realized that implementation would require touching 5-6 other areas of code).

      I like your idea of measurement as a metric. What would be a “good” value? What would be too much measuring? Too little?

      Cheers!

      -Haney

      • spdufeu says :

        Very good point accepting the estimates as rough. I’d be tempted to include the team in that too though, as I’ve been in some retrospectives where the team started second guessing themselves over an estimate being a 3 when it was actually a 2!

        As for good and bad values, I imagine it would vary vastly by team. It would be another metric I have at my disposal that I’d hope to see a correlation between velocity and “grooming time”. I do something similar with “average PBI size” for each sprint. It’s clearly not the thing to focus on, but does reveal that some teams work better with larger PBIs.

        Thanks for your reply

  20. Graham Bull says :

    I don’t think anybody considered what happens when you break a project into small chunks. It might be hard to accurately estimate the project as a whole, but each chunk would be much easier to estimate. Add up the chunks, and you’ve got a reasonable estimate for the project. Oh, and nobody should jump straight into a project without that list of smaller chunks 😉

Trackbacks / Pingbacks

  1. The importance of backlog refinement - Matt DuFeu - May 9, 2015
  2. Software Estimates | Voice of the DBA - September 1, 2015

Leave a Reply

Your email address will not be published. Required fields are marked *