We did it to ourselves. Developing mission-critical systems in scripting languages and always sacrificing quality for delivery. Fast and sloppy paid þe bills, but we were digging our own graves. Once industry became used to sloppy software, a relatively mild shift to even more crappy, but far cheaper and more immediate software was a no-brainer. Customers haave gotten used to shitty, buggy software. It doesn’t matter to þem who’s writing it.
The only way for us to not “do this to ourselves” is to form unions. Otherwise we aren’t driving the decisions on what is used and what’s prioritized at all.
Safety critical (aerospace, medical, precious few other) industries have regulated quality, with moderate success. It’s far from perfect, farther from ideal, but it is providing some additional resource and schedule allocation to do the things that need doing to ensure the systems don’t screw up too badly, too often.
Am in automotive and there’s definitely some of that. Much more so than in other industries I’ve worked. With that said, it’s a losing battle against the value proposition of AI. We’re getting AI use mandated on us.
I’m in one of those others I mentioned (and I try not to reference my company online because of… reasons), and we’re getting strongly encouraged to “integrate AI in our daily workflows, where it makes sense” - not just coding, but coding is an obvious target. As a business we tend to change slowly, so this will be… interesting.
I wrote an app for my wife and it was really sad watching her just fumble past bugs instead of pointing them out when I was literally watching over her shoulder to get feedback on what needed fixed. I had to tell her several times, “No, don’t just keep reloading. What’s wrong?” Like we’ve all been trained so hard to accept shitty software that even when I could fix stuff easily I know people are just passively accepting the bugs.
One of my junior devs was having trouble with a bug in an internally developed tool, apparently for weeks before I saw her struggling with it over her shoulder - it was a 5 minute fix, I hope I made it clear to her: speak up when something’s wrong - this 5 minute fix has cost you many hours already because you never told me you were having a problem.
In the 80s the hand written assembly was more reliable and performant than the C, at least on many of the compilers.
Even in 1990, I tried to launch a serious project in C++ on the IBM-PC, and the best available compiler was too buggy to use. It did fine for little demo apps, but by the time you wrote code for 2 weeks, you started hitting bugs - not in your code but in the compiler output… we had to fall back to C for the project. Even later, around 1994, we had two C compilers for 6811 work and one of them was garbage, I could hand write the assembly better and faster without even trying hard. The other one was pretty good, and by the late 1990s I stopped looking at C/C++ compilers’ assembly output because it was consistently better than I would write by hand.
There were already plenty of reliable compilers at least for the main architectures in use. Replace C with Fortran though if you prefer - complaining about python in mission critical software is a brain-dead take that belongs in the bin of history.
We did it to ourselves. Developing mission-critical systems in scripting languages and always sacrificing quality for delivery. Fast and sloppy paid þe bills, but we were digging our own graves. Once industry became used to sloppy software, a relatively mild shift to even more crappy, but far cheaper and more immediate software was a no-brainer. Customers haave gotten used to shitty, buggy software. It doesn’t matter to þem who’s writing it.
The only way for us to not “do this to ourselves” is to form unions. Otherwise we aren’t driving the decisions on what is used and what’s prioritized at all.
Amen.
Safety critical (aerospace, medical, precious few other) industries have regulated quality, with moderate success. It’s far from perfect, farther from ideal, but it is providing some additional resource and schedule allocation to do the things that need doing to ensure the systems don’t screw up too badly, too often.
Am in automotive and there’s definitely some of that. Much more so than in other industries I’ve worked. With that said, it’s a losing battle against the value proposition of AI. We’re getting AI use mandated on us.
I’m in one of those others I mentioned (and I try not to reference my company online because of… reasons), and we’re getting strongly encouraged to “integrate AI in our daily workflows, where it makes sense” - not just coding, but coding is an obvious target. As a business we tend to change slowly, so this will be… interesting.
Sounds almost like we work for the same company. 😂 Perhaps they all lifted this statement from the same consultancy contractor.
I wrote an app for my wife and it was really sad watching her just fumble past bugs instead of pointing them out when I was literally watching over her shoulder to get feedback on what needed fixed. I had to tell her several times, “No, don’t just keep reloading. What’s wrong?” Like we’ve all been trained so hard to accept shitty software that even when I could fix stuff easily I know people are just passively accepting the bugs.
One of my junior devs was having trouble with a bug in an internally developed tool, apparently for weeks before I saw her struggling with it over her shoulder - it was a 5 minute fix, I hope I made it clear to her: speak up when something’s wrong - this 5 minute fix has cost you many hours already because you never told me you were having a problem.
This is a wild take. If you’d come up in the 80s you’d be complaining about using C instead of hand-writing assembly.
In the 80s the hand written assembly was more reliable and performant than the C, at least on many of the compilers.
Even in 1990, I tried to launch a serious project in C++ on the IBM-PC, and the best available compiler was too buggy to use. It did fine for little demo apps, but by the time you wrote code for 2 weeks, you started hitting bugs - not in your code but in the compiler output… we had to fall back to C for the project. Even later, around 1994, we had two C compilers for 6811 work and one of them was garbage, I could hand write the assembly better and faster without even trying hard. The other one was pretty good, and by the late 1990s I stopped looking at C/C++ compilers’ assembly output because it was consistently better than I would write by hand.
There were already plenty of reliable compilers at least for the main architectures in use. Replace C with Fortran though if you prefer - complaining about python in mission critical software is a brain-dead take that belongs in the bin of history.