If you work in tech, you’ll eventually run into the term technical debt. In this post, I want to argue that the term technical cantilever is more accurate.
A cantilever is when a structure is extended as if hanging in the air, held together only at one end, like half of a bridge. There is something magical about it because our intution tells us that this should collapse and, indeed, they are feats of engineering.
Software are often cantilevers: you build a solid foundation and then, you shoot out. Your foundation will necessarily include a lot of sotware engineering and design, it will include computer science theory, it will be heavily tested (both formally and informally); your outshoots will be a bit more messy code. Most software developers are working on the cantilever, not the foundations. In fact, I think most code falls into three categories:
The foundation. This is your operating system, your programming language libraries, your development framework (or the web browser on the user’s side). This stuff often has deep foundations in theory. Papers were written about its APIs and presented at CS conferences (some of them before you were born). The building and testing infrastructure alone have taken decades of manpower to build.
Internal libraries. This is some internal code that looks like a library. It has some testing. Nobody is presenting it at a CS conference, but there were design decisions based on what people felt were best practices.
Application. This is a bit rougher code. Testing may exist, but is less formalized. There are fewer design meetings.
Code may move from 3 to 2 as it gets hardened, and code may not always fall exactly into a bin. In scientific software, I have discussed an analogous phenomenon, using different terms: tools for others to use and Extended Methods code that corresponds to a single project. Another important point is that people who work on #1 and people who work on #2 and those that work on #3 will end up with very different intuitions about the value of formal engineering, leading to long and pointless HN threads and Twitter discussions.
Debt grows if unattended, while a cantilever can stay working but, at some point, you cannot extend it anymore even a tiny inch. I have left some projects active but idle for many years with no ill effects. All the around the world there are small pieces of infrastructure that have been running for years with little maintainance. Pieces of software that run as long as nobody touches them or upgrades anything. At the micro-scale, I ran my personal website on a very old version of Django for years to no ill effect. In fact, we have developed a lot of new infrastructure for freezing things in place: containers, virtual images, nix, &c
At some point, though, you cannot extend the cantilever without immense effort and jerry-rigging it, the software collapses. This is unlike debt, which grows little-by-litte (like a cantilever can be extended little-by-little) and can be paid down little-by-litter (which is very hard to do for a cantilever). A cantilever works great, like magic, until you hit the limits and then, to mix structurally-incompatible metaphors, you hit a wall. You can freeze it, wonder how it is possible that the whole thing hangs in the air, but it does not support even one more little brick.