Live data from Hacker News

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

news.ycombinator.com

31–40 of 40 posts

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

#32
post #7

Enterprise software perspective - IT managed directly by business users. In that, the system can accept natural language descriptions of business logic, resolve ambiguity, and can self-modify, maintain, and heal itself. In other words, a virtual software architect.

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

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

#33
post #9

Building software like we build bridges. There are a lot of things wrong with this analogy, but I think it still encapsulates a nice ideal. We'd like to get it right the first time, and make it last with minimal maintenance. (This is for software engineering, not computer science)

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..."

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

#38
post #9

Building software like we build bridges. There are a lot of things wrong with this analogy, but I think it still encapsulates a nice ideal. We'd like to get it right the first time, and make it last with minimal maintenance. (This is for software engineering, not computer science)

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 dynam…

If we found a way to make BDUF work reliably, it would transform the industry overnight, and turn software development into a recognisable engineering discipline. The fact that we haven't yet, and that one particular approach failed, doesn't mean that it isn't possible. Nor does it mean we should stop trying.

Iterative development is an interesting stop-gap, but it's certainly not the be-all and end-all we should be looking for.

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

#39

Earlier quoted context omitted.

> 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 signific…

"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 a server is just a matter of running a script." This raises a good point about reuse. You wouldn't try to re-use the same bridge across a different span without modifications, but we require our software to run in different contexts (be it diff…

Within reason, you definitely can: http://www.army.mod.uk/royalengineers/equipment/704.aspx

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

#40
You know that scene in Independence Day when Jeff Goldbloom flies into the mothership and uploads a program to shut it down? That.

No, I don't mean an alien empire running on Mac OS 7.6.5, I mean extreme interoperability so software can rewrite itself to work on a different platform (self-porting, in other words).

Having said that, their firewalls were lacking!

Post reply on HN