So what does the piece of software you are about to write have to do with a long-decommissioned aircraft carrier?
Well, I’m assuming that you are working on something more complex than a marketing website that is going to get chucked away after a few months, and are – perhaps – working on a business system that is going to have many man months – and possibly many man years invested in it. In that case, the answer to the question is “more than you might think” (but yeah, it is tenuous – I really just like big ships).
The second of the Kitty-Hawk Class carriers was USS Constellation (CV-64); Her keel was laid down in 1957, she was commissioned in 1961 and finally decommissioned in 2003, after some 42 years of service as mobile home to a crew of 6,000.
53 people died during her construction and she cost around USD 2.5 billion in 2017 dollars.
When you engage in the design and construction of an enormous undertaking like CV-64, one of the key considerations is “how long is this thing actually going to need to last?” The benefit-of-hindsight answer to the question is often “longer than we initially expected”.
The same question needs to be applied to your software. If it needs to last 6 months, the choices you will make will be very different than if the system is going to last a decade or more. In my own career, I have worked on one system that is still in active development after 14 years and another that reached at least 20 (that I know of). They both cost multiple millions of dollars to develop and were integral to the businesses that deployed them.
For enterprise systems, like the big old ship, the truth often is that however long you think it will be used for, it will actually be used for longer in some form or another. The budget to spend hundreds of thousands (or millions) of dollars on developing a system often doesn’t come along twice. So we keep things running and we keep extending them.
The biggest challenge is predicting whether a technology chosen today is still going to be maintainable in a decade or more. In truth, there is going to be a degree of guesswork, but we can use the past to help us predict the future. The database is a really good example of something we can have a degree of surety about. If it is appropriate to your business problem, and you can store your data in a mainstream RDBMS (such as PostgreSQL, Oracle or SQL Server), we can say with close to 100% certainty that in a decade, those products will still work, will have had active maintenance, and you won’t have had to go through a version update that forced you to rewrite all your code.
Like it or not, these products are the decades-old rocks on which enterprise systems are built. Your bank is not going to store your data in MongoDB. Well, your bank can do what it likes, but if my bank does, I’m moving my funds. Definitely use a non-relational database if you have a genuine reason, just don’t do it because (a) you are too lazy to properly model your data or (b) because it is trendy and you only work with stuff that is fun. Trendy, fun things usually hurt you when you break up with them.
The truth is that in a reductive sense, business systems exist to store and mutate organizational state. If you can figure out the storage side, that’s really half the battle won. The other half of the battle, unfortunately, is way more difficult; What do you use to write your business logic in? Of the dozens of languages and hundreds of frameworks, which do you pick?
What do I look like….? Nostradamus?
It is easier to suggest characteristics to avoid, than things to aim for. Don’t choose a framework that is at version 1 unless you are pretty sure that version 2 is likely to remain relatively backward compatible. Frameworks often need a bit of time for ideas to shake out and to end up in a somewhat final shape. New and cool may equal expensive rework down the line. If you don’t get paid overtime, that might be you getting squeezed. And if not you, well, somebody probably is, so pay it forward and make good choices to help your fellow man (or woman).
Do you really need to pull in a third-party library to save a few lines of code, if that library comes with a dependency tree the size of an aircraft carrier? Node.JS projects undoubtedly suffer from this problem. How many of those dozens of libraries you pulled in are basically abandon-ware even by the time you type npm install? (and whist you are at it, how do really know you can trust any of this code, anyway? See previous comment about my bank).
Do you need to be web-scale? Look, if you are reading this blog, the answer is probably “no”. 99.9% of projects aren’t “web-scale”. Choose the technology that lets you solve your actual business problem, not someone else’s. If your problems are mostly synchronous, is that asynchronous platform really the best choice?
Back to big ships — In 1990, CV-64 was taken out of service for 3 years for a Service Life Extension Program (SLEP), which was intended to add an extra 15 years onto her life (for the princely sum of $800m). They could do this because she had “solid bones”. You need to make sure that your projects also have solid bones so you can squeeze extra life from them.
A “SLEP” process is also totally applicable to software. On my last big project, we made a (bad) choice in 2003 to use XUL, a Mozilla specific markup for a few of our core components, because (a) it was going to be the next great thing (guess what – it wasn’t), and (b) it was way better than HTML (that much was actually true). In the early 2010s, we engaged in a technology replacement program to rip it all out before it was dropped from Firefox.
The important thing here was that we knew we had a bad technology choice, we knew roughly how long we could live with it and we executed a plan to move forward. It is a good idea to periodically look at the current risk status of any technologies you are using and ensure you are in a position to mitigate any risks before they bite you. If your system is architected with reasonable separation of concerns and using open standards (i.e. don’t do what we did), you probably won’t need to replace too much in any one go.
Summary: Don’t do trendy for the sake of trendy. Anyway, I’m at 1,100 words, and I’m only allowed 800, so, blame the incoherent mess you just skim-read on editorial policy. If I’d had another 10,000 words, believe me, it would have been terrific.
Banner image: Photo by Michael Afonso on Unsplash
