Comments by "TheEvertw" (@TheEvertw) on "Estimating Software Delivery Time DOESN'T WORK!" video.

Many managers complain that software is the only discipline in engineering that can't make good estimates. But in all other disciplines, designing is about 10% of the final cost. The rest is manufacturing, logistics, purchasing etc. In software, designing is 100% of the cost. There are no (almost no) "manufacturing" costs. The other disciplines can not estimate how much "design" costs either. If they do estimate it, they are often wrong by a factor of 2. But they can make pretty good estimates for manufacturing from a preliminary, rough design, and the variance in design costs is negligible compared to manufacturing. That is apart from the other disciplines dumping all their big problems on software. "Oh, software will fix that" has doomed many projects. This include inter-department warfare that software is somehow to bring to an end -- the bane of many government SW projects.
65
The principles still work. You can make "proof of concepts" very quickly even for very complex systems. That is what stuff like LabView and Simulink is for. Risk-driven prioritization is even more important for those projects. And management needs to know and be OK with the fact that early in the product cycle, estimates for software can be off by a factor 2. If they are not OK with that, they need to manage the project differently, spending more time in small POC projects before going all-out. If you give a detailed estimate for a complex software system when there still are technical risks, you are doing your company a disservice.
14
@ForgottenKnight1 Also, every 10 years the industry decides to no longer use the nuts 'n bolts of the previous product line, switching to something as radically different as e.g. using only glue or only velcro.
5
 @Tony-dp1rl Companies that do complex systems are aware of the uncertainties in software estimates and are skilled in risk management. Or they won't be in business for long.
2
@SufianBabri Exactly! It isn't like the tooth shape of an M-10 thread changes every time the relevant committee has a meeting. But this does happen with our tools and even our programming languages.
2
@chrispeng5502 What projects that start with a deadline need, is a risk / uncertainty driven management process, like true agile, to ensure that at least there is something that more-or-less works at that deadline. As all PMs know, you can estimate project cost, duration and quality (match to requirements), and pick any two of those to meet. But never all three. In SW projects, two of those need flexibility, as you can not pump money (i.e. more developers) into a project to make it faster. As someone said, you can't spread the process of having a baby over 9 women and expect the baby to be ready in 1 month. Pumping developers into a SW project that is late will make it even later.
1
@57thorns the problems in a project never come from the things you know. They usually come from the things you think you know.
1
@rosomak8244 More often than not, errors in civil engineering estimates are either because of sloppy pre-sales, or a scheme to twist the Principal's arm into overpaying half-way through the project. Or both.
1