A Plea for Lean Software (1995)
Programmers revisit Niklaus Wirth’s 1995 “Plea for Lean Software” in light of today’s slow, memory-hungry apps, arguing that modern tools and frameworks often squander massive hardware gains for marginal convenience. Many blame organizational incentives that reward shipping features over performance, the rise of heavyweight stacks like Electron, and reliance on broad, generic dependencies instead of focused, well-understood components. Others counter that richer functionality, Unicode, remote editing, and complex system infrastructure inevitably add weight, and that for many users and companies the trade‑off remains acceptable as long as perceived speed is “good enough.”
OS, background services, and user control
- Many complain about commercial apps auto-starting background services (VPNs, Steam, chat apps) largely for updates/telemetry rather than user value.
- Windows is criticized for making such services hard to disable and for undoing user settings (e.g., AV policies), while macOS is seen as more user-controllable.
- Some suggest OS-level update services that apps can register with, but doubt developers would adopt them over custom updaters.
Editors, features, and perceived bloat
- Older editors using a few MB are reinterpreted as “lean” compared to modern tools like VS Code/JetBrains.
- One side argues modern features (Unicode, emoji, rich remote development, LSP analysis, previews) inherently justify higher resource use.
- Others counter that these features can be implemented with much less code; large frameworks and browser engines are often chosen by default, not necessity.
- Responsiveness and input latency are emphasized as more important than raw RAM usage.
Dependencies, libraries, and Electron/web stacks
- Shared libraries vs. bundling is debated: DLL-hell and distribution pain pushed many toward bundling everything in a large package.
- Some advocate tiny, purpose-built libraries; others favor mainstream libraries (e.g., big font renderers) for reliability and shared maintenance.
- Electron is a lightning rod: seen as enabling fast iteration and cross-platform dev, but also as emblematic of waste (multiple embedded browsers, high RAM/CPU).
- PWAs are suggested as a middle ground, though they lack native APIs without extra machinery.
Organizational incentives and process
- Large organizations are said to reward features and optimism, not performance; small incremental slowdowns accumulate until systems feel intolerable.
- Agile/enterprise processes, heavy CI/CD, and large teams are criticized for ballooning effort and LOC with little real output.
- Performance as a core feature exists in niches (trading, search/ads) where time is directly monetized; elsewhere it’s often deprioritized.
Hardware, users, and testing
- Some argue “hardware is cheap, time is expensive,” justifying heavier tools.
- Others note that many users have modest machines; running multiple heavy apps (Slack/Teams, IDEs, browsers, Electron tools) makes systems sluggish.
- Testing on low-end or older hardware is proposed as a discipline to keep software lean.
Responsibility and lean-software ethos
- Several insist developers must own performance, pick fast-by-design architectures, and avoid gratuitous abstraction and generic frameworks.
- Others highlight ecosystem and economic forces (shared dependencies, job incentives, management culture) that structurally favor bloat.
- There is cautious optimism around a counter-movement of performance-focused tools, but skepticism that it will broadly reverse bloat trends.