“A people without knowledge of their past history, origin and culture are like a tree without roots” – Marcus Garvey
I work in a business where there is a substantial amount of technical debt left behind by legacy applications created in technology stacks that are typically not in line with our current technical approach. What this means that we are bound for the health and welfare of the business to continue to support and maintain them as some are business critical and invest in moving them forward so that their lifecycle can be reset.
Many of these applications were built without the consideration of what a lifecycle of software actually is and how to monitor its growth, ROI and decline. The intention behind them was that the skills and expertise needed, at the time of inception and creation, were viable technical approaches of the time and that they felt significant confidence to retain those skill sets for support. This is not uncommon in business at times and usually gives rise to those “dark matter developers” who become deep system experts and just keep the wheels running in the background. I point this out not as a complaint or contention of their motives, even though I might disagree, but to say that all software, no matter how amazing it is has a lifecycle. And by ignoring this fact we place ourselves in jeopardy of creating debt in the future.
Just like driving a new car off of the show room, once it begins receiving use, wear and tear occurs and only routine maintenance extends its lifespan. Software is no different. Where we have a transportation infrastructure that supports the base car design, with effective maintenance we can actually extend probably well beyond projected lifespans the life of a vehicle. However, this analogy becomes more closely coupled if we think about something like an ambulance. A vehicle that is required to perform a task that supports the end goal of ensuring people arrive at the hospital safely and sometimes within a critical need for reliability. These vehicles are on a life span. We do not even think about having a “dark matter mechanic” that is the only one that knows this ambulance model that can fix it if broken down in a critical situation. Routine maintenance and routine retirement of these vehicles to be able to effectively meet the business need is performed.
This is the same zone that I see software within. Attention, care and feeding and intention to transition should occur. It’s necessary to protect the business aspects of which it is supporting. Where it may be a longer lifespan than an ambulance, it is still a critical need.
What I have seen, even from myself, is often dislike of the aspects of supporting these legacy systems. While they are often far beyond their lifecycle, it’s our responsibility as service to a business being successful to keep them running but effectively plan for their retirement or transition. I have witnessed, and probably been guilty of in my past, of complaining about the past and the problems it presents as opposed to looking at it from a more objective viewpoint of business support and use a more strategic approach to thinking about how to determine its state in the lifecycle and how we can optimize support and maintenance while planning to remove the debt of sometimes bad or dated technology.
Ways of Dealing with Legacy Applications
I have read several articles about this subject and one gave some good suggestions and the consequences of each. As I cannot recall the exact article, forgive me for simple paraphrase. When approaching legacy application debt, there are a few immediate choices:
- Isolate it – Move the application in a more virtual space to enhance recoverability. This still requires, depending on the stack, keeping certain skills on hand for support and maintenance but does allow you to use virtuals of production environments to test impacts in isolation.
- Modularize it – Start examining the underlying architectural structure and see if you can begin abstracting and replacing the logic and data layer tiers. This still means for a period, you have to maintain support in potentially a older tech stack but you begin addressing large areas of the backend to try and move it into a larger more supportable space if possible. This allows the presentation layer to stay preserved but you are still modernizing the business logic and data structures. This can be significant and daunting work but hopefully is least disruptive to the business.
- Ignore it – This is a model that businesses often choose and the end result is often critical failure that results in lost reputation, business and effectiveness. Using this model means you retain skill sets for which the market is sometimes small or non existent or the complete opposite in which you pay astronomical prices for contractor or service support just to ensure the application stays viable. Some people choose this option as it is easier to complain and some consider that often our career lifecycles with a given company are shorter than the concern of critical failure. In other words, we leave it for the next people to deal with. This is a bad plan.
This is not an exhaustive strategic approach to addressing legacy technical debt. Just three brief strategies that I read and found interesting.
Supporting Legacy Application Debt
What my largest focus is on personally is the cultural approach that we convey when approaching legacy application support and maintenance. I have caught myself on many occasions lamenting the design, implementation and current state of an application only to realize that something has to be done to resolve and issue. The image I used for this post is something that I came across that gave me some perspective on how I should look at legacy support to have a healthy outlook on its support and maintenance (and not abandoning the idea of its lifecycle and care and feeding).
In support legacy applications for a business a healthy outlook is to consider 3 central ideas:
Humility – This code was not likely purposely written to be poorly designed, unsupportable or confusing. A team of people created this program to support a business need of the time based on the skills and abilities they possessed to meet that need. In support of these applications, we often dwell on the implementation of the past without realizing that in the future our code will be supported by someone else as well who may levy the same critical eye. How many times have I written a piece of code or script only to return to it much later and wonder “what was I thinking” as I went through the code.
Ownership – Like it or not as the arm of the software maintenance and support group, we now own this software. Embracing that ownership in an agile manner means as the owner we search for improve opportunities that allow us to make it stable, reliable and maintainable.
Commitment – Again, as the owners of this code base and being an agile organization, we take commitment seriously. We have made a commitment to ourselves and to our business to do the job we are hear to job to achieve the highest value for the business. Part of that is often getting into the deep and murky waters of an older code base upon which the business has dependence. Our commitment to deliver the highest value should be just as solid here as when we make a commitment to deliver that next sexy market grabbing innovative product. We approach challenges as opportunities to learn, grow, expand and bring value addressing the need.
Again, I am not saying that we should accept legacy technical debt and bury our heads in the sand. We absolutely should learn to effectively define and manage product lifecycles and optimize care and feeding while keeping a constant vigil as to where they are in their lifespan. But when we are faced with supporting legacy applications, how we approach that work, how we view the application in terms of the business and how we take base level ownership of the code can make a world of difference in the cultural perception of the support of these legacy items.