Ask HN: What is the Holy Grail for Software Engineering?

Physical construction envy is naive.

Many bridge-building projects go over time and over budget.

Most bridges have a feature list fixed years before construction is begun.

Bridges are static. Even draw-bridges do not adapt to their environment automatically, but require human intervention.

There is a categorical error when you try to apply construction practices of static things to the construction practices of dynamic things, hence the failure of waterfall. Note that the original papers that introduced waterfall actually suggest a system that more closely resembles iterative development than BUFD.

> There are a lot of things wrong with this analogy

I think so. As a rule, when something can be developed incrementally rather than planned and engineered, it should be. This makes mistakes less expensive, allowing you arrive at a satisfactory end result in a fraction of the time.

This is one of the huge advantages of the web over desktop software. Initial delivery to the desktop and subsequent updates cost significant time and headache. Redeploying to the server is just a matter of running a script.

I think the bridge analogy can work a different, equally effective way: we can build software based on well-established and tested engineering principles, with tools and materials that have a known, verifiable set of behaviors.

I'm not a materials/mechanical engineer, but it seems that engineers can build bridges properly the first time (most of the time, right?) because they are working against a set of well understood, well tested physical laws (for lack of a better word). Even I write the perfect, say, shopping cart application, that bit of software still relies on programming frameworks, web servers, operating systems, and hardware systems that have known issues.

If bridges were like software, as soon as a drunk driver ran through a bridge's guard rail the designes would have to follow up with a post that started, "We had some downtime from an accident, here is what we're going to do about it..."

Let us not conflate computer science with software engineering.

Vinge's "superhuman intelligence" rhetoric bothers me because it suggests that intelligence is a one-dimensional quantity. I don't think this makes sense except in the context of specific domains. For example, a basic calculator has superhuman intelligence when it comes to arithmetic, because it can evaluate arbitrary expressions much faster than a human can and doesn't make mistakes. But it's dumb about everything else.

Update: The child comment by binaryfinery points to where Vinge addresses this. Sorry, I failed to add the disclaimer that I only skimmed the article.

While I agree those are worthy goals, the middle two are CS, not SENG. Real AI is probably the loftiest goal in CS, but it requires a lot more theory work before anyone will be able to implement it.

Such system would be necessarily self-conscious with all severe problems it implies and human reproduction already produces such systems.

These are computer science, not software engineering.

Oh, and #3 is neither...