1. 16
  1. 7

    If we get fired for wrong estimates, you’re not gonna like the numbers I give. I’m wrong so much about how long something will take that the only way to not be wrong is going to be to 10x every honest number I believe. Software would stop if we had to be pessimistic rather than giving our best guess. Nobody would start anything.

    Edit: to clarify, it’s not that I’m consistently wrong, like I’m always 2x over what I thought or something. It feels like it’s chaotic, I’m maybe 50% I feel pretty close either over or under, but when I’m really wrong it’s 10x out, and that’s more often than I would be comfortable with if wrong guesses were expensive.

    1. 2

      That’s how Scotty could be a miracle worker. There is some value in the growth of numbers, so long as it’s done with full cooperation of those with business concerns.

    2. 3

      One of my early managers had a rule for estimating project times:

      1. List all the tasks

      2. Estimate the time in man-hours for each task

      3. Add the times together

      4. Multiply by π.

      If the project uses unknown technology, then instead of multiplying by π, multiply by π^2.

      1. 2

        Granted, I haven’t been involved in a massive project of the type this post is describing, but where this kind of disciplined process falls apart in my experience is that step 0 never finishes even after implementation has already started. New requirements keep coming in and old ones keep changing, and not all the changes can be deferred until after the initial version.

        Maybe it’s different when the project is sufficiently huge?

        1. 3

          New requirements keep coming in and old ones keep changing, and not all the changes can be deferred until after the initial version.

          This is why you have to learn to push back. The customer (or whoever it is) must understand that it does take time to figure all this stuff out, especially when the scope is large. Changing things on the fly is going to cost them. If step 0 is changing all the time, then it is very likely you are not in a large project. If you are in a large project and it is in constant flux, then you can be pretty sure your project is doomed.

          1. 2

            Definitely true that my projects haven’t been on the scale of what the post is talking about with eight-figure development budgets and so forth, so that may be the main difference.

            It doesn’t seem to be a matter of which industry you’re in. I’ve seen this happen even at a bank: Last year I had to throw out several weeks of work because all of a sudden the compliance department realized that implementing the product spec (which they had already reviewed multiple times and signed off on) would risk running afoul of money-laundering laws. And the compliance department at a bank, for good reason, has the authority to brush aside pretty much any amount of push-back from the engineering team short of, “It’s physically impossible to do what you want.”

            1. 1

              This is certainly a risk. It could happen in my work if the hardware teams decide to change something since we’re utterly dependent on them (and they are also our customer!).

              It’s important to realize that all you planned and worked on can be tossed with a spec change. The key is who is deciding on that spec. In the case you cited it wasn’t the development team. In retrospect, all the work put in was essentially pointless. The key is that (apparently) no one knew at the time the work was being done. To me, this is not an argument against planning and estimating. (And to be clear, I don’t think you are arguing against this.)

              The customer needs to be aware that large spec changes will cause significant delays. What gives planning and estimation a bad reputation is tying this all to hard delivery dates while continuing to absorb spec changes. Or to keep increasing scope of the project. Agile, in the broad sense, addresses this quite well. But I don’t see it as advocating for the banishment of estimation. Or planning. Or even forethought. I’ve always seen it as a way to get something that kinda, sorta works so that you can learn from it, even if it’s not customer facing. Doing that does not imply that mapping stuff out ahead of time is a waste.

              And hey, even thrown away work teaches you something.

        2. 2

          I do wish that more managers and stakeholders understood that software development projects are far less like building a house and far more like building an entire regional construction industry. The closest we have to a “house” these days is a single compiled binary. With modern CI/CD pipelines, we expect a single dev to produce several if not dozens of these in a given day of work.