Code For The Ages
Podcast: Play in new window | Download (55.3MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
Applications have a lifecycle. Whether the app runs unmodified for a few days before being replaced by a newer version, or runs for twenty years, there are few applications that can run unattended forever. The progress of culture, the internet, moving pieces of hardware, changes in platforms, programming languages, and programming approaches all conspire to shorten the useful lifespan of a piece of software from the moment it is released. You are almost certain to have to make changes to software at various points during its lifespan and in response to events that occur, no matter what you do. However, if you have some awareness of the kinds of things that can happen to software as it lives out in the wild, you may be able to make some of these changes easier to bear.
All things die. This includes the system you are working on right now, and any systems you build in the future. When building an application that is intended to be in production for a long period of time with minimal maintenance, there are things that will probably occur that can create maintenance work. If you are aware of these from the start, you can often design your application to make it easier to handle them when they come up.
Episode Breakdown
6 months to 1 year
New front end js framework
This is in the 6 month to one year range because these evolve quickly and often include breaking changes. Assuming you are using a long-term support version of your JS framework, the next one you care about will probably release within in a year.
Zero day or major short notice vulnerabilities
There are always major vulnerabilities out in the wild, some of which you will have to handle quickly. This varies a lot based on technology stack, as do the mitigation strategies.
New Reporting and Analytics Requirements
Clients, regulatory agencies, and stakeholders will want new stuff out of a system, on a regular basis for as long as it is running.
Implementation detail rot
Developers who built the system will forget exactly how they implemented things, usually within a month of being done. This perfectly normal process is why you need clean code and documentation.
Browser technology changes
Browsers are evolving rapidly. Because they are such a huge security target, they often implement changes in a short period of time that can break applications. Ask Flash, Silverlight, ActiveX and Java applet developers about this. Or people writing browser plugins in general.
2 to 5 years
New backend framework
The backend framework of your application will probably need to be changed within 5 years due to deprecation. These tend to be slower than front end changes, because they run in environments that are more resistant to change.
Updated web server
If you are building a web application, it is likely that the web server you are using will undergo major changes in the next five years. Web server developers tend to try and make changes transparent, but this can often mean having to make configuration changes at the very least.
Deprecated OS version
The OS version that your app was built to run on (or tested on) will probably become deprecated within five years. This is doubly true if you weren’t developing agains the bleeding edge in the first place.
Deprecated encryption and hashing methods
Whenever you are using encryption or hashing in your application to make hacking more difficult, be aware that advances in technology may mean that your “secure” solution is no longer secure. Depending on your platform, this may be tricky to switch out, especially if you are storing the hashed/encrypted data.
Hardware failures likely
Hardware failures happen over time. In the next five years, it’s pretty likely that something will fail on whatever machine is running your code. These failures may require moving to another system.
Updated legal framework
Laws are constantly changing, and the regulatory environment in which you designed your system may not be there in five years. This may require shutting down the app entirely, changing how you store data, or even adding features.
Manual rot
You’ll be making small changes over the years. The manual may not stay up to date, increasing support burdens. Documentation and instructions are often an afterthought, and a few years of changes will render them incorrect.
5 to 10 years
Deprecated platform apis
In a five to ten year time period, you can expect at least some of the APIs you are relying upon to go away. This can be due to security, due to other APIs becoming available, or any number of other causes.
Deprecated compiler or tools
In addition to your APIs going away, the compiler and other tools you use may become unsupported over time. While you may still be able to use them, they may no longer be supported by the vendor or have other issues.
“Dead Sea” devs
As your software ages and maintenance is required, you’ll also find that your development team tends to change. In many cases, this change can result in your team being entirely composed of people who couldn’t get a job elsewhere.
Processes built around assumption of bugs
The first generation of your users have expectations about how the software should work and will report bugs. The second and subsequent generations will learn the hacks that the first generation used to get around bugs that you didn’t fix. They may become dependent on the hacks.
Slower to surface new features than competition without tech debt
If you have competition, your old piece of software may be harder to change than their newer software. This can make competition more difficult over time, causing development to get more painful as yesterday’s hacks become part of today’s problem.
Knowledge rot
You will cycle through developers over a ten year period. It may be that none of the original developers are around. When developers leave, knowledge is lost. This snowballs impressively over a ten year span.
10 to 20 years
Devs getting hard to find and found at premium
In the ten to twenty year range, the number of developers still in the industry (at least those who remember how to work on software like yours) becomes more and more limited. Developers die, retire, and move into non-coding management positions. This gets expensive and you’ll be spending a substantial portion of budget on maintenance, instead of replacement.
No more forums for the tech
If you need to ask questions or get help with the technology, many of the forums, blogs, and other resources you used while writing the software will be long gone by this point. This also means that job boards for the technology are gone, which makes it harder to hire.
Hard to get data out of database with newer tools
Database technology ages as well. You may have an interesting time finding drivers for old databases in new technology.
Unaddressed zero day vulnerabilities
At this point, if a vulnerability is found, it may be in the wild before you find out about it. It may also not be patched. For instance, if you are using Pathworks (by DEC) and a vulnerability comes up, you may have an issue. Bear in mind that any developers who were on the mailing list are probably gone. Your organization may not be at the same address, either.
Surprise, major security changes around OS level APIs
You may be depending on APIs at the operating system level for various reasons (including speed), and those are likely to change as a result of security concerns over a longer time window. It’s also possible for such APIs to have reduced performance as a result of security changes as well.
Reverse engineering rot
At this point in the game, your engineers are almost certainly not the original crew and probably don’t have similar experiences. This makes it hard to reverse engineer your existing code, since it is hard to get in the heads of the original developers.
20+ years
All competent devs are dead/retired and noobs are expensive
After the 20 year mark, it’s going to be extremely difficult to find developers to replace any that you lose. You’ll also be losing developers as they retire. Replacements are extremely expensive.
Inability to get data in and out because of hardware changes
By this point, it will also be hard to replace hardware. This can mean things like connecting to a network, or hooking up an external drive, become more difficult. It’s not just that hardware changes, but mistakes are easier to make, since people aren’t used to the technology.
Data corruption and loss likely
At some point, some part of the system will fail. Depending on how short-staffed you are, you may not notice it in time and you might have some data loss or corruption. Data restoration may be interesting for the same reasons that it is difficult to get data out of the system.
Hardware vulnerabilities where infeasible before
The hardware you are using may have security issues (like timing attacks) that were too hard to do when the hardware was released, but are very reasonable with newer technology. If no one is paying attention to hardware vulnerabilities, you might have a breach for some time before anyone notices.
Cultural changes leading to verbiage and images meaning something else
Over a 20 year period, the meaning of words may be taken in an entirely different way. A good example of this is the floppy disk icon that is often used as a “save” icon. When was the last time you saw a floppy disk?
Cultural expertise rot
In addition to all the knowledge rot that happens over time, at longer intervals you’ll see basic understandings evaporate.
Book Club
The Pragmatic Programmer
This is our final week talking about The Pragmatic Programmer. The last two chapters of the book talk about the projects you are on as a pragmatic programmer. Chapter 7, the penultimate chapter focuses on the time before a project starts. This includes gathering requirements, understanding the constraints of what you are developing, and knowing when to start (avoiding analysis paralysis or jumping in too soon). The final chapter deals with the projects themselves. It looks at the larger picture of working with a team, establishing working rules, and automation and project wide testing. Remember these chapters and sections do not need to be read sequentially. If you are dealing with an issue on a project team you can jump directly to chapter 8 and read it.
Tricks of the Trade
Begin with the end in mind. It makes it easier to postpone the end, and it helps you reason better about surprises.
About darkmode for browsers, have you ever tried/evaluated Dark Reader? https://darkreader.org/
Thanks for the excellent list of events that will impact the life-cycle of our applications! One thing that I would add to the “2 to 5 years” list is larger changes to the business domain, tying this back to episode 132 on Domain Driven Design. In my experience from working as a developer within the ERP and CRM space, I’ve often seen such major changes in the business processes and the related domain in a 2 to 5 year time-frame that large parts of the solution has been rendered obsolete. Thanks for a great show and for providing such detailed show notes!