Code is a liability. Code's *capabilities* are assets. The goal of a tech shop is to have code whose capabilities generate more revenue than the costs associated with keeping that code running. For a long time, firms have nurtured a false belief that code costs less to run over time: after an initial shakedown period in which the bugs in the code are found and addressed, code ceases to need meaningful maintenance.

2/

After all, code is a machine without moving parts - it does not wear out; it doesn't even wear down.

This is the thesis of Paul Mason's 2015 book *Postcapitalism*, a book that has aged remarkably poorly (though not, perhaps, as poorly as Mason's own political credibility): code is not an infinitely reproducible machine that requires no labor inputs to operate.

3/

Rather, it is a brittle machine that requires increasingly heroic measures to keep it in good working order, and which eventually does "wear out" (in the sense of needing a top-to-bottom refactoring).

To understand why code is a liability, you have to understand the difference between "writing code" and "software engineering."

4/

"Writing code" is an incredibly useful, fun, and engrossing pastime. It involves breaking down complex tasks into discrete steps that are so precisely described that a computer can reliably perform them, and optimising that performance by finding clever ways of minimizing the demands the code puts on the computer's resources, such as RAM and processor cycles.

5/

Meanwhile, "software engineering" is a discipline that subsumes "writing code," but with a focus on the long-term operations of the *system* the code is part of. Software engineering concerns itself with the upstream processes that generate the data the system receives. It concerns itself with the downstream processes that the system emits processed information to.

6/

It concerns itself with the adjacent systems that are receiving data from the same upstream processes and/or emitting data to the same downstream processes the system is emitting to.

"Writing code" is about making code that *runs well*. "Software engineering" is about making code that *fails well*.

7/

It's about making code that is legible - that can be understood by third parties asked to maintain it, or who might be asked to adapt the processes downstream, upstream or adjacent to the system to keep the it from breaking. It's about making code that can be adapted, for example, when the underlying computer architecture it runs on is retired and has to be replaced, either with a new kind of computer, or with an emulated version of the old computer:

https://www.theregister.com/2026/01/05/hpux_end_of_life/

8/

Because that's the thing: any nontrivial code has to interact with the outside world, and the outside world isn't static, it's *dynamic*. The outside world busts through the assumptions made by software authors *all the time* and every time it does, the software needs to be fixed. Remember Y2K? That was a day when perfectly functional code, running on perfectly functional hardware, would stop functioning - not because the code changed, but because *time marched on*.

9/

We're 12 years away from the Y2038 problem, when 32-bit flavors of Unix will all cease to work, because they, too, will have run out of computable seconds. These computers haven't changed, their software hasn't changed, but the world - by dint of ticking over, a second at a time, for 68 years - will wear through their seams, and they will rupture:

https://www.theregister.com/2025/08/23/the_unix_epochalypse_might_be/

10/

The existence of "the world" is an inescapable factor that wears out software and requires it to be rebuilt, often at enormous expense. The longer code is in operation, the more likely it is that it will encounter "the world." Take the code that devices use to report on their physical location. Originally, this was used for things like billing - determining which carrier or provider's network you were using and whether you were roaming.

11/

Then, our mobile devices used it to help determine your location in order to give you turn-by-turn directions. Then, this code was repurposed again to help us find our lost devices. This, in turn, became a way to locate *stolen* devices, a use-case that sharply diverges from finding lost devices in important ways - for example, when locating a lost device, you don't have to contend with the possibility that a malicious actor has disabled the "find my lost device" facility.

12/

These additional use cases - upstream, downstream and adjacent - exposed bugs in the code that never surfaced in the earlier apps. For example, all location services have some kind of default behavior in the (very common) event that they're not really sure where they are. Maybe they have a general fix - for example, they know which cellular mast they're connected to or they know where they were the *last* time they got an accurate location fix - or maybe they're totally lost.

13/

It turns out that in many cases, location apps drew a circle around all the places they *could* be and then set their location to the middle of that circle. That's fine if the circle is only a few feet in diameter, or if the app quickly replaces this approximation with a more precise location. But what if the location is miles and miles across, and the location fix *never* improves?

14/