Comment by mightybyte | Hacker News Reader

Comment by mightybyte | Hacker News Reader

Parent Full thread

Yes, I get that all engineering (not just software) has inherent uncertainty in estimates. And there is always the chance for unanticipated events causing major overruns. But I still think that the uncertainty in software is significantly higher than in other engineering disciplines.

Of course I don't have any scientific evidence for this claim. But there are lots of phenomena that exist in the world that don't yet have scientific support. I think that software his higher uncertainty because it is much less constrained than physical engineering. There are a relatively limited number of ways that one part of a physical system can impact other parts, and those are constrained by the laws of physics. Software systems have no such laws. It's often possible for any component to write to arbitrary locations in memory controlled by any other component. This is kind of like a rusty hinge on a 34th floor bathroom door causing a problem with a doorbell on the third floor. Those kinds of actions at afar just don't happen in the physical world and if they do, they happen via pretty well understood physical mechanisms. To make matters worse, the discipline of software engineering is less than a hundred years old as opposed to thousands of years for physical engineering.

It's not about feeling special. I think there is something fundamentally different about software.

The only thing different about software is we haven't been doing it long so we don't know how to estimate. If you are writing a CRUD web app, it is just like the million others that have been written before and you should have the ability to give reasonable estimates. If you are writing a self driving car - that is new ground that only a few have attempted: there are many "unknown unknowns" that are hard to account for.

I've been developing CRUD apps for my company's clients for eight years. They're all superficially the same, but every single one of them has had something unique about their schema design, and they all have different business rules (in a general sense and in specific details) that make every project unique. We have a model that gives us ballpark estimates before we get into detailed analysis, but every time a customer insists on taking our ballpark estimate and treating it as a fixed-price commitment, the project becomes uncomfortably stressful.

I was just talking to a dirt moving contractor, he would say essentially the same thing as you.

Estimate higher then.

If I am developing a standard project, I will give you accurate estimates that are often correct. If I am building a custom project, my estimates will vary greatly, based on how custom it is, how well you describe what you want, and how many times I can expect you to change your mind about something.

It's really easy to tell whether you're building something standard. If it is standard, you don't need to write software for it. Say you want a standard blog. You use Wordpress. Say you want a blog that's kind of like Wordpress but a little bit different. You need to hire a programmer to write a custom component.

Effectively, all the software we write is custom. Once something becomes standardized, you no longer "build" that software. If it is standard, you install and configure it.

This is the same in the real world. If you need a standard kitchen, you can estimate how long it will take you to go IKEA, buy the cabinets, bring them home, and install it. If you want something custom, it all depends on how custom. If you want cabinets that retreat into the wall, have glass fronts, bulletproof countertops, can adjust in height so that both your 5'2" wife and her 6'11" husband can use them, in the mobile trailer that needs to tolerate temps from a dry -40F up to humid 100F without discoloration and warping, good luck. Oh, and they need to look really nice and be easy to clean. Estimate that!

TL;DR: when hiring a programmer to develop a project, nobody wants standard IKEA.

That's fine if you:

• Never upgrade your tech stack.

• Always use people of exactly the same level of skill.

• Assume the project stops at implementing a static set of requirements given up front.

• Assume the requirements are correct.

• Assume there's no political dimension to the actual deployment and usage of the app, i.e. the project is just software and not a business change project.

In practice none of these things are ever true. The business doesn't want a CRUD app, it wants an automated process that it probably can't explain, will change half way through the implementation and some of the employees may resist deployment of the software. And people expect software development to get cheaper and faster over time, as with everything else in life, so you can't exactly ship a Visual Basic 6 app in 2018 because that's what you happen to know best so you can easily estimate work with it.

My point about software systems being less constrained than physical systems means that even ho-hum CRUD apps will likely have more unknown unknowns than a ho-hum dirt moving project. Also, the task of stating the requirements for a software system is much more involved than stating the requirements for a bridge or tunnel.

In short, I think there are very clear and tangible things that give software estimates a meaningfully higher uncertainty than other engineering disciplines.

Reply on news.ycombinator.com