Legacy code is a synonym for unmaintainable code, monolythical systems and old technology.
In other contexts building legacy is something positive. Now building legacy is synonymous to leaving something valuable for a next generation.
Could we turn our legacy in something more positive? In a way we could put it on the balance sheet, in black.
How to approach this. Some thoughts.
Innovation while constructing
In most project delivering business value has the highest priority. Technological innovation and renovation are nice to have, and are often postponed under the pressure of time and money. Thus projects are slowly transforming the legacy code into even amorphous Corpus Logarithmum.
To mitigate this, in every project include some portion of technical innovation or renovation. Not as a nice to have, but as a must-have deliverable. This way make improvements and avoid turning functioning code into atrocious application molochs.
Investing in Software Archeology
99% of the stuff we do is building on existing code. Legacy code. And you are extending the legacy with increasing speed.
So we are a software archeologists (I think the term was invented by Grady Booch). We need to understand what the generation before you did. And improve it.
Software archeology isn’t just digging into code. It is digging into people’s heads. Souping up the knowledge in there. The knowledge they did not get the time for to put on paper. Booch calls it “tribal memory”. If there is anything on paper – or in some Folder, Document Management System, Drive, wherever it is growing mold. Don’t believe what is on paper.
Building for integration
We see many problems with old programs when they contain business logic that you want or need to reuse. At some point in time you will want to reuse what is already build. Then you must get to that logic in the legacy program. You’d better have a good interface. Or you will have to make an effort to open up your applications at a later date, which then mean a major operation on stuff you haven’t touched in years.
A insurance company had this very efficient life insurance system. All of the policy rules were coded in such a way that they were not accessible from outside these program. Then the internet came, and the life insurer needed to add channels to their business that needed access to the same policy rules. But they were not accessible. A significant re-engineering effort was required to break open the old application and allow the logic to be reused in other channel programs.
So it is best build new stuff such that we can always expose well defined interfaces. Service orientation may have been a big hype and it is behind us now, but the concepts of service-orientation, thinking in terms of service encapsulation and exposrue are evergreen. And by the way date from way before the SOA hype.
Building for automation
Legacy is mostly built with a past operating model in mind. Which means requiring a lot of manual labour to be executed by aging staff that have the knowledge in only their heads. Therefore you do not just want to rebuild and extend legacy code, but you also want to replace the workforce by programs. The programs that control your programs automate your development and operations. And automate your business of IT.
Building for longevity where needed
With today’s need for speed, a stream of throw-away software emerges. The life span of mobile phone apps seems to be less than a year.
Building backbone applications is different.
These are apps that can not be thrown-away in 3 months time. This is software that must last for years.
Therefore they must be maintainable.
You can’t afford a weekly app update. They must be right first always. Every bank knows what happens if the banking app shows an incorrect account balance. Twitter explodes.
It’s more like chess. You set up the opening with the end-game in mind. And you write down every move, so you can analyse the game later. See where you went wrong.
I was brought in by the CFO (also responsible for IT – not generally a good combination) of a small bank in Switzerland. They wanted to expand into Russia and Asia. So their system needed to support Cyrillic and Chinese characters. But it currently could not. He wanted to know what they needed to do to change their systems to support these character sets. So I investigated this for him. The bank’s application weren’t maintained for many years. The middleware and the database management system were very outdated. Beyond a point where migration to new technology was an option. Bad news for the CFO. And he for his shareholders. Hadn’t he cut cost on maintenance, the business might have been ready for expansion. Now they were hindered by their systems.
You don’t need to me psychic, but you can take measures that can prepare you for the future.