The car is in the shop, again. The mechanic looks at you with that long face and hands you the diagnosis: alternator failure. You mutter to yourself that it’s the second time in a couple years that this, supposedly, durable part has given up on you and left you stranded on a snowy road somewhere far from home. Not for the first time, you are left wondering if it’s worth sinking more of your hard earned money into this troublesome car, or if it’s time to divorce yourself from an undependable vehicle. We all know these things happen, things break down and need to be replaced, but how can we tell when the platforms and services we use should be deprecated? From my experience, here are a few good warning signs that it might be time to move on.
Contradictory Documentation
The first thing I look at with any unfamiliar piece of technology is track down the documentation. This has, historically, given me the biggest insight into the lifecycle and current maturity of the platform I’m working on. If there is no documentation, it usually means the platform is bleeding edge and speed of development is the main priority. Sometimes the pace of development means documentation gets left behind, and I don’t always associate that with doom and gloom. However, when documentation is robust in some areas and sparse in others, red flags start to trigger.
"Documentation tends to expand when the pace of development slows and everyone gets a bit more breathing space. I find it is often the pivotal time in a platform where it either starts to age gracefully or develop tumors and thorns that spell trouble down the road."
If there continues to be an effort to expand the documentation, there is usually an effort to continue to improve. However, when documentation becomes contradictory and not even remotely portrays reality, that is when it might be time to start fresh. Platforms that have gotten to this point rarely have aged gracefully, and instead have developed contradictory anti-patterns and are usually incredibly difficult to update or modify. Platform updates seem slow? Ask the team working on it if the documentation is accurate, and you just might be surprised.
Heavy reliance on institutional knowledge
In lieu of actual documentation, there becomes a heavy reliance on institution knowledge. This leads to a problem known as the “Hit By Bus” problem, where if one person were to be incapacitated everything, from debugging to development, would halt. If your platform would fail because one or two people leave, you have a major issue. And despite what you might think, quality developers hate having that burden on them, as it tends to mean many late night phone calls debugging and a general nagging angst that leads heavily to burn out. Just as you wouldn’t want one point of failure to collapse a system, no one person should be a point of failure.
Cluttered or inconsistent data
“Dirty” data is the slow poison that collapses platforms.
The more the data becomes cluttered, or rife with inconsistencies, the more time is spent trying to program or implement fixes or workarounds for that data. Workarounds that cause the expansion of institutional knowledge and development difficulty. A lack of adherence to data quality standards is usually a hallmark of a lack of quality throughout the system, and is an incredibly difficult problem to resolve. It’s paramount that data in a platform stays as clean as possible, and when it starts to deteriorate its a worrisome sign.
Non-existent or non-representative test suite
Every platform should have some form of automatic testing. It’s not worth discussing the extent of the testing, or the type of testing as there are many other resources that can beat that topic to death. However, the bare minimum of a test suite should be one that gives the people involved making changes some level of comfort that they didn’t completely brick everything during routine changes and maintenance. Not saying that testing would remove all bugs or issues, or prevent them from ever happening, but they should serve to act as a guide rail for developers to check to make sure that their updates and refactors are still providing a relatively stable system. Attempting to refactor or work on a platform that does not provide even this rudimentary level of testing is like trying to rebuild a moving car at night with only the light of the stars to help. If it’s too hard to write tests for, it may be a sign your platform has reached end of its life.
Pain of Development
If changes to a platform or system feels like it’s akin to pulling teeth, that is a sign that a rework might be needed. Platforms should help foster a sense of agility and adaptability, because the pace of technology is fundamentally swift. A platform should empower an organization to react to changes and needs quickly. The key of anything is adaptability, and if a piece of technology isn’t adaptable it is not worth having. It is a hard metric to judge, but it’s a worthwhile indicator that a revamp might be in order.
Counter: Working code works
While it may seem tempting to trash and rebuild, sometimes it’s worth considering that legacy, old, and complex code is working code. While it may seem counter intuitive, sometimes sticking with what is working leads to a better outcome than trying something new. The most important thing with deciding if it is time to move to something new is if it makes sense to, and that is where having experienced outside audits are helpful. Sometimes the grass isn’t always greener, and it takes another set of eyes to help highlight that.
