Thank you! I knew I couldn’t be the only one.
It’s also an economic one. Think history. In the early years of commercial electricity, there were X competing standards in the same city, and the average person was clueless about safety. (Electric tablecloth anyone? Just put the kettle on the tablecloth – literally anywhere on it – and it magically heats up! Mind you don’t spill any water though…) Yet people carried on like that, because there was money to be made.
Fast economic growth is both a blessing and a curse. 
I’m pretty sure this is what it boils down to. If you sell something that looks awesome but is, in reality, slightly crap, you’ve actually locked in your customer base; they’ll carry on buying your next model and your next model in the hope that it’ll work properly next time. IMO there’s a “sweet spot” of crappiness that achieves this. The product must work just barely well enough that the user doesn’t just drop it in the toilet and flush, but not well enough that he’s going to be happy with it for the next six months.
I was tracking to the Dylan part, then this post ceased to make an ounce of sense for me. But I will agree, times are a changing…
Yes. But we got the job done within those constraints.
That was precisely my point. 80% of those complex systems are doing nothing radically different to what we did 30 years ago, yet they’re using millions of lines of code to do it instead of thousands. So bugs, inevitably, increase.
NASA, I think, did a study on this in the 1970s, and found that regardless of anything you do with methodology, there is an absolute lower limit to the number of bugs, proportional to lines of code. This is one reason why avionics systems use “out of date” hardware and software - not only is the hardware inherently more reliable, the software that runs on it inevitably has fewer bugs.
It’s a very modern form of laziness. Why try to get your product into a 1MB footprint when you can sprawl out over 100MB? It’s the engineering equivalent of calling Pizza Hut for takeout instead of cooking a proper meal, and the result is similar.
yeah, I use those. The thing is, though, we got away with little bits of paper because we had fewer bugs. People only need those tools because the blizzard of bug reports would otherwise be overwhelming.
Bug-tracking software gives developers the illusion that as long as it’s logged in the system, they’ve done something about it. In reality 95% of the bugs just sit there at low priority, never being dealt with. And anyway everyone knows the code base will be thrown away next year to incorporate the latest whatever-it-is middleware with a silly name, so why bother?
The fact that anyone can actually compile such a list in a human-readable form suggests that the problem wasn’t too bad. Also, I’m drawing a distinction here between bugs that make the user’s life a misery, and occasional annoyances that don’t interrupt the workflow.
There are multiple reasons why it HAD to work. A big reason was the cost of fixing problems. Not so long ago I was sending out products with software in OTP ROM. The binaries were in the 1K-2Kbyte range. And they were zero-defect. I’ve just rebuilt that product using C on an ARM Cortex-M0, with a bunch of manufacturer-supplied libraries underneath. It’s shit. Some of that is because of me and some of it is because of them, but it’s gone through multiple iterations and occupies about 20Kbytes of flash.
Never used it, but VMS was one of the most solid software products I’ve ever used. It had to be - we were running stuff that needed 99.999% uptime.
Part of my gripe was: do we actually need to do any of this stuff? Is it really that important? But look - we were doing that. I worked for BT. Yes, the bitrates were a whole lot slower, but the function of the product was about the same. We knew how to build videoconferencing that worked (although we never sold any because the technology was too expensive). There’s nothing inherently bug-generating about “decoding radio signals” etc etc - a lot of that stuff runs on hard logic in ASICs and FPGAs anyway, not in software. And it works. It’s the garbage on top of it (Android etc) that doesn’t.
Yes. A lot of my university stuff has been having issues. Bank was doing maintenance for a day as well.
Complexity is the cancer of modern Software Engineering.
- Our system is too complex! Let’s split it up into microservices to better handle the code.
- Microservices need too much administration. Let’s automate it! Container! Docker!
- Docker needs too much administration! Let’s automate it! We do Kubernetes!
- Kubernetes need too much administration. Let’s automate it! We do Ansible!
- Ansible need too much administration. Let’s automate it! We do Chef / Salt!
In the end you have a monster nobody fully understands and all effort is used to keep it alive. Fixing bugs is not a priority.
After a few years the company only knows how to push a button to get binary. Nobody knows how anything works.
But don’t reinvent the wheel! Use that library that only has 1435 dependencies. Nobody checked the code of those and knows the people who maintain it. Then you find a bug and trace it down to a dependency. Good luck getting the maintainers to care about your use case.
Loosely translated from here with my own additions.
So many buzzwords. So many mediocre minds in software, just following like sheep.
Actually a bug in dependency 1435/1435 is one thing, maybe you can vendor the fix, but what if it is a security flaw, and what if your product is a crypto wallet? (happened).
So what is your complaint about cryptocurrencies? They work just fine for me.
Haha I immediately thought of Fefe when I read that.
I’m super thankful I didn’t go into software but hardware… Shit here is also shitty and can be complex, but I would guess still 100x less complex than such multilayer software constructs.
Sorry, please continue the Boomer vs. Millennial fight, don’t mind us bystanders.
There are lots of terrible tools, libraries, and languages around these days, but there are lots of great ones too. I don’t think the technology is really the issue.
I think Finley touched on the real problem when he said that most old software had to work. Here’s the thing: most modern software doesn’t actually have to work. Most of it doesn’t really do anything important, and anyway we’ve trained humanity to expect it not to. And it’s much, much cheaper to write software that mostly works than software that always works. So by market forces, that’s what we get.
Most companies have no idea how to create quality software. They have a boss working in marketing that write the specs. Their CIO having it estimated and settings up the budget. Their HR hiring people on Fivrr or in downtown India/China and they then cross their fingers and hope for the better. None of them know how the internet works.
When the software doesn’t work you know the management is broken. Just avoid these companies and go to a competitor if you can.
Also some culture just don’t value quality at all. Their house is broken, their streets are broken, their system is broken, and it’s just fine. They then start coding and the result is the same. Broken.
There is no solution for that except having a very big and efficient QA team between the developers and the clients. Or a complete change in management.
Is the internet kaput?
Ja.
Don’t know what you’re talking about, works fine for my team. Using docker+k8s automates deployments and makes updating system much easier. Local development is simpler too.
Making microservices to reduce complexity just moves it elsewhere. Communicating between services becomes really annoying. But it does help with redundancy. The concept should be used sparingly to take certain, critical components from monolithic system out so they don’t go down with the ship.
In the end you have a monster nobody fully understands and all effort is used to keep it alive. Fixing bugs is not a priority.
After a few years the company only knows how to push a button to get binary. Nobody knows how anything works.
Automation is good. Usually what you get is one guy who has a process that no one else knows so when they get hit by a bus the knowledge is lost. Configuration is documentation in itself, and automation is what computers are good at. Why would you make the steps manual on purpose when the human factor will screw things up regularly? It works great for my team and most of the time is spent on fixing/improving code. Every once in a while have to restart deployment because an image failed to build while repo indexes were being updated, but that aside it works 99% of the time.
That said, you should always keep an eye on the layers of abstraction. There is only so much you can keep in your head at the same time. Don’t let this be you.
Like I mentioned, this is from a well knows security expert in Germany. He audited many big companies software projects in Germany. So he has seen some real life examples in the wild.
Not every project using new technologies is doomed as long as the managers have technical understanding instead of applying buzzwords they were pitched.
Do you use blockchain and AI already? 
I had a .NET framework update just now and it worked again.
I can’t find much here to disagree with. There’s nothing inherently bad about new technology or big systems. In the hands of competent people, things will probably work out fine. Two things, though:
-
Most of our supposedly modern technologies are ancient. Good managers can make good use of them (and know when they are/are not appropriate) because they’ve been using them for years. We were using automated test harnesses 30 years ago. We had Cloud-like distributed processing and storage. The Apollo mission computer ran a virtual machine. But people just can’t seem to stop themselves reinventing the wheel in new and shittier forms (Java being a prime example).
-
The rise of the “coder”. Modern application frameworks frequently sell themselves with some form of “now anyone can write code” sales pitch. Well, yeah. Anyone can write code in the same way that anyone can build a bridge with 2x4s. The end product might look superficially like the real thing, but it sure as hell won’t perform like it. @mochigome said much the same thing back there.
Your whole gripe is about increasing code - yes we do need it. It is important. Because we’re not stuck in the 50s.
No, things didn’t work “solidly” back in the days. It’s just that testing wasn’t great. Here’s a bug uncovered after 30 years: And you need the millions lines of code.
Do you think it wasn’t exploited before or used to someone’s benefit? Ofcourse it could be. But we didn’t know of the problem till now.
Here’s right now, where IBM mainframes cause errors:
Just sloppy programming on part of IBM… so it doesn’t “just work” - you didn’t stress the system enough, that’s all.
FYI: all code will have bugs. It’s impossible humanly, to write error free code always. Important thing is to uncover them, and learn - and we’re doing that in much better ways today than before.
Just because it “had” to work doesn’t mean it “did”. Even today, everything has to work - doesn’t mean it does or will 100% of the times. That’s just not possible.
zero-defect: now you’re being delusional.