Faberwork’s Notes and Trends offers new approaches and tools for companies to proactively address uncertainty and risk. Here we look at the management of an increasingly critical portion of a business’s IT inventory – technical debt.
Technical debt is any part of a firm’s IT inventory that is no longer meeting current standards. These are the accumulated assets of a firm – its code and systems - devoted to computer technology.
Faberwork’s extensive experience in managing legacy code can help companies grapple with this national priority. From working with both government entities and corporations, Faberwork’s perspective is that managing legacy code is not a spare time operation. Faberwork has seen how legacy code can quickly become a large part of many businesses’ IT portfolios.
Attention to legacy code, especially given the government’s recent comments on cybersecurity , is of high importance. Because of the growing concern about cybersecurity and the economic impact of legacy code, corporations and governments need to assign a dedicated and professional management team to oversee and track this as a business project. Like all technical projects, this one must have specific goals and meet key performance indicators.
The manager needs to be high enough in the organization, public or private, to command the necessary resources. The project itself needs to be assigned an appropriate priority. This is not easy for an organization.
Organizations tend to treat legacy code problems as merely sunk costs. It is in a sense for them water over the dam and not a path to new profitability or social success. Eventually, the legacy code needs to be re-platformed/re-written before it reaches the Software End of Life (EOL) stage. If this is not done well in advance, one may reach a point when the legacy code completely stops working or performs sub-optimally.
The head of Faberwork, Alok Pancholi, has a deep level of experience in the process. In the Q&A with our editorial team from eBooleant Consulting, Alok shares his guidance on technical debt, an issue of considerable significance for companies.
Q: At a high level, what does the problem of rewriting the legacy code boil down to?
Alok: Quite simply, the mission. Who is in control of it? And by that, I mean whose absolute responsibility is it to deliver on the re-platforming project. That person should be guiding the team through the process of ultimately updating and/or re-engineering the system so that it is more or less equivalent to the legacy system.
Q: What are some of the issues with legacy code?
Alok: Legacy code has several issues, and they warrant serious consideration. First, it isn’t easy to maintain legacy code. And then of course there can be performance issues. In many cases, we also have the skills shortage problem as most of the original developers have moved on to a new tech stack. For instance, these days the developers do NOT want to work on COBOL/Mainframes/Fortran/C-based systems.
Interoperability issues and integration challenges can be sizable. And these old systems, at times, don't inter-operate well with the more modern ones. For example, most modern systems use REST and JSON/XML, and the older systems use TCP/IP protocols with RAW-TEXT-based communication (for example, Electronic Data Interchange (EDI) format).
And finally, it is often difficult to upgrade the systems around the legacy code. For example, the underlying operating system (OS), the compilers, the libraries, and other components create serious potential incompatibilities.
Q: So, what should companies do about technical debt?
Alok: Theoretically, what is needed is to reverse engineer the software all the way to the requirements. In doing so, one must pay attention to how the replacement application will be tested and compared against the current one. The testing and comparison should be done at the component level (very granular). And what’s also needed is to re-engineer/re-platform the old system, which in many cases was written in COBOL some 30+ years back. It's very complex to rewrite it. Fixing the old code is a lot more complex than writing it afresh.
Preparation is essential. First, there is an exceedingly high probability that these legacy systems will keep running and suddenly one day just stop! One option is to isolate the legacy code and not upgrade the software around it. This can help buy some time but also exacerbate the risk. Eventually, this may not help because the software is all connected, and the systems’ components are not independent of each other.
So, suppose you upgrade the operating system, and this requires upgrading the version of Java, and then Java requires upgrading the networking. The ripple effect can force an organization to upgrade all of its systems at once and that can be too sudden.
Q: Can you share some of your experiences working on legacy code in the public sector?
Alok: I was the technical lead for a 20-member development team for a department within the US government. We worked on re-writing the legacy code from COBOL/C to JAVA. It was a great experience working with talented developers and navigating complex code for over four years.
There were many management professionals involved, however, so full ownership of the project was not always clear. We often needed to understand the big picture and how our pieces integrated with other parts of the operation. Each new building block needed to be verified at a granular level to ensure that it matched the input and output of the LEGACY system. This was not effectively done. But we developers forged on, leveraging our skills with the guidance provided.
Q: And how have you addressed Technical Debt for clients in the corporate world?
Alok: We have one client for whom we have spent several years focused on technical debt issues. In the past, this client had been deferring legacy remediation because management didn’t feel that it needed to be done.
However, one of their customers asked for information on how they managed legacy code. Then it became clear to the client that their legacy code problems had been ignored for as much as four or five years. It needed to be cured now. The enterprise-wide system needed to become stronger and perform better before new functionalities could be added. As with any debt, continual efforts to address accumulated technical debt is the key to having a reliable and maintainable system.
Any parting thoughts?
Alok: Here is the question that customers should ask—how are their software providers handling legacy code? Virtually all companies should be expected to be actively involved in technical debt clearance as a matter of good practice.
Technical debt encompasses more than just legacy code. It includes all types of obsolescence in a firm’s systems. However, the lessons of legacy code apply to the whole portfolio of technical debt. Many firms know they have the debt, but they feel they can get away with ignoring it for now. However, suboptimal systems yield suboptimal performance. The right time to start managing them is now.
Thank you, Alok. Our readers appreciate these insights and look forward to more.
