Imagine if a structural engineer whose bridge has collapsed and killed several people calls it a feature.

Imagine if that structural engineer made a mistake in the tensile strength of this or that type of bolt and shoved it under the rug as "won't fix".

Imagine that it's you who's relying on that bridge to commute every day. Would you use it, knowing that its QA might not have been very rigorous and could fail at any point in time?

Seriously, you developers have all kinds of fancy stuff like Continuous Integration, Agile development, pipelines, unit testing and some more buzzwords. So why is it that the bridges don't collapse, yet new critical security vulnerabilities caused by bad design, unfixed bugs etc appear every day?

Your actions have consequences. Maybe not for yourself but likely it will have on someone else who's relying on your software. And good QA instead of that whole stupid "move fast and break things" is imperative.

Software developers call themselves the same engineers as the structural engineer and the electrical engineer whose mistakes can kill people. I can't help but be utterly disappointed with the status quo in software development. Don't you carry the title of the engineer with pride? The pride that comes from the responsibility that your application creates?

I wish I'd taken the blue pill. I didn't want to know that software "engineering" was this bad, this insanity-inducing.

But more than anything, it surprises me that the world that relies so much on software hasn't collapsed in some incredible way yet, despite the quality of what's driving it.

When the need for "someone to do the job" is greater than the amount of people who can do it properly..

Well to be fair look at the self accelerated cars from a few years back, so the world was falling down at that point cause of shitty coding

Because software for the general public doesn’t have the risk of endangering lives, so although we have 1000’s of buzzwords and ci/CD tools, finding people that can use them well vs people that know how to login and press a button is hard to come by.

The other issue is management typically don’t see software (including web) as a difficult job, so they’ll keep throwing buzzwords around and expect their team(s) to just get on with it as if it was like reading a paragraph of text and bam - genius mode unlocked. Hmm maybe these guys/gals watched the matrix a few too many times.

Software that is critical has mandatory QA depending on the criticality level, like medical or airborne.

However, it is quite expensive to do that, and consumer software would by and large not exist if subjected to that level of quality.

Just to get an idea, you can easily multiply the pure coding time by a factor of 10 to get the total time, and that's still entry level.

@C0D4 I'd argue that certain types of software certainly could endanger lives, but indeed the most damage isn't life-endangering.. at least not directly. For example data leaks, which could be considered very endangering to the social status of those affected. Or a buffer underflow on my debit card that went negative for some reason and suddenly makes me a billionaire. If I decide to cash out quickly, that'd have a huge impact on the bank that I got it from. Not that I'd get very far before I get sued into oblivion for doing so, but you get the idea, right.

I'm not arguing that all software needs to become ruggedized (although BSD did an excellent job with that, very impressive how little security flaws they've had so far) but the disconnect between marketing, HR and the developers really needs to be solved.. development can't be done quick and dirty because then it won't be done well. But perhaps it's just ignorance on the marketers' part? Do they really know any better? Developers are pushed way too much and that combined with the scarcity of good developers is a really bad thing.. but those aren't insurmountable issues that can't be solved with dialogue, right?

@RantSomeWhere nah, just the tired Condor currently.. hence why this rant is so low on swear words I guess 😛

@RantSomeWhere I'd say that it's sometimes already too much innovation, and it lowers the quality. Especially seen in web where the pace is so fast that by the time a dev is expert in something, it falls out of use. Hype driven development forces many devs to eternal noobness.

If the structural engineer had to design and build every piece the bridge is made of by hand, everytime they build a bridge, your comparison would hold.
But the bridge builder has hundreds of people, building on centuries of experience and research.
The software engineer has too often too little time to build something too new with too few people at hand.

I can only speak for myself, though. And what I have given into production until today, was always rock solid. And some of my software products are used by thousands of people on a daily basis.

Nevertheless you have a valid point there!

I mean as others already have kinda pointed it out. Most software today is not safety critical in a sense where it would endanger lives.

But software which is in the same category as a bridge like aerospace, automotive, etc. has to undergo tons of paperwork, specifications, code reviews, etc.

There are quite a few standards for different industries, and if you are really designing/writing safety critical software, "move fast and break things" will definitely not fly.

Ship fast mentality is the cause of it.

Most of Japan development companies have to follow ISO standard for all their projects. They generally don't use any trending frameworks or tools with most stars or most downloads on GitHub. They have shit tons of documentation. They focus annoyingly much on long term quality.

If development companies from US practice 1/3 of above, I'm sure you won't suffer this pain 😁

Having worked for Civil Engineers on some big projects, it's called redundancy; they know they are fucking up all the time, they just rely on the fact that it "probably" won't kill anyone, because "it shouldn't".

My friend is a mechanical engineer; my other friend a valve technician. Most of their days is spent swearing at each other, and 90% of what they do doesn't work, but get's sold anyways.

Dont worry @Condor, most engineers are surprised that most structural infrastructure hasn't collapsed in the same way most software eng are regarding the tech scene.

We give bridges years to build with all proper materials n equipments, with all battle / time tested design, with right people for the right job n proper financial budget. Bridges do fall if anything skipped.

One examples I remember is software was developed like above in Bell Labs.

If we are skipping things left right n center, why wonder?

I actually feel I have to add one more thing; my uncle is an Aerospace engineer for a prominent manufacture of planes. They are superglued and shimmed to fit, since all the pieces sent from China are invariably off in some way, meaning they don't fit together properly. Happy travels.

From my experience, faulty software is often the result of its architecture (or lack thereof). In that respect, software engineers should definitely be as involved as structural engineers in how the software is architected and designed from both data flow and infrastructure standpoints, not just a focus on code quality or latest technology. It also shines a light on its long-term maintainability and security.

I agree that the "move fast and break things" mantra should not be practised at all for commercial software (or any software that involves monetary transactions or customer information). But I'll admit it has its place in hackathon experiments and proof-of-concepts, but up to that point only.

Faulty scrum implementation without understanding is one of the cause.

@evilcoder Depending on what's edited it might get you killed or divorced

@irene original version 1 agile is not cancer. Current agile probably is.

Good metaphor.

There is more than one reason why our sw might suck.

- legacy projects started back when security was not a problem. Hence the design is buggy
- legacy projects started as one-man-tool or maybe a PoC, which later grew to a massive beast the initial design was not meant to support
- projects started without all the pipelines, agile, etc. - all the bells you've mentioned
- projects whose owners are cheap and end their sentences 'just make it happen', ignoring devs' warnings about inevidable losses of some sort, be it sec, stability, data fckup, etc.
- projects whose scopes change 3 times a day
- projects that have not been covered with tests as business was forcing to 'make it live in a month'
- projects that have no maintenance purchased hence no bugs are to be fixed after going live. Happens more often than you'd think. Development is not charity, if owners are not paying for your work no sane dev whould ever do any improvements on his own time, on his own dime.
- you've found a corner-case bug that noone has thought of. Automatic tests are still written by people who have to think of ways code could break and try to exploit that. It's quite impossible to cover every possible case there is :)
- the dev was tired/sloppy/inexperienced and made a mistske [human error, dev's fault]
- the dev was being constantly distracted by juniors, managers, qa, analysts, wtv and made a mistake [human error, not dev's fault]

There are many more possible reasons. Every time you find a bug or hear of one, remember, that behind every dev there is an army of managers, owners and funders who tend to restrict devs from doing things right. On top of that, devs are human, and human tend to make mistakes.

Builders cheat, cut corners. Put in cheap things that might break after a few uses. Not killing but still crap.

Not many years ago here where a building collapsed, they had used thinner material than the standard/regulatory requirement.

Link, although in Swedish but your preferred local nordic guy or translatorsoftware could help https://sv.m.wikipedia.org/wiki/...

This deserves more upvotes.

One is careful when working with robots though that could hurt people if they do something wrong. Here only real world testing and experience halps. And emergency buttons. Unit testing can't do much here unfortunately and simulation is not even close to the real world

Yearh, I also think wenn need more Q&A but I doubt that most devs choose not doing it.
In my opinions it's a problem of not having enougth ressources and to tight deadlines.
It's hard to convince non devs why you need testing or more time for testing because it isn't something you can see directly.

We should explane better and more often why's important to spend this "extra time" for Q&A even if it looks like everything is finished.

But I agree if you can and choose skipping testing you should rething your actions.

(Sry if my english isn't the best)
Bonus:
At my university we learned not really how to code. We just hade to submit something working.
At my 5th semester they launched a new cours "IT Security" where we had our first contact with "good and save" code practice. It's hard to change the coding style you are use to but it was eye opening.
And if you have to "learn by googling" this whole subject often get never touched.

Looking back even the sample solutions were the minimal solutions at all.

I can just speak for my german education but if you teach IT you should teach good from the beginning and maybe focus a bit more on the security side of coding. It's not a web tutorial it should ne the best education for this subject.

@cursee
Got to look for more japanese software for myselfe 🤔

@bootleg-dev
If you look at some of our german carmakers. They do know how to build cars but in the past they pretty much fucked up most software integrations.

@Niss Not sure what you exactly mean with "fucking up software integration". But generally I think automotive safety critcial software has show an good track record in the past. (With exemptions like Toyota, Tesla, etc.)

My main point was, that there are procedures and standards to make software reliable and safe where it matters. It's not like some intern is gonna write some ECU code tomorrow in a new programming language he discovered. But yes, in less critical software the quality is often shit. (And I'm aware that some software is actually more critical than it appears at first glance).

It's also a matter of cost. In "The Practice of Programming" (highly recommended!), Pike and Kernighan state that the difference of effort between code for personal use and production ready code is one or even two ORDERS of magnitude.

Though I find that thorough error checking and proper validation of any kind of input data actually speeds up development because you see immediately when, where and how something doesn't work as expected.

That's why we are developers not engineers. Engineers com from uni, we come from the internet.

@estinf software was already crappy before the internet was a thing. I was there, three thousand years ago. I was there the day the strength of devs failed. Uhm no, wrong movie, but in the 80s, which is not that much more recent.

@Niss that is because they outsource those things, but being contracted by a German car maker is pure hell!

@irene BMW and Mercedes Benz went negative on the topic through our media

@irene BMW and Mercedes Benz were mentioned in our news that they have multible security issues in there new models. One of them could be completely shut down while driving it.

(In german):
https://google.com/amp/s/...

@Niss BMW's "connected drive" has been "connected hacking" for years. They don't know jack shit about software.

Not digging the comparison. Software in things that shouldn't fail (medical equipment, planes, cool space stuff, etc.) usually don't, because it's important that they work so we build accordingly.

You decide how much risk you're willing to accept vs the cost of reaching that level of safety according to what makes sense business-wise. You don't spend 10 years putting down a plank that will get you across a small stream and you don't build x-ray software without competent people and practices on all levels.

Just want to add to my previous post that I made it sound like it's usually a conscious decision to build buggy things. I don't believe that, I think that most bosses and managers are clueless and short-sighted and it's a miracle that the software world is running this good. Idk, also a bit tired, excuse my sudden burst of optimism :D

@ihatecomputers yeah, that sounds pretty reasonable actually. Probably it's the same in software as it's in other industries, consumer goods are cheap shit and industrial/mission-critical stuff is prohibitively expensive but quite Skookum. I mean aside from the price bump from marketing wanks and brand name of course.

As for management and cheapskate clients.. yeah I can see how that'd work out to cheap shit.. I mean you don't always get what you pay for, but you never get what you don't pay for ¯\_(ツ)_/¯

To add to @ihatecomputers who definitely spoke my mind: bridges do fall, so do other buildings (did you check the Brazilian news lately?)

In the Roman empire bridge engineers had to stand below their bridge on the opening day when the first carts crossed it. This ensured they were built properly. 😉

@Yamakuzure Is this the equivalent of releasing on a friday afternoon? I'd be the most dead bridge builder in the history of dead people.

Those issues are easily reproduceable if you really want to go that way.

@vlatkozelka hmm, makes sense.. thanks for explaining!

Well, bridges collapse (eg https://bbc.com/news/... ) and software kills too: https://en.m.wikipedia.org/wiki/... - but yeah our field is usually weak on the systematic, structured, theoretic side - wondrous how they can even talk of computer "science"

A bridge is built in years, software in hours.

I used to have a long list of software failures that caused humans harm, death or financial issues. Nuclear power plants, military projects and factory machinery topped the list. But that was in the 80s. By now, that list would be an enormous book