So Why Do Systems Become Legacy Anyway? It’s More Avoidable Than You Think.
Article by Jon Butler
The obvious reason is that the underlying technology becomes obsolete there is not much that can be done about that but it’s really only a small part of the story. Much of today’s legacy was written in Java so what gives?
Well, there are a bunch of other “lifestyle choices” whose effects aren’t obvious at the time but will seriously affect the systems life expectancy over time, either because they lead to reliability and scalability issues or speed of change deteriorates. Here are some of the big "bad-habits" I came across in my career.
A deadline had to be hit
The worst thing that you can do with software is force it to be built in a fixed time-frame. Even when a time-frame is set by tech before the project starts, it’s usually a good guess at best. When corners get cut to hit dates, its usually the features that are needed to sustain the platform over the long term that go out the window. Doing the work after go-live will be the plan but this can get lost in the wash of post go-live issues and new pressures.
The case was not well made for focusing on non-functionals
Getting the project sponsors to really understand the importance of investing in testing, scalability, and resilience before it was a visible problem is a must for long term health. If this is not established in the beginning, the system lifetime will be marred with constantly needing to fit a square cost peg into a (much) smaller square budget hole.
The business became mature and stopped needing change
Without realizing it, sometimes the system goes into maintenance mode, the build out is done, the evolution of the new product or sales channel slows, and the required tech investment reduces significantly. This is a vulnerable time. If the funding is not kept above a minimum level, entropy will kick in and the system will go into decline fast.
The talent went elsewhere after the big build out
In a perfect world, developers want to architect and build new things; when the heavy lifting is done, talent starts to look elsewhere. It is harder to attract talent to work on an existing system and even if you find people the change in personnel can really disrupt the productivity of a team. It is important to be constantly thinking about how to keep the expertise in the building (if not in the team).
The system was a “1 business wonder” and did not get used anywhere else
Safety in numbers is critical. The more a system gets reused around a firm the better its chances of avoiding a premature “legacy” tag. But achieving adoption is tough. There is always a strong instinct from the business that using somebody else’s tech is going to be harder in the long run than building your own. Yes, it might be quicker, but will it do the job? and will i have enough control?
It was not built to be operate effectively and efficiently by others
When you sit down and design a system it is too easy to think about how to deliver the functionality and not focus on the tools needed to make it easy to operate. 40% of budget can get spent on support if it is not done right and much of this is because too much developer expertise and attention is required for too long.
Lacking a strong culture of test-driven development
Inability to test destroys a systems ability to change quickly and safely. A system needs to be designed to be testable with tools that make test running and results evaluation efficient. It needs discipline to write tests (ideally before the code) and keep them updated as functionality changes.
Strong culture of documentation, code reviews and code hygiene
Being able to make assumptions about how a system behaves is important. This is achieved in part by maintaining a consistent implementation approach throughout its lifetime. Proper code reviews are one good way to achieve this. Keeping complexity under control is everything – simple systems become complex not always because of complex features but because there is no consistency and unused code is not pruned.
Relationships with surrounding teams and departments are not effective
Pretty much every system is affected by the systems around it, that it depends on to deliver its functionality. Systems and the teams that surround them, tend to become fortresses and relationships combative not co-operative. Borders between teams are always frictional and so clean interfaces and data contracts need to be implemented to take the emotion out of things.
The data model was not thought through ahead of time
When systems change, the data changes. If the data model is not built to reflect the way the business will use the system and the way it is likely to change the effects over time can be negative.
So, building systems that stand the test of time is hard – what are the options?
With the benefit of hindsight, it can be argued that the right software development tools will help a lot by removing the need to solve and re-solve many of these thorny issues. Many of which are common across all systems irrespective of the functionality they provide. Making systems stand the test of time is complicated and requires constant management throughout its lifetime.
Application platforms like Velox allow you to buy solutions to many of the problems that lead to a systems becoming legacy before its time but unlike traditional 3rd party vendor solutions, allow you to make your own functional changes as you need them. Velox greatly reduces the execution risk of building a system and ensures you get the right return on your investment over the lifetime of a system.