Some software has continued to be used for decades. Unix and its descendants. The C programming language. SQL. TeX. Emacs. Vim. The Bourne shell. Substantial portions of contemporary computing infrastructure rest on software that was designed before most current programmers were born.
Most software is not like this. The vast majority of software produced is forgotten within a few years. The frameworks that seemed essential become legacy. The applications that defined an era become unsupported. The tools that everyone used disappear from collective memory.
The patterns that distinguish durable software from disposable software are worth understanding.
What durable software shares
Looking across the software that has endured for decades, several characteristics consistently appear:
1. Solving genuinely fundamental problems. Durable software addresses problems that do not go away. File systems will continue to need management; durable file management software remains relevant. Text editing will continue to be needed; durable text editors remain relevant. Database queries will continue to be needed; SQL remains relevant.
2. Stable interfaces. Durable software typically has interfaces that change slowly. Programs written for early Unix can often still run on modern Unix-like systems decades later. Programs written for many newer systems break with each major version.
3. Composability. Durable software typically composes well with other software. Unix tools are designed to combine. SQL queries combine with diverse application code. The composability extends the software's relevance.
4. Cultural adoption. Durable software has become embedded in how its users think and work. The cultural adoption is harder to dislodge than technical alternatives might suggest.
5. Restraint in features. Durable software typically does specific things well rather than many things adequately. The restraint allows continued mastery; the breadth would prevent it.
Software exhibiting these characteristics often endures. Software lacking them typically does not.
What disposable software shares
The software that does not endure typically shares opposite characteristics:
Solves trendy problems. Built for problems that emerged with specific technological moments and become irrelevant when those moments pass.
Frequently changing interfaces. Each version breaks compatibility with previous versions. Users and dependent code must constantly adapt.
Tightly coupled to platforms. Designed for specific platform contexts that may not persist.
Fashion-driven adoption. Adopted because they are currently fashionable rather than because they solve enduring problems.
Feature-driven design. Constant feature addition that prevents users from developing deep mastery.
Software exhibiting these characteristics typically fades within a decade or two regardless of initial enthusiasm.
The case of Unix
Unix is the paradigmatic case of durable software. Developed at Bell Labs in the late 1960s and early 1970s, Unix has continued to be used and developed for over half a century. Modern Linux, macOS, and various BSD systems all descend from Unix. The fundamental design choices of early Unix continue to shape how computing is done.
What made Unix endure:
- Simple powerful primitives (everything is a file, small composable tools)
- Stable system call interface across decades
- Cultural commitment to backwards compatibility
- Focus on developer use cases that have remained relevant
- Open development model that allowed external contribution
Unix has survived multiple technological generations — minicomputers, workstations, personal computers, mobile devices, cloud servers. The fundamental design has remained relevant despite enormous changes in the underlying hardware.
The case of frameworks that did not endure
Many web frameworks that were once dominant have largely faded. Examples:
- jQuery — once essential, now mostly legacy
- Angular 1 — popular for several years, then replaced by incompatible Angular 2+
- Backbone.js — substantial adoption peak, now rare in new projects
- Knockout.js — meaningful adoption period, now mostly forgotten
- Ember.js — substantial enterprise adoption, declining
Each had genuine technical merit at its peak. Each addressed specific problems of its era. Each is now substantially less used than at peak. The patterns that produced their decline:
- Solved problems that became less relevant (jQuery solved cross-browser compatibility that browsers eventually addressed)
- Major version transitions that broke backward compatibility
- Replacement by frameworks that fit better with subsequent technology trends
- Limited cultural depth beyond specific technical adoption
The frameworks that fade typically share characteristics. The frameworks that endure also share characteristics. Recognizing the difference helps with technology selection.
What this teaches about choosing software
For people selecting software for work that will continue across years, the durability question matters substantially. Software that will not be supported in 5 years produces costs across that period.
Practical implications for software selection:
- Favor software that has already endured several technological generations
- Be skeptical of newly-emerged "transformative" software
- Consider the cultural depth of software adoption, not just current popularity
- Evaluate backwards compatibility commitments and track records
- Consider whether the underlying problem will continue to be relevant
This bias toward durable software conflicts with much technology culture, which favors novelty. The conflict is genuine and the resolution depends on context. For long-horizon work, the durability bias typically produces better outcomes.
What this teaches about building software
For people building software, the durability question affects design choices. Software designed for durability has different characteristics than software designed for current trends.
Design choices that support durability:
- Address fundamental problems rather than current technological moments
- Provide stable interfaces that can persist across versions
- Build composability with other software
- Focus on doing specific things well rather than many things adequately
- Document thoroughly enough that users can develop mastery
- Commit to backwards compatibility even at cost of some technical purity
Software built with these principles is harder to ship initially and may attract less initial attention. Software built without them is easier to ship initially but typically does not endure.
The contemporary tension
Contemporary software culture creates tension between durability and visibility. Software that follows current trends gets attention; software that is built for durability often does not. The economic incentives often favor visibility over durability.
This tension affects what software gets built. Substantial portions of contemporary software effort produce software that will not endure because the incentives reward visibility rather than durability.
The systems that the next 50 years of computing will rest on are being built somewhere — but probably not where most contemporary attention concentrates.
A closing observation
The software that has endured for decades demonstrates what is possible when software is built for problems that do not go away, with interfaces that remain stable, with restraint that allows mastery.
The software that fades within a decade demonstrates what happens when software is built for trends, with interfaces that constantly change, with feature creep that prevents mastery.
For practitioners and users alike, recognizing the pattern affects what software warrants serious investment of attention and what software is likely to consume time without producing durable value.
Some software endures. The patterns are recognizable. The choice of which software to engage with deeply affects what kind of computing capability we develop over years.
