Live data from Hacker News

Ask HN: Why is software quality always decreasing?

news.ycombinator.com

31–40 of 166 posts

Re: Ask HN: Why is software quality always decreasing?

#31
>Can this be avoided for codebases that are old and large? Does anyone know of examples of codebases (public or private) that have maintained a high quality codebase that is large, old, or supported by a large number of contributors? If so, how is it done?

The thing is

if you took 3 x 10 years of experience engineer - one in web app backends, one heavy FP programmer and 3rd one in e.g kernel programming, then they'd have different definitions of "good code"

for web apps it's probably a lot of abstractions/indirections, DDD, patterns, heavy OOP, testability

for kernel code there's nothing wrong with gotos, ugly hacks for performance, 10 meters of ifs, stuff like likely/unlikely

Re: Ask HN: Why is software quality always decreasing?

#32
post #27

Its always decreasing because entropy builds up on longer projects. Its simply the fact of life, not particularly specific to coding. Nothing to do about it. You can delay it somewhat but not too much. The best you can do is to have automatic tests, lots of them, and make them work as intended (good tests are very hard to make). Those make refactoring possible and make specific quality guaranties.

> Its always decreasing because entropy builds up on longer projects. Its simply the fact of life, not particularly specific to coding. I don’t know much physics, but this word-soup about entropy is mistaken, isn’t it? Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)? > The best you can do is to have automatic tests, lots of them, an…

You are trolling here aren't you ?

> Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)?

Did you ever lead a project that spans at least half decade? And is this a coherent thought or something something whatever?

> I’m not sure what “best” means here, but there are other tools for improving software quality beyond tests, including and in particular formal methods.

There are other tools, but the one that makes refactoring possible is the best you can do regarding OP question. If you have a bad quality code, you need to refactor, no? You might want to have some other tools like superb docs, formal proofs etc. but those do next to 0 when you need to refactor and guarantee that you didn't break hell.

> What quality guarantees do tests make? That the build passes the test suite?

Notice the part about "good tests" which are "very hard" to do.

Re: Ask HN: Why is software quality always decreasing?

#33

Software quality has been increasing for as long as I've been in the business. However, the complexity, scale, and defect surface of software has been increasing at least as quickly. We've invested the systemic gains in quality to expand the capabilities of what software can reasonably do instead of polishing the software we wrote 20+ years ago. This was the right choice in most cases. The software from a few decades…

I tend to agree when considering _new_ projects. A new project begins with a larger ecosystem of knowledgeable and experienced software professionals. This would include people tangent to software development (project managers, designers, executives, etc). I suppose the intent for asking the question was really something like, "how could or should one institutionalize quality improvement?" Maybe that starts with 1) ensuring that the business actually grows, 2) ensuring that the software actually works, and 3) ensuring that some flexibility is baked into management of software as an asset... or something along those lines.

Re: Ask HN: Why is software quality always decreasing?

#36

Earlier quoted context omitted.

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.

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 qual…

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?

Re: Ask HN: Why is software quality always decreasing?

#37

I've been mainly working in web development since 2009 (before that I did it sometimes but also lots of standards work and data handling), so in that field I have seen a lot of commonly accepted software engineering best practices in use, but those commonly accepted software engineering best practices were not necessarily the commonly accepted software engineering best practices of the modern day, but rather of the d…

That's a very interesting insight. Thanks!

Re: Ask HN: Why is software quality always decreasing?

#39
For users (and hence product owners, managers etc) the most important quality is features. That the product does what they want. So long as users would rather have software that does 20 things poorly than 10 things well, then that's what they'll get. Because the software with twice the functionality will cast a wider net and catch or keep more business.

The reason you see the buggy and bloated software is survivor bias I think. The software you see is the software that survived long enough to become bad. That programs grow old and bloated is a testament to that someone uses them. This was always the case too. Software was definitely not any better historically.

Re: Ask HN: Why is software quality always decreasing?

#40
post #27

Earlier quoted context omitted.

> Its always decreasing because entropy builds up on longer projects. Its simply the fact of life, not particularly specific to coding. I don’t know much physics, but this word-soup about entropy is mistaken, isn’t it? Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)? > The best you can do is to have automatic tests, lots of them, an…

You are trolling here aren't you ? > Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)? Did you ever lead a project that spans at least half decade? And is this a coherent thought or something something whatever? > I’m not sure what “best” means here, but there are other tools for improving software quality beyond tests, including and…

My first comment was specifically about the invocation of “entropy”, which I believe is just confusing nonsense. And as I said I don’t have the requisite background to really make the point, was hoping for some goodwill and assistance perhaps.

I’ll retract my comment about formal methods since I’ve never actually used them in a refactor. And I agree that tests make refactoring easier. But none of this demonstrates for me that tests are the “best” tool for facilitating a refactor.

And so, what specific quality guarantees do good tests make?

Post reply on HN