Long Term Software Development

Software evolution & long-term view

• Several commenters point to Lehman’s Laws and related research on software evolution as empirical backing for the article’s themes.
• Others recommend books on legacy systems and empirical software engineering, reinforcing that long-lived systems are common (banking, aerospace, elections, archiving).

Dependencies, versioning, and “DLL hell”

• Many see deep, fast‑moving dependency trees as the main enemy of longevity, citing Python, Node, and ML stacks as fragile and short‑lived.
• The historical “DLL Hell” on Windows is used as analogy; some argue it’s largely solved now via versioned assemblies and app‑local DLLs, while others note it was “solved” mostly by bundling private copies.
• Rust’s model (multiple versions of a crate in one binary, name‑mangled) is praised for safety but criticized as encouraging sprawling, slow‑compiling dependency graphs.
• Reproducible builds are proposed as a counter to dependency drift, but others point out they do not solve security updates or abandoned libraries.

Third‑party libraries vs in‑house code

• A strong contingent argues for minimizing third‑party deps, especially in performance‑critical C/C++ systems or long‑lived infrastructure, citing:
  • Poor performance and scalability of many OSS libs.
  • Harder observability and debugging across many libraries.
  • Supply‑chain and maintenance risk, especially when tooling must be aggressively updated.
• Counter‑arguments stress that some domains (auth, crypto, image parsing, ML libraries) are too hard or risky to re‑implement, and that popular, well‑scrutinized libs are safer than bespoke code.
• There’s nuanced middle ground: use a few “platform‑level” mature deps, vendor or replace narrow ones, and accept interim libs as stopgaps.

Simplicity, documentation, and style

• Many reinforce “write boring, simple, obvious code” and avoid premature optimization or over‑architected layers.
• Some warn not to conflate “simple” with “easy”; a good architecture can be “clever” in service of making application code simple.
• Documentation is widely seen as crucial for longevity; disagreement focuses on avoiding meaningless boilerplate vs providing high‑level intent and system context.
• Style uniformity is de‑emphasized; learning to work with mixed styles is considered more valuable than rigid enforcement.

Critical systems vs typical web/apps

• Commenters note a gap between practices for life‑critical / industrial systems (assertions, no dynamic allocation, highly conservative change) and the more pragmatic mitigation‑oriented advice suitable for typical web and business software.