Coding to Last?

I read this pretty interesting article on the engineering of pedals and hinges, the life expectancy of components and the rigorous testing for reliability in mechanical parts. Engineering is ultimately about tradeoffs, and this was a classic example of balancing cost and weight against stability and longevity.

It made me think about how developers try to live up to the “Software Engineer” title, even if it’s a self-applied label that’s only popular in the Silicon Valley. In our world, the tradeoff is between the amount of time it’d take to build a system, and the computing resources required to keep it up and running plus the cost of its ongoing maintenance effort. Even if the lean-startupy, hacked-in-one-weekend code isn’t going to be thrown away in a month1, it’ll be continuously refactored and remolded into foreign material over time.

And while continual improvement is considered coding good practice(™), I do wonder whether we’d be better served to spend a bit more time to ensure that the things we build can last for years and decades. I’d like to think that the old systems that have stood the test of time have done so, not necessarily because nobody wanted to tackle ancient tech debt, but because the old code still works and was designed to last multiple engineers, machines, and possibly companies.

At my first job, I was put on a win32/MFC codebase that was a decade old; that is, in 2004, I was working on code that was written in 1993 or so. There was still a substantial amount of effort to make use and enhance our custom Windows client app, and it was made possible mainly because Microsoft did such a good job maintaining compatibility across Windows. More than just 0s and 1s, that codebase has built up real value: it knew about various quirks in the Windows registry, memory leaks in the rendering subsystems, and was optimized for thin internet pipes with spluttering bits of data. It could be relied on, even as the layers upon the client were built to accommodate an increasingly complex UI.

At the extreme end of things, NASA’s software development process is notorious for being thorough and precise. Obviously, the high cost of a bug is a big motivating factor, but one nice side benefit is that a lot of the code is essentially bug-free and have lasted for decades. Think about that: like a well-crafted bridge or an antique instrument, the code embodies a kind of timeless quality. It is something that has transcended technological advancement and continues to perform, a stable source of truth that will be relied upon for years and years to come.

I’d take that over a statue.

  1. Some advise against taking on massive rewrites out of frustration and ego. I tend to agree.

Share this article
Shareable URL
Prev Post

Apple Maps and an Issue of Trust

Next Post

Real World Code does not Suck

Leave a Reply

Your email address will not be published. Required fields are marked *

Read next