> But even a bad estimate gives you some handle on how easy or hard something is to do
Can’t agree with this at all. A bad estimate is by definition bad. How does it give you a handle on anything if it’s unreliable? It’s like saying bad medicine is better than no medicine.
And when you talk about breaking an estimating problem into smaller estimates, you’re now firmly in the domain of actually doing the work. An economist can’t take a software problem and decompose it into tractable solutions. Even if they could - good luck getting the customer to pay for that.
That’s why I say estimating is an economic problem. The cost of accurate estimates asymptotically approaches the cost of the implementation. Nobody is willing to pay for accurate estimates, and anyway doing this doesn’t make sense.
Unfortunately there are very few levers to pull in terms of software planning. Time based project management is way over emphasised. This is why approaches like lean (MVP, CD) and agile exist in the first place.
That's the problem. You have an opinion but no empirical evidence and you think your opinion is pretty good. There's plenty of material out there that is a bit more well reasoned that disagrees with your opinion. For example Don Reinertsen's books.
Most Agile estimates are pretty bad. But that's OK because it's still better than just winging it. One of the realities of working with real companies is that they have things like dead lines. Programmers don't like them. The don't believe in them. They are bad at delivering stuff on them. But they still exist. The reason agile/lean/scrum/etc. exist is to beat some sense into programmers completely and utterly failing to deliver anything on a predictable schedule. Bad estimates are the foundation of these processes. Where bad is better than no estimates and the rest of the process is about mitigating the consequences of the estimates being low quality.
> That's the problem. You have an opinion but no empirical evidence and you think your opinion is pretty good. There's plenty of material out there that is a bit more well reasoned that disagrees with your opinion. For example Don Reinertsen's books.
Wait - there is a large body of work that is better reasoned than a quick post dashed I off in haste before dinner?
> One of the realities of working with real companies is that they have things like dead lines
Using condescending terms like "real companies" is unnecessary. You know nothing at all about me or how I've come to my conclusions; you just make arrogant assumptions that you know better about this than I do. I'm open to being wrong and learning new things, but do you really think you have the Silver Bullet?
My experience over a large number of projects suggests that the whole premise that most commercial software project problems can be solved using technical, mathematical or scientific means is wrong. My opinion - which aligns with the results of large-scale studies such as the Standish Group CHAOS reports, the PMI Pulse reports and more - is that the problems with commercial software projects appear to be almost entirely social and organisational. Projects are too ambitious, too complex, and are executed poorly by inexperienced people. No amount of time spent on estimation is going to fix that.
I am unfamiliar with Reinertsen's work, but I think it's quite interesting that economics is not exactly a science either.
Can’t agree with this at all. A bad estimate is by definition bad. How does it give you a handle on anything if it’s unreliable? It’s like saying bad medicine is better than no medicine.
And when you talk about breaking an estimating problem into smaller estimates, you’re now firmly in the domain of actually doing the work. An economist can’t take a software problem and decompose it into tractable solutions. Even if they could - good luck getting the customer to pay for that.
That’s why I say estimating is an economic problem. The cost of accurate estimates asymptotically approaches the cost of the implementation. Nobody is willing to pay for accurate estimates, and anyway doing this doesn’t make sense.
Unfortunately there are very few levers to pull in terms of software planning. Time based project management is way over emphasised. This is why approaches like lean (MVP, CD) and agile exist in the first place.