Software is drowning the world

James Abley's observation: every time you decide to solve a problem with code, you're committing part of your future capacity to maintaining and operating that code. Software is never done. Organizations are running to stand still and don't even realize it.

Here's what accumulates over time. Security: humans are terrible at writing secure code, and given enough time, other humans will discover the holes. You now have CVEs to assess and patch, both in your code and every library, OS, web server you depend on. APIs change: third parties will change their APIs for performance or security. Older versions get deprecated. You need to upgrade and adapt your code to use the new API, even when maintainers strive for backward compatibility. Legislation changes: Brexit required businesses to rewrite software for new trading relationships. GDPR forced compliance work. These aren't one-time events.

A team working in a particular way can only be responsible for a fixed amount of software. The amount of software should be managed, otherwise the team grinds to a halt. Every organization Abley has worked in suffers from decade-old codebases running unsupported versions of dependencies or frameworks. The maintenance burden compounds.

At a certain size, it makes sense to have people dedicated to developer productivity—creating tools that improve capacity of other teams. You can choose higher-level languages, use SaaS vendors' tech stacks that need less time. But mostly you need proactive tooling: automated dependency upgrades via Renovate, Dependabot, Snyk. The question isn't whether to build custom solutions. It's whether you've accounted for the ongoing maintenance cost when making that decision. Because the software drowning isn't what you write today—it's the obligation you create for every day after.