During my talk at the “ScaleUp 360 Legacy IT Europe” conference, an important part of the discussion was about the notion of Legacy. As usual, it was very interesting to see that each speaker presented a different perspective, very frequently based on marketing concerns. So for many people, legacy is IBM, Cobol and SAP.
This article takes up some parts of my talk about my personal vision of what a Legacy application is.
So, I propose you to browse with me, the stereotypes of Legacy applications and reach a personal definition.
The Software age
Legacy applications would be old software. What is old software? 1 year, 5 years, 10 years? Does modern software work better than old software? Is a young software a promise of lower maintenance costs and a more elegant design? Nothing is less certain.
The technology, a symptom to throw your Software?
At SALT, the majority of our IT staff is composed of very young developers, many of whom are trained at the famous Xavier Niel School 42. Developers, who code above all, sometimes without any theoretical background and with excellent training in the latest technologies.
According to a widespread belief among young developers and our technophile architects, old technologies make Legacy applications. We could do a survey among you: what is an old technology, can you tell me about it?
10 years ago it was Cobol, RPG, Ideal, ABAP, or even C/C++.
Today my young developers tell me .NET , ASP.NET, Java (and the many frameworks), but also recent technologies like Spring if you use old design methods.
PHP and Python at the head of technologies hated at home, in spite of the revival thanks to Data scientists.
Same thing for application servers (Websphere and Weblogic top hated JEE stack), databases (SQL is so OK Boomer), and JS frameworks every two years, a new one.
Deploying JARs or servers is also a has-been, who doesn’t use Docker?
So are these technologies a good indicator for a Legacy application?
Process and lack of skills : the ultimate sign of an abandoned software?
In my career, I have encountered situations where software, maintained for years by a software publisher, software sold with a version cycle, licenses, could no longer find a team to maintain them.
This software that we no longer like, had customers, huge business expectations, the competition was pressing from all sides. For example, a customer, the 4th largest French software publisher since bought by an American fund, specialized in finance. Upmarket offices, central Paris, attractive pay, good multicultural atmosphere: no applications, no internal recruitment, even service companies couldn’t find anyone.
I attended the end of a job interview with two service company candidates while I was carrying out a side migration project. To my surprise, they gave an immediate answer, two NO. Confidence at the end of the interview: “suppose I maintain your software for 2 years, I lose 2 years to progress on “saleable” skills, my CV loses 2 years.
Another software publisher listed on the stock exchange supplier of the largest yellow pages search engine in France. Did you know, the indexing engine written in C++ was maintained by a single person close to retirement, with health problems 500 km away from the R&D center. No one had ever gotten their hands on this software for at least 10 years and the project managers had no idea how it worked except for a few absconding notes left on an old Wiki. We made the transition to younger teams and integrated with the rest of the R&D team.
At another publisher, the salespeople complained that the installation and operation manual was 80 pages long. Our competitor installs in 1 hour. We need two days. The complexity of the process of releasing, building, and deploying the software was infernal. We proceeded to a “game” with the customer. We put one of our engineers and one of theirs side by side to generate the software deliverable. Result: each produced a different version of the deliverable by following the instructions. Not a real deterministic process.
Market evolution consequences
Among product owners, the functional productivity of an application is often neglected.
Here are my favorite questions to discover and get to know an application:
How long does it take to learn about the application? For a Senior? 5 Days? For a Junior 30 Days?
What is the load needed to write a simple graphical form? Complex? Including, specifications, coding, automated testing, and intermediate release? 1 Day? 5 Days?
Quoting these numbers to a former client of mine, the CTO blushed and said 60 days, and we just tested the passing cases. What a tragic performance.
My personal definition of a Legacy Software
Enough anecdote. I propose this definition for the Legacy. All Legacy applications have one thing in common: they have customers or a very strong business expectation. And they are asked to evolve, either abruptly (pivotal) or quickly (functional and technological backwardness) in the face of faster competitors.
Why it cannot be rewritten? Contact me for more information.