The Software Crisis

Existence and nature of a “software crisis”

• Some see no crisis: software is everywhere, mostly works, and it has never been easier to build powerful systems on rich APIs and tools. We’re in a “golden era”; constant over‑budget/late projects are just normal for many human endeavours.
• Others argue there is a crisis: pervasive low quality, bloat, brittleness, and user-hostile behavior. Problems are often hidden until users hit edge cases; “turn it off and on again” is viewed as symptomatic.
• A third group reframes it as primarily a project-management or economic crisis (feature factories, short-term incentives, lack of accountability), not a purely technical one.

Abstractions: necessity, overuse, and failure modes

• Broad agreement that abstraction is essential; without it, we’d still be bit‑twiddling.
• Disagreement over degree and kind:
  • Critics argue we’ve stacked too many deep, leaky layers; imperfect abstractions force people to reason about multiple layers at once.
  • Others counter that detail-eliding abstractions massively increase productivity; the problem is bad or mismatched abstractions, not abstraction itself.
• Debate over “perfect” abstractions: some say a perfect abstraction should never require dropping down a layer; others call that unrealistic and emphasize understanding implementation limits (SQL EXPLAIN, sorting algorithms, etc.).

Complexity, human limits, and mental models

• Many see complexity as the true enemy. Even solo hobby projects become hard to hold in one head; modeling the whole system is often beyond human cognitive limits.
• There’s tension between:
  • Building abstractions around users’ inaccurate but useful mental models to reduce friction.
  • Insisting abstractions should closely reflect underlying reality; otherwise they are “lies” that break badly when users inevitably hit internals.

Economics, incentives, and organization

• Several comments blame incentives: cheap, fast, and “good enough” beats careful, durable software; costs are externalized to users and the future.
• Agile/Scrum is criticized for fragmenting work into tickets, discouraging holistic thinking, and pushing non-technical managers above technical staff. Others report positive agile experiences focused on trust and removing process.
• Comparisons are made to other engineering disciplines where physical constraints impose a hard minimum quality bar; software’s lack of such constraints allows fragile systems to ship and persist.

Alternatives, movements, and tools

• Handmade/permacomputing/retro movements are cited as countercultural responses, emphasizing shallow, composable abstractions (e.g., Unix-style pipelines).
• Some warn these can fetishize minimalism and neglect rich, integrated tools users actually want.
• There’s exploratory discussion of composable GUIs and shell/GUI hybrids as ways to regain Unix-like composability at higher layers.

Author participation and reception

• The author clarifies they’re not anti-abstraction, not advocating “more technical users,” but concerned about divergence between platform mastery and release cadence, and wants constraints on layering.
• Some readers are excited for follow-ups; others criticize the tone as overconfident and the essay’s structure as muddled.