Hacker News Reader

Comment by jasode | Hacker News Reader

>projects delivered precisely what they said they would, and in the timeframe they originally promised.

Those factors are "project management" which include concepts like "scope", "budget", and "critical path".

It's arguable if those are "engineering". They certainly affect engineering. (And likewise, some engineering constraints can feed back into project planning and feasibility.) In any case, project planning is a separate area of study. Using the author's strange definition of "engineering", it means the NASA Space Shuttle is "not really engineering" because it didn't deliver to the specifications of 50 launches per year at low cost.

A more reasonable definition of engineering that most could agree on would be, "the study (or art) of balancing technical tradeoffs against real-world constraints".

View on HN

As I'm commenting elsewhere, this is true... I didn't acknowledge that other physical engineering projects do indeed suffer from some of the main problems. What's missing in software engineering is the rigour and ability to reason so precisely about what's being built. I was originally taught (on a Software Engineering degree course) that it doesn't formally fit the definition of engineering, and I've not seen that change much, but I'd agree the definition is certainly up for grabs, and perhaps extension to include modern software practices, such as Agile.

> What's missing in software engineering is the rigour and ability to reason so precisely about what's being built

That's only true if you choose for it to be. There are ways to formally prove that your software is correct but they require a large time tradeoff. For example, the software in the chip in your car has gone through as much engineering rigor as a bridge. Alternatively, look at a cheap toy produced in a shitty factory in an undeveloped country. It will have parts in it that were designed by a mechanical engineer but they choose to be less rigorous to keep cost savings low and as a result you get a toy with "bugs" in it.

Very true!

Relevant:

http://www.edn.com/design/automotive/4423428/Toyota-s-killer...

Screw-ups happen in traditional engineering one story I was told at college was using the wrong fixing for attaching steering wheels leading to cases of the steering wheel coming away from the steering Colum whilst the car was in motion.

And the civil engineers I used to work for had a bridge fall of its supports :-) I had to reverse engineer some software to help find the reason for that.

For example, the software in the chip in your car has gone through as much engineering rigor as a bridge.

We'd like to think so. I currently do some work for a static analysis company that has many, many customers in the automotive industry. The MISRA rules are part of the standard package bought by these customers, and an awful lot of MISRA violations will be caught by the analysis.

Then you get the example of Toyota, who I am pretty sure are one of the customers of my current employer (and some of their subcontractors/suppliers are also customers). They definitely had the opportunity to identify the failings in their software (some of which would definitely have been caught; recursion, for example) and either ignored the results, or just plain didn't bother.

Reply on news.ycombinator.com