I think comparing software development to traditional civil, mechanical or electrical engineering is flawed (apples and oranges).

When this guy claims they are doing something that has never been done before, they are taking orders-of-magnitude higher risks than any new sort of traditional software development project.

When's the last time you started a new software project thinking "gee, I wonder if this will explode into a giant fireball if my calculations are off?" No. You probably write your code, then run it, and if you see a problem you make changes and then repeat.

Does the fact that they are drilling for oil a mile below the surface of the ocean strike you as something quite magical? I'd say the entire drilling platform is an amazing engineering feat, and it likely requires a lot of wild-wild west engineering to make it a viable product.

I work on nuclear reactor monitoring software...

So, "melt into a superheated puddle of neutron-emitting slag", while not quite as dramatic as "explode into a giant fireball", is quite possible if the senior software and methods engineers at my company (and the many, many people the NRC involves in verifying and validating our code packages) collectively screw up.

Very true, but if that's the case you're probably writing some code that requires engineering (i.e. a control system or requiring an understanding of the engineering system that you're writing code for). If that's the case then you're probably wearing the hat of an engineer.

In "real" engineering, every project is slightly different. If they were the same, you wouldn't need an engineer. The engineer knows about many projects involving similar components, the details and the way they are put together will be different on each project.

Wholly new software projects are not as common as you seem to suggest. Genuinely new stuff gets published in journals (just like "real" engineering), not many software engineers are creating new type systems, file systems, concurrency models, etc.

Some engineering disciplines may move more slowly than others, especially those for which the cost of failure is extremely high, but it's not as radically different as you suggest.

Correct.

Also, what a lot of posters are forgetting is that software is involved in "real" engineering. The work BP is doing isn't happening by the seat of their pants; real numbers are being crunched, supplies are moving along the chain and simulations are running. It's not happening with slide rules and ledgers either: there are software applications enabling all this work they're doing.

A significant portion of physical engineering these days is delegated to software and it needs to engineered properly just like the rest of the system. If the software controlling a chlorine extraction process fails and vents toxic gas, the result is every bit as tragic as if a mechanical engineer had specified the wrong pipe material and that was the fault that released the gas.

I would like to point out that systems that control physical equipment frequently fall into the domain of electrical engineering as much as they do software.

I'm not sure what you mean by this.

I write code that directly controls physical equipment. I work specifically for the Software Development department and we are the only people who have control & responsibility for software. While the electronic aspect of the systems are controlled by our EEs, Software has complete responsibility for the code.

The stuff "real" engineers do is at the limits of what is possible for human beings as a species to do - go higher, go faster, go deeper, be stronger, last longer. That's what he means by "never been done before". He means "wasn't physically possible for anyone on the planet yesterday". Is that not magical?

And if it goes wrong, it really goes wrong, as the Deep Horizon leak illustrates. If your "novel" RoR application doesn't work, no-one cares, you tweak a line of code and try again. Big deal.

> If your "novel" RoR application doesn't work, no-one cares,

Not true if you have lots of users, just ask Twitter. Fortunately, a Twitter outage does not cause massive ecological damage.

I think this is a mis characterization. Mechanical engineering is a much older, much more mature field than computer science/software engineering. As a field of engineering study matures, many of the solutions to possible problems become commonplace, or at least they become trivial. New problems to solve are less and less frequently actually new, but rather just novel deviations from a commonly solved type of problem. However, capping the well is a completely new type of problem. It is one that has not been solved so many times that accounting for all of the variables is easy. Think about that next time before you criticize other disciplines.

The "oil rig engineer" sounds like not a actual rig designer, but engineer in the sense of "sanitation engineer" or such.

Software development is a form of design engineering.