Becoming more than human.
Ask HN: What is the Holy Grail for Software Engineering?
11–20 of 40 posts
Re: Ask HN: What is the Holy Grail for Software Engineering?
#12There's really three problems I can think of, in decreasing order of difficulty: 1) writing an AI, 2) proving P=/=NP, and 3) founding a 200-billion dollar company.
These are computer science, not software engineering.
Oh, and #3 is neither...
Re: Ask HN: What is the Holy Grail for Software Engineering?
#13Users that read the manual
Re: Ask HN: What is the Holy Grail for Software Engineering?
#14Re: Ask HN: What is the Holy Grail for Software Engineering?
#15A general purpose memory manager that doesn't suck.
Re: Ask HN: What is the Holy Grail for Software Engineering?
#16Building 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 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.
Re: Ask HN: What is the Holy Grail for Software Engineering?
#17Building 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)
> 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.
Re: Ask HN: What is the Holy Grail for Software Engineering?
#18Building 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)
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.
Re: Ask HN: What is the Holy Grail for Software Engineering?
#19Minimizing the cost of producing secure, reliable, efficient systems that fulfill business objectives and are inexpensive to modify (where modifications preserve reliability and performance.) Included in the cost must be the risk of finding engineers to provide maintenance and changes.
Re: Ask HN: What is the Holy Grail for Software Engineering?
#20Building 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)
> 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 different web browsers, operating systems, versions of the language, et cetera.)