[blippage]

Not only that, but we're now creating devices that depend on remote servers. It's completely obvious what the downsides to this are, yet we embrace it without question.

And why are moving to apps that only work online? Networks are slow compared to desktops. Programming seems to be the art of doing the worst thing possible. Our computers are getting faster and faster, but we're relying on communications that are vastly slower.

And another thing: Windows updates, or even Firefox for that matter. Software shouldn't be so full of problems that you need to constantly update it. Just update it every 2 years. Sure, you get the supposed latest and greatest, but updates are a messy process.

Perhaps the difference between programming and "real" engineering is this: parsimony. In engineering, you have to do more with less. In programming, the attitude seems to be to shovel more spaghetti onto the plate.

Update: I'll add a further point. It's not just parsimony, it's also cost of errors. In physical products, a flawed design that makes it into production is costly. So you have to get it right. With software, you can afford a slap-dash approach. And that's what we see.

[bitwize]

> Not only that, but we're now creating devices that depend on remote servers. It's completely obvious what the downsides to this are, yet we embrace it without question.

But there are upsides as well: the devices are usually attached to services for which the device acts as a conduit. If the service is valuable, you can sell devices and keep collecting money after first sale, driving huge margins. Didn't Hackernews post a lot of Fs in the chat for the original BlackBerry service -- one of the first devices of this kind to reach a mass audience -- once it was shut down?

[marcyb5st]

I think it's preposterous to expect that software that has millions of line of code (like Windows or Firefox) is perfect. Software Engineers are humans as well and we do make mistakes.

You could argue that we should adopt the same testing strategy of mission critical pieces of logics where 1 LOC has 1+ LOCs of test code, aim for 100% coverage, ... . But then your windows license would cost 1000s of $.

And about your final remark. What you call real engineering has to cope with well defined requirements and the context is well known. You know beforehand the maximum weight a bridge should be able to support. You know the configuration and properties of the soil where the bridge will be built, and you have good estimates of 1 in 100 year extreme events magnitude.

Software doesn't have that luxury. If we build a web server to handle 1k qps it still is somewhat likely that said server might face spikes of 10k qps. Try to do that with the bridge mentioned above. Forget failing gracefully. Additionally users have few ways to use the bridge. You either cross it by car / bus / on foot. The same web server might face someone trying to send a payload of GBs where you would expect few KBs. That's at least partly why code is messy. The space of possibilities is much greater and we somehow need to write software that still works.

[abernard1]

> The space of possibilities is much greater and we somehow need to write software that still works.

But the cost of failure is much lower, and that's why we as an industry can be so mediocre.

Physical engineering organizations have profit margins in the single digits to low tens. Software has margins in the 50s to 80s and marginal unit costs of zero. If any physical engineering organization had employees of the skill of our current SaaS software market, they'd be out of business immediately because no other industry but software can absorb such frequent and dramatic failures.