On the Longevity of Developed Software

One of the things I often think about as a software developer is that much of what I make does not last very long. I am lucky if the product of my labour lasts more than a few years. I am not alone in these thoughts: there was a recent thread on HackerNews along much the same lines[1], categorising all developed software that lasts long enough as tech debt.

It is quite fashionable, as many do in that thread, to believe that this is entirely due to failings of the industry. Be it because of a preference for trendy technologies that come ago, or from poor design choices that prioritise short-term solutions over long-term planning, and no-doubt those are significant factors. However, I think there is another factor at play that is a far more optimistic one: simply the fact that there is genuine innovation in the world of software development and much of the need to replace working systems is driven by us wanting to replace systems that just weren't as well built as what we build today.

Take Web development, which I know best. There's nothing stopping you building Web sites much as they were build 20 years ago, with HTML forms and splattering of CSS. Most of those sites -- the ones still up -- work just fine in modern browsers. The UX is inferior and its far more difficult to modify them (including finding people with the skills to do so) but many keep ticking away day after day, performing the task they were set out to do. Riddled with security vulnerabilities, no doubt, but still meeting the task they were written for. The problem comes when you want to make changes to them.

Much of my day job involves working with a legacy JavaScript codebase that is, thankfully, nowhere near so old. But it is still old enough to demonstrate to me just how much has improved in the last five years. The code has no tests, no type annotations (not even JSDoc), no general documentation, and most critically of all, no explicit dependency declarations. Say what you will of today's Jenga-pile of node modules, react components, minified bundles but I do think it is objectively better than yesterday's labyrinth of programs generating HTML files with script tags, referencing global variable initialised elsewhere. My day is nothing short of mostly archaeological work as I dissect what the developer before me intended.

• When it comes to large codebase with lots of developers, type annotations that can be verified by the compiler ARE an improvement over not having them.
• Whether you think TDD is awesome or excessive, having some unit tests that cover edge cases and known bugs is obviously better than not having any.
• Whether you think documentation is usually misleadingly wrong more often than it is helpful or not, having descriptive tickets referenced in git commits is obviously better than 1000 lines of changes with nothing but "fixes bugs".
• And quite honestly, I don't see how anyone can dispute the usefulness of import statements. Just assuming that the right scripts will be available on the webpage at the right time in the right order is pure insanity.

Things have improved, and it makes me optimistic that when the code I write today is inevitably replaced it will be because that developer knows of a better way of doing things.

~~~

Last Updated: 2023-05-21