> Software estimation is a joke because there's no penalty for underestimating.
In my experience, while this might be true in some companies, I noticed that most of the time the issue with estimations is the lack of clarity (=what do I really want?) and enough context (what's the impact in terms of scope to reach what I want?).
Most of commercial software, for whatever weird reason, keeps on being compared to other industries and repeatedly this fails.
It's not like building a car, it's not like building a house, it's not like shooting a movie, etc.
> I noticed that most of the time the issue with estimations is the lack of clarity (=what do I really want?) and enough context (what's the impact in terms of scope to reach what I want?).
From what I've seen, this up front design ends up being a good portion of the design time. The cheat is that people don't include this upfront design in the time estimate. They say "the specs are still being set, we can't start yet" rather than "we're delayed in setting these new specs", even though the end date moves similarly.
This is because of the way most software is built. If you are using event modeling, it's very easy to estimate feature costs. The only exception is when you are truly innovating new algorithms so there is not a historical precedent you can refer to. This is not common work in the industry however, most software projects are variations of previous themes.
Sorry but I don't buy that a specific process can solve that problem. DDD can actually add quite some unnecessary complexity, not only because it requires that everyone is skilled to know how to apply it, but also because sometimes you really feel you're overenginerring things just to follow ... a model.
I know for certain that a specific way of doing things can and will improve a process. Nothing to say there. But "solving" a problem? Not sure about it.
Plus, sometimes you as a company don't know really what decision to make. PMs try to figure it out, get stuck, unstuck, and then suddenly a big company comes up with something new and your market is shaken. So again "what do I want?" which has an impact over everyone in the chain, because you must design something but keeping in mind that "it might be different in 6 months". So extensible, scalable, but hell please don't overengineer it, and yet I want it to run on K8s, but if a customer needs it in their data centers, we need to find a way to make it work there too, in a way that scales, but we can't give them a k8s cluster. It has to be easy to install, offer great UX and also be Fedramp and super secure, which most of the time means "either ... or".
Some industries are brutal.
Sorry I don't believe that a process can solve that problem.
Maybe in some specific industries where you have a lot of time, very well defined and predictable roadmaps it can work too.
In my experience, while this might be true in some companies, I noticed that most of the time the issue with estimations is the lack of clarity (=what do I really want?) and enough context (what's the impact in terms of scope to reach what I want?).
Most of commercial software, for whatever weird reason, keeps on being compared to other industries and repeatedly this fails.
It's not like building a car, it's not like building a house, it's not like shooting a movie, etc.