[redcap]

The problem I have with "software engineering" is that it's not real engineering. Sure you might do thinking to create proper requirements, design, build a prototype, build the real thing and iterate, use agile or whatever.

But comparing programming to actual, real-world engineering is a different kettle of fish. Engineers make things with actual physical requirements - if they're not met, people will die. You're not going to be doing proper engineering unless you can sue the engineers for the wholes in their software that caused people to lose money from their bank. Sure it works and may well solve a problem, but it's not engineered.

Real software engineering is using formal methods to do your utmost to prove that your stuff actually will work (Intel does that for some of their chip development) or make 5 different control systems for your rocket and have them vote on the correct course to add extra backup to prevent fuckups (NASA did this for the Apollo iirc - the EU Ariane didn't, so they had a rocket crash at one point).

Until that happens, you're just going to be developing sandcastles - you're going to have buggy software that will break at some point - because software development is so fast that it's not worth the effort to engineer from the get-go.

In other words, coding is coding - you can have good coding that uses best practices - but if you call it engineering you're deluding yourself in most cases.

[danso]

Er...what...?

Bad code won't kill people? I think any longtime reader of HN can think of a few real-life stories that would contradict this.

I studied computer engineering and yes, I remember those of us more on the hardware side thinking the ones on the "soft" side of the engineering were the lazy ones. Having been more involved in programming projects since then, I've seen the great value in being able to "engineer" software that meets highly specific specs and anticipates future needs, upgrades, and maintenance. Neither of those are necessarily related to good programming, and the failure to achieve both in mission-critical software will lead to deaths

* and as far as I can tell, "real" engineers do not get individually sued for physical failures, unless there's a rare instance in which an individual engineer can be proven to be malicious or grossly negligent.

[redcap]

I was thinking more of the web stuff that people do, so may be overstating my case. There are cases where you really need to make things safe - NASA's Apollo rockets and medical equipment to name a few. Also, when I talk about suing engineers I meant suing a big company such as Microsoft for the glaring security problems in earlier versions of Windows. Some Windows machines would be hacked within minutes of connecting them to the internet - in my mind that's simply negligence on the part of the developers - them being liable for creating an insecure product would force them to develop a properly secure solution - in other words to actually engineer it properly.

Where you have a hardware-centric approach, I'd assume that the whole system, software included has been pretty well tested and engineered to a great deal.

But banking software and I postulate most software that hacker news contributors write is probably going to be inherently flaky in some respect. The main fault for this is that writing software is so quick and easy compared to creating something physical that will last.

It's due to the push to get something to market and the "easy" nature of software development that leaves true engineering discipline by the wayside.

Yes, you can be in a situation (especially when people's lives depend on it directly such as medical equipment) when you are properly engineering a solution, but I still stand by my premise that most software development is not software engineering - you're just making sandcastles.

[jarek]

> Some Windows machines would be hacked within minutes of connecting them to the internet - in my mind that's simply negligence on the part of the developers - them being liable for creating an insecure product would force them to develop a properly secure solution - in other words to actually engineer it properly.

If software developers were actually engineers, or at least some of them were and were required to sign off, they would actually have authority to influence decisions that had huge impact on this situation - deprioritizing of security, bad project management, etc, not originating from the development side of the organization.