6 ms·

I don’t really agree with your premise. Software quality wasn’t pristine a few decades ago. It wasn’t hard to find messy codebases, apps that barely worked, and

I don’t really agree with your premise. Software quality wasn’t pristine a few decades ago. It wasn’t hard to find messy codebases, apps that barely worked, and developers who simply fumbled their way through code until something compiled. If anything, it feels like common softest quality has trended upwards as software engineering learning materials have become more widely and freely available across the internet and we have so many more open-source projects to learn from. > The one thing that's been pretty consistent is excessive technical complexity (aka tech debt). Technical complexity and tech debt are two entirely different things. Do you think it’s possible that you’re simply missing the “good old days” when computers did less, Software expectations were lower, and it was possible for a tiny team to completely understand and operate a useful software package by themselves?

timhrothgar 5y ago
Perhaps I should update the question. I'm not referring to ALL software quality. I'm referring to the quality of codebases that are 1) old, 2) large, and 3) supported by many people. You make a good point though. Perhaps I just miss the good ol' days of working on small teams with small codebases that were pretty easily maintained.
- wrs 5y ago
  Old large codebases are mostly maintained by people who weren’t around when the code was originally coming into existence. They don’t know the implicit design assumptions and decisions, or even the history of requirements. One thing you’ll find in nearly any software project of any age is a lack of good documentation of those things, so as you lose the community folklore, people will start making myopic changes, cargo-culting, violating future-looking design principles, and so forth. Pretty soon you just have a pile of incoherent features and making systematic improvements is hard because the code is no longer systematic.
- quanticle 5y ago
  Even with those caveats, it's unclear whether the premise is satisfied. The Linux kernel is old (old enough to drink!) large (and getting larger!) and supported by many people. Has its quality declined? I don't think so. It supports more hardware than ever. Kernel panics don't happen nearly as often as they used to. New features (BPF), make kernel programming easier. It's difficult to say that the Linux kernel's quality has declined over time.
  - timhrothgar 5y ago
    I had this specific example in mind. How has Linux done it? Was it ultimately due to the benevolent dictator for life (BDFL) management practice?
    - xxpor 5y ago
      The kernel isn't working on commercial deadlines. Maintainers don't have to worry about their stack rank at the end of the year. They don't have to justify their head count. Some of this happens internally I'm sure, at places like IBM, Red Hat, and Intel, but none of it is coming from Linus.
    - ssdspoimdsjvv 5y ago
      Probably that, and the average Linux contributor being a lot brighter than your run of the mill programmer.
      - 6510 5y ago
        If someone was to design a good small set of opcodes we could go back to rolling machine code by hand. While at it we might as well fill the atx box with cute tiny isolated computers that talk over ip addresses. They have to be small enough as to not leave space for an OS. Some ROM is fine ofc.
  - peakaboo 5y ago
    People being up the Linux kernel on the same way they bring up Oprah as an example of being successful in America. 99.99999% of software in big corporations will not have even 5% of the quality of the Linux kernel. The reason the kernel has such a high quality is because of Linux being a dictator, training everybody in not always so nice ways to write code that doesn't break anything and that is maintainable. He cares about the code and he has the status and the mandate to prevent it from becoming shit.
    - PragmaticPulp 5y ago
      > 99.99999% of software in big corporations will not have even 5% of the quality of the Linux kernel. Having done a lot of work on the kernel, I think you’d be surprised at the relatively low quality of a lot of kernel drivers. The core code is generally quite good, but it’s not true that the kernel is full of pristine code. I’ve worked at multiple companies where code quality standards exceeded a lot of the weirder stuff I’ve seen (and often fixed) in kernel driver code.
- peakaboo 5y ago
  You listed the reason it's a mess yourself - many people worked on it and it's old. For big companies there is no incentive at all for a developer to personally care about and do battle over things like code quality and reduce complexity. If they are use any kind of agile (lol) system, it will just be about polishing the turd so it doesn't break and add features in some way that doesn't require big rewrites.
- mbesto 5y ago
  > 1) old, 2) large, and 3) supported by many people. Software entropy implies that software that doesn't change will always suffer entropy if the environment changes. In a vacuum, we would never need to change software once it was "feature complete". But that's not how the world works. Environments change and so that inevitably means software will corrode. Candidly, I think you're just looking at the world through rose tinted glasses.
- com2kid 5y ago
  > Perhaps I should update the question. I'm not referring to ALL software quality. I'm referring to the quality of codebases that are 1) old, 2) large, and 3) supported by many people. Because Google[1] and Facebook came along and scared everyone by iterating at a LOLWTF pace and companies in surrounding spaces looked at what was taking up time in their release schedules and the answer was "test passes" so they fired all their testers, and told devs to add unit tests but unit tests don't cut it. Companies that used to have immaculate software quality had dedicated test automation engineers who had the job of abusing software in crazy bizarre ways. Then they hired armies of manual testers to go over anything that hadn't been automated. Lots of problems existing with this system, one of which was career advancement for software engineers in test was limited because it is hard to get recognized for the two primary jobs of an SDET: Signing off on code Blocking a release on quality grounds So you had a gradual rot of SDET and test orgs at companies, with pools of brilliance that slowly got drained as the best engineers got tired of being undervalued. Start from that base, and then around ~2010 everything needs to start "moving fast". Apple and MS both get rid of their test teams, and with two of the largest employers of dedicated software engineers in test getting out of the field, the entire field itself falls apart. Now it is career suicide, an ever shrinking career path that pays far less than doing "real" development work. That leaves us at where we are today. Everything sucks and breaks all the time. [1] Everyone forgets how bad the first 5 major versions of Android were.
  - mbrodersen 5y ago
    I have no QA testing and the code I maintain haven’t had a customer production bug for 5+ years. And we are taking complex software written in C++. The reason why is 90000 end-to-end use case tests. I routinely implement new features or refactor major parts of the application and the tests will tell me if it is ready for production or not.
trinovantes 5y ago
It definitely feels like survivorship bias. We only remember the good software of the past while forgetting the hundreds of buggy mess created by companies that are probably defunct by now
- tluyben2 5y ago
  Oracle?
  - cestith 5y ago
    Oracle is a marketing department and two law firms in a trench coat.
- rhizome 5y ago
  http://www.scriptarchive.com/formmail.html http://www.scriptarchive.com/formmail.html
- Gigachad 5y ago
  I wonder if people are forgetting that not long ago, it was acceptable and normal that your word processor could have a bug in it which would crash the entire OS. Or how almost everything was insecure by default.
  - oblio 5y ago
    Or your email client would open and execute every file attached and it would do so with root permissions.
  - stonogo 5y ago
    Nobody found that acceptable except computer programmers.
    - Gigachad 5y ago
      Well it didn’t really matter what users thought because that’s how it was. Modern programming and software is massively improved and the failure modes are much safer.
PaulHoule 5y ago
Definitely there are practices such as version control and automated testing that are better practiced today then they used to be.
cblconfederate 5y ago
Most of the "client"/desktop software does the same things that it did in 1997. Most/all of the 'advanced' features such as AI/voice recognition are done server-side because reasons. If the quality of desktop software was going up, it would be doing more than it did in 1997. I don't think it does, in fact it is being dumbed down to look like mobile software (which is inherently lower quality due to limited UI). So how come the quality is going up but the user benefit (i.e. time it saves) has not changed?
- Bilal_io 5y ago
  Do you think web development is anywhere near what it was 20 years ago? Or even 10 years ago? It has definitely advanced a lot. We're now able to do things we were never able to do back then. Now the browser can run a whole cad application, Photoshop, advanced 3d games and complex UI that we weren't able to compose before.
  - cblconfederate 5y ago
    > Do you think web development is anywhere near what it was 20 years ago why not compare web dev to where desktop was 20 years ago. The question from the user perspective is not whether this or that type of development is getting better, but whether software offers us new affordances today, which it does, but most of them rely on server-side processing and cloud data. I think you bring up a great example. Which kind of application has gotten better than its past desktop counterparts because of the improvements in javascript? (counterexample: we lost Flash)

timhrothgar 5y ago

Perhaps I should update the question. I'm not referring to ALL software quality. I'm referring to the quality of codebases that are 1) old, 2) large, and 3) supported by many people. You make a good point though. Perhaps I just miss the good ol' days of working on small teams with small codebases that were pretty easily maintained.

wrs 5y ago
Old large codebases are mostly maintained by people who weren’t around when the code was originally coming into existence. They don’t know the implicit design assumptions and decisions, or even the history of requirements. One thing you’ll find in nearly any software project of any age is a lack of good documentation of those things, so as you lose the community folklore, people will start making myopic changes, cargo-culting, violating future-looking design principles, and so forth. Pretty soon you just have a pile of incoherent features and making systematic improvements is hard because the code is no longer systematic.
quanticle 5y ago
Even with those caveats, it's unclear whether the premise is satisfied. The Linux kernel is old (old enough to drink!) large (and getting larger!) and supported by many people. Has its quality declined? I don't think so. It supports more hardware than ever. Kernel panics don't happen nearly as often as they used to. New features (BPF), make kernel programming easier. It's difficult to say that the Linux kernel's quality has declined over time.
- timhrothgar 5y ago
  I had this specific example in mind. How has Linux done it? Was it ultimately due to the benevolent dictator for life (BDFL) management practice?
  - xxpor 5y ago
    The kernel isn't working on commercial deadlines. Maintainers don't have to worry about their stack rank at the end of the year. They don't have to justify their head count. Some of this happens internally I'm sure, at places like IBM, Red Hat, and Intel, but none of it is coming from Linus.
  - ssdspoimdsjvv 5y ago
    Probably that, and the average Linux contributor being a lot brighter than your run of the mill programmer.
    - 6510 5y ago
      If someone was to design a good small set of opcodes we could go back to rolling machine code by hand. While at it we might as well fill the atx box with cute tiny isolated computers that talk over ip addresses. They have to be small enough as to not leave space for an OS. Some ROM is fine ofc.
- peakaboo 5y ago
  People being up the Linux kernel on the same way they bring up Oprah as an example of being successful in America. 99.99999% of software in big corporations will not have even 5% of the quality of the Linux kernel. The reason the kernel has such a high quality is because of Linux being a dictator, training everybody in not always so nice ways to write code that doesn't break anything and that is maintainable. He cares about the code and he has the status and the mandate to prevent it from becoming shit.
  - PragmaticPulp 5y ago
    > 99.99999% of software in big corporations will not have even 5% of the quality of the Linux kernel. Having done a lot of work on the kernel, I think you’d be surprised at the relatively low quality of a lot of kernel drivers. The core code is generally quite good, but it’s not true that the kernel is full of pristine code. I’ve worked at multiple companies where code quality standards exceeded a lot of the weirder stuff I’ve seen (and often fixed) in kernel driver code.
peakaboo 5y ago
You listed the reason it's a mess yourself - many people worked on it and it's old. For big companies there is no incentive at all for a developer to personally care about and do battle over things like code quality and reduce complexity. If they are use any kind of agile (lol) system, it will just be about polishing the turd so it doesn't break and add features in some way that doesn't require big rewrites.
mbesto 5y ago
> 1) old, 2) large, and 3) supported by many people. Software entropy implies that software that doesn't change will always suffer entropy if the environment changes. In a vacuum, we would never need to change software once it was "feature complete". But that's not how the world works. Environments change and so that inevitably means software will corrode. Candidly, I think you're just looking at the world through rose tinted glasses.
com2kid 5y ago
> Perhaps I should update the question. I'm not referring to ALL software quality. I'm referring to the quality of codebases that are 1) old, 2) large, and 3) supported by many people. Because Google[1] and Facebook came along and scared everyone by iterating at a LOLWTF pace and companies in surrounding spaces looked at what was taking up time in their release schedules and the answer was "test passes" so they fired all their testers, and told devs to add unit tests but unit tests don't cut it. Companies that used to have immaculate software quality had dedicated test automation engineers who had the job of abusing software in crazy bizarre ways. Then they hired armies of manual testers to go over anything that hadn't been automated. Lots of problems existing with this system, one of which was career advancement for software engineers in test was limited because it is hard to get recognized for the two primary jobs of an SDET: Signing off on code Blocking a release on quality grounds So you had a gradual rot of SDET and test orgs at companies, with pools of brilliance that slowly got drained as the best engineers got tired of being undervalued. Start from that base, and then around ~2010 everything needs to start "moving fast". Apple and MS both get rid of their test teams, and with two of the largest employers of dedicated software engineers in test getting out of the field, the entire field itself falls apart. Now it is career suicide, an ever shrinking career path that pays far less than doing "real" development work. That leaves us at where we are today. Everything sucks and breaks all the time. [1] Everyone forgets how bad the first 5 major versions of Android were.
- mbrodersen 5y ago
  I have no QA testing and the code I maintain haven’t had a customer production bug for 5+ years. And we are taking complex software written in C++. The reason why is 90000 end-to-end use case tests. I routinely implement new features or refactor major parts of the application and the tests will tell me if it is ready for production or not.

trinovantes 5y ago

It definitely feels like survivorship bias. We only remember the good software of the past while forgetting the hundreds of buggy mess created by companies that are probably defunct by now

tluyben2 5y ago
Oracle?
- cestith 5y ago
  Oracle is a marketing department and two law firms in a trench coat.
rhizome 5y ago
http://www.scriptarchive.com/formmail.html http://www.scriptarchive.com/formmail.html
Gigachad 5y ago
I wonder if people are forgetting that not long ago, it was acceptable and normal that your word processor could have a bug in it which would crash the entire OS. Or how almost everything was insecure by default.
- oblio 5y ago
  Or your email client would open and execute every file attached and it would do so with root permissions.
- stonogo 5y ago
  Nobody found that acceptable except computer programmers.
  - Gigachad 5y ago
    Well it didn’t really matter what users thought because that’s how it was. Modern programming and software is massively improved and the failure modes are much safer.

PaulHoule 5y ago

Definitely there are practices such as version control and automated testing that are better practiced today then they used to be.

cblconfederate 5y ago

Most of the "client"/desktop software does the same things that it did in 1997. Most/all of the 'advanced' features such as AI/voice recognition are done server-side because reasons. If the quality of desktop software was going up, it would be doing more than it did in 1997. I don't think it does, in fact it is being dumbed down to look like mobile software (which is inherently lower quality due to limited UI). So how come the quality is going up but the user benefit (i.e. time it saves) has not changed?

Bilal_io 5y ago
Do you think web development is anywhere near what it was 20 years ago? Or even 10 years ago? It has definitely advanced a lot. We're now able to do things we were never able to do back then. Now the browser can run a whole cad application, Photoshop, advanced 3d games and complex UI that we weren't able to compose before.
- cblconfederate 5y ago
  > Do you think web development is anywhere near what it was 20 years ago why not compare web dev to where desktop was 20 years ago. The question from the user perspective is not whether this or that type of development is getting better, but whether software offers us new affordances today, which it does, but most of them rely on server-side processing and cloud data. I think you bring up a great example. Which kind of application has gotten better than its past desktop counterparts because of the improvements in javascript? (counterexample: we lost Flash)