For a recent project, I found myself working on a piece of software that is twenty years old. Everything about it felt old. The language was old. The development tools were old. The framework was old. At times my work felt like I was doing software archaeology.
In other ways, the software felt like it was something that could have been written much more recently. This caused me to ask myself, “what is it in software that stands the test of time?” It is an interesting question because software has an ephemeral quality to it. But this application has been in production since the Clinton administration and that means it has provided a phenomenal amount of business value to its users over the years. How can we build software today that will provide that much value over time?
Taking a deeper look at this software, it wasn't the language or the framework. It definitely wasn't the IDE--our modern tools make us much more productive. The best thing about the software was the clean code. It is simple things like having well named variables and functions that are appropriately sized. Code that used abstraction and encapsulation correctly was the code that was able to be easily maintained over the years.
But why is this so important when it is something that the end user never sees? Just when I was wondering this myself, I stumbled upon the perfect analogy.
The Old Safe
In the near future, Aptera will move into a wonderful new building. When we purchased the building, it came with a safe left by the previous owner. The safe is old, much older than the software I was working on, but it works as well today as it did the day it was made. What is it about the safe that has made it stand the test of time? It is built with high quality components.
The critical parts of the lock are made with brass, not some cheap pot metal. The users may never know that the drive wheel and the drop-in lever are made of brass or even that they exist. They have kept the lock working smoothly for all these years.
In the same way that the brass internals of the lock have kept the safe operational without the end users awareness of it, clean code keeps software operational whether or not the end users are aware of its existence. The overall functionality of the application I'm working on hasn't changed much over the years. But it has needed to be tweaked and added onto over the years to continue to meet the needs of the business.
It would have been initially cheaper to use lower quality metals in the safe. In the same way, it would have been cheaper initially to write messy, but functional code. But the software wouldn't have lasted as long and wouldn't have provided nearly as much benefit to the bottom line if it wasn't built to last.
The users may never know that the code is well structured and properly named. They may never know that the unit tests exist. But they will directly benefit from software that functions reliably for years to come. So, if you want to build software that will stand the test of time, always take the time to code it cleanly. Consider maintainability to be a key aspect of the code. Because just like the safe, even if the end user can't see the value, time will prove your effort well worth it.