Is Software Quality Getting Worse? It Used to Be Much Worse

A post that sparked nearly three hundred points of discussion on Hacker News puts forward a counterintuitive argument: although people universally complain that software is getting worse, looking back at history, software quality was actually much worse before. This argument seems to defend the current software industry, but in fact it implies a disenchantment with the "nostalgia filter."

The Illusion of Software Quality Under the Nostalgia Filter

People tend to remember the parts of past software that "worked" and forget the maddening crashes, compatibility issues, and learning costs. The article points out that this selective memory is the psychological foundation of the "software is getting worse" narrative. When we complain today about an app stuttering or updating too frequently, we often overlook the more widespread chaos in early software ecosystems—incompatible drivers, frequent system blue screens, and software installations requiring manual configuration of numerous parameters.

This memory bias is especially pronounced in tech communities. Experienced developers easily mistake the smooth experience brought by personal proficiency for an improvement in the software itself; while newcomers' frustration when facing modern complex systems is blamed on "software getting worse" rather than the objective existence of a learning curve.

Selective memory and nostalgia bias are classic concepts in cognitive psychology. When recalling the past, people tend to retrieve positive events more easily, while negative experiences gradually blur as emotions fade. In the software domain, this bias manifests as: users remember the moment when an old tool was "simple and efficient" but forget the daily troubles caused by frequent crashes, driver conflicts, and cumbersome configuration. This psychological mechanism not only affects individual judgment but also forms a collective narrative in tech communities, giving the "software is getting worse" argument emotional resonance rather than being based on comparable objective data.

The availability heuristic also plays a role: when people evaluate software quality, they tend to rely on the most easily recalled examples (such as a severe stutter or a privacy breach) and ignore long-term, low-frequency improvements. This cognitive shortcut amplifies negative perceptions and further reinforces the nostalgia filter.

The Transfer of Complexity, Not Its Increase

The core insight of the article is that software has not simply gotten worse or better; rather, complexity has shifted. Past software exposed complexity to users—command-line parameters, configuration files, manual dependency management; modern software encapsulates complexity internally, lowering the barrier to use through automation, abstraction layers, and default configurations.

This shift brings new problems. When the abstraction layer is thick enough, users lose visibility and control over system behavior, making it difficult to diagnose once problems arise. At the same time, encapsulation also means the "black-boxing" of software behavior: users can only perceive stuttering, delays, or functional anomalies but cannot understand their causes. This explains why modern software is more powerful in functionality yet often feels "less reliable."

Abstraction layers are a core means of managing complexity in computer science. By hiding underlying details and providing simpler interfaces, they allow developers to use systems without understanding the full implementation. Modern software relies heavily on abstraction layers (such as operating system APIs, frameworks, and cloud services), transferring complexity from the user side to the internal side. However, abstraction is not free: each additional layer of abstraction adds a potential point of failure, and failures are harder to locate when they occur. Black-boxing is precisely the consequence of excessive abstraction or insufficient documentation—users can only see inputs and outputs, unable to gain insight into internal states, leading to diagnostic difficulties.

Observability has thus emerged, emphasizing making internal system behavior visible through logs, metrics, and tracing. This is directly related to the "diagnosability" mentioned in the article: good software design should strike a balance between encapsulation and transparency, lowering the barrier to use while retaining sufficient debugging information.

Divergence in Discussion: The Dialectic of Progress and Regression

The HN comment section shows clear polarization of views. One side believes that modern software has indeed made substantial progress in stability, security, and maintainability, with the widespread adoption of continuous integration, automated testing, and monitoring systems enabling earlier defect detection; the other side emphasizes that frequent updates driven by commercial pressure, feature bloat, and privacy erosion have caused software to regress in terms of "predictability" and "user trust."

A noteworthy consensus is that the criteria for evaluating software quality themselves are changing. In the past, the measure was "whether it runs"; now it is "whether it is smooth, secure, and respectful of users." Rising standards create the illusion of "declining quality," but in reality, expectations are rising faster than actual improvements.

Continuous integration (CI) and automated testing are key practices in modern software engineering for improving quality. CI requires developers to frequently integrate code into the main branch and quickly detect defects through automated builds and tests; automated testing covers unit, integration, and end-to-end levels to reduce regression issues. These practices do improve software stability and maintainability, but their benefits are often invisible to end users—users perceive feature updates and interface changes, not the quality assurance behind them.

Feature creep, on the other hand, affects perception in the opposite direction: commercial competition drives products to continuously add new features, leading to interface complexity, performance degradation, and increased privacy risks. Users thus get the intuitive feeling that "software is getting worse," even though underlying stability may have improved. This coexistence of progress and regression is the root of the divergence in the HN discussion.

Implications for Developers

The value of the article lies not in proving that "software has always been getting better" but in reminding tech practitioners to be wary of simple linear narratives. For developers, this means two things: first, respect history and understand the constraints and trade-offs of early software ecosystems; second, seek a balance between abstraction and transparency, avoiding sacrificing diagnosability for the sake of encapsulation.

In the current era of increasing adoption of AI-assisted programming and automation tools, this perspective is particularly relevant—tools lower the barrier to coding, but the responsibility for managing system complexity does not disappear; it merely shifts from "writing code" to "understanding system behavior." The next battleground for software quality may not be the code itself, but how we enable users and developers to regain comprehensibility of complex systems.

One-line Summary

Software quality is not linearly deteriorating; rather, it is an illusion shaped by the transfer of complexity and rising expectations.

Paragraph Summary

The article responds to the common complaint that "software is getting worse" by pointing out that software quality used to be much worse. Due to selective memory, people overlook early software crashes, compatibility issues, and learning costs, forming a nostalgia filter. The core insight is that complexity has not disappeared but has shifted from the user side to the internal system, bringing new problems such as black-boxing and reduced diagnosability. The HN discussion shows divergence: one side acknowledges substantial progress in stability and security, while the other emphasizes that commercial pressure has led to regression in predictability and user trust. The consensus is that quality evaluation standards themselves are rising, and expectations are increasing faster than actual improvements, creating the perception of "getting worse." The implication for developers is to avoid linear narratives, seek a balance between encapsulation and transparency, and pay attention to the responsibility of managing system complexity in the AI era.