Software estimation is hard – do it anyway

I used to do real estimates and was borderline prophetical on them. Didn't matter. I stopped and now just do a rule of thumb plus two weeks, two months, two years depending on the project. Professionally it changed nothing. For me it made my life much better and now projects come in "early" and make customers happy. Instead of people frothing at the mouth because it was a "day late"

Why do we as an industry put up with this? Lawyers Don't, Doctors Don't. Pretty much any Degree based industry doesn't. If it goes over budget/time they all just shrug and say that's how it is if you want it you have to pay more. Yet Devs are somehow supposed to know to a dollar how much the unknown will cost?

Years ago, in a former life, I built a project boilerplate that included all the non-development tasks required to build and ship a new version of a product that I used to build out all my project plans.

There's all this (important) "guff" that people in the development often don't think about and don't care about that you absolutely have to take into account if you want to get even close to a sensible ship date. Some examples: updating license agreements; creating new records or updating them in your licensing system; providing various kinds of information and training to sales and marketing and coordinating with them on launch plan and materials; ensuring your support team is trained on the new product or version; budgeting time for support tasks on existing products; running your early access program, including gathering feedback and implementing changes based on it; and on and on.

The other thing I'd do is front-load all the riskiest work: that way if something goes wrong or is more complex than expected you know early, can communicate early, and there are no nasty surprises late on that might have a negative impact on other parts of the business or customers. You also have plenty of time to come up with contingencies to rescue the situation if it is somewhat time critical.

Even then I'd offer up a "hurricane model", where I'd have an earliest ship date, latest ship date, and most likely ship date, and that window would gradually narrow as the project progressed, the same way certainty about a hurricane's near term track increases as time goes on. Obviously that might not hold true if there's a significant shift in requirements. With our projects what it meant was that by the time we were at the point where we needed to start coordinating across teams around launch activities (generally about three quarters of the way through), there was enough certainty to actually pick a release date that everyone else in the business could work to.

And what did I base all this on? Well, past experience: actual data, even if it was fuzzy or there were too few points for any kind of statistical significance. They key point is that all the work required to ship the product, whether inside or outside of our team, was included in the plan.

Estimates and (increasing) certainty are often quite important to other areas of the business so I would say you can't ignore them, certainly not if you want your voice(s) to be taken seriously in the wider business.

I tried that, and it was almost (but not quite) invariably held to be the lowest of the range, and still construed as a deadline. "3-5 months" becomes "3 months or we have to reschedule other stuff".

I think of it this way. All problems that become sticky problems, got that way by being sticky. Re-writes encounter the sticky problem one way. When the spec is real, the spec is vast. "Do everything GMail does" is a lot of things.

In internal business app teams, the sticky issue is that no one actually understands the business problems well enough to articulate sufficiently. There's usually very little incentive to be the spec person, on either the technical or business side.

It might often be the same underlying issue. The difference with rewrites is that the "conversation" happens within tech teams, no outside player.

Demoing every day only works if your work is easily visible, but that's beside the point. Micromanagement to this level is not conducive to a healthy development environment.