Usually when we think of “legacy software” we think of applications written in COBOL and located somewhere on a mainframe. This mindset leads developers to create their code without looking ahead and thinking about who should read it later.
“The moment you submit code, it’s legacy software,” said Jean Yang, founder and CEO of Akita Software. The question arises what a smarter use of legacy code could look like.
One problem with code: it’s never really static. Or as Charity Majors, co-founder and CTO of Honeycomb, puts it, “You really don’t know how the software is going to behave until you put it into production.” It wasn’t until production that the cracks in the “old” code became apparent, Majors said: “A small piece of code is a complicated system, but once it’s up and running, has users, traffic patterns and underlying infrastructure, it becomes complex. You can not predicting what will happen if you change something. You have to observe and see what happens in a controlled environment.”
“Individual engineers can write software, but only teams can deliver, deliver and maintain software. The smallest unit in software delivery is the team,” emphasizes the Honeycomb manager.
We could pretend that the problems (bugs, errors, etc.) are technical problems with our application, Yang, her interlocutor, adds. However, according to the manager, this misses the point: “It’s always a human problem. You always have to trust people. And most tools help to find out what people have done in the past, what they have done recently and what caused these problems . It’s all about people.”
That brings us back to legacy – and observability.
“The longer it has been since software was created, the more the cost increases when problems need to be found and solved,” Majors says. Therefore, observation tools can be a tool to solve problems within minutes. They ran the code in controlled production, allowing developers to debug their old code shortly after it was written — rather than decoding it months, years, or even decades later.
That is also why good documentation is that important. It’s not just used to make sure others get along with the code we’ve designed. Simon Willison, founder of Datasette, explains that he also writes the documentation for himself, otherwise he often forgets why he wrote the code in a certain way: “When I come back to the project in two months, everything works, and I know where everything is because there is extensive documentation that helps me – and others – get back into the code.”
“Part of the development work is ensuring good documentation, good unit testing, and good observational capabilities,” Majors says. “It’s the only way you can see how the code behaves in combination with different systems and conditions. In the IDE you will never understand the code – you have to run it and then watch it.”
And what about those who want to work with your code years or decades later? Software development expert Avishai Ish-Shalom say it so recently: “Our ‘modern’ infrastructure such as Linux, MySQL, PostgreSQL etc. is decades old – even ‘modern’ clouds are now in their mid-teens. More disturbingly, this infrastructure is proving significantly more flexible and stable than our most optimistic predictions – but signs of aging are visible, making maintenance and development more difficult year after year.”
We all live in a legacy world, both new and old legacy systems. We (sometimes) move from monoliths to microservices, move from disk to RAM, and do many other things when we encounter hardware or software limitations or see opportunities to take advantage of new developments. For those dealing with systems that are years or decades old, things get worse, as Yang explains: “Any system built in the past year has the same characteristics. But with systems that are five or ten years old, It’s a different story. Every legacy system is obsolete in its own way.” (FM)
- Tobias Leicher, IBM
“No front-end will survive 20 years because it is very subject to fashion. However, to design things that have become established and consistent over the years in such a way that they can be easily reused, the programming language alone is not decisive, but a good cut, easy access and dealing with the technical debt. It’s important to learn how to manage applications that have built up and reduced technical debt over the decades and that have remained innovative without seeing technology as the sole driver. IT is one of the few technical disciplines where we rarely learn from existing good software systems. After all, nobody learns to build a motorcycle without first looking at an existing one. Why don’t software engineers just collect good code and learn from it, think about design patterns, how good applications and algorithms are implemented and teach others that way?”
- Dr Georg Loepp, Cegeka Germany
“But legacy systems also have good things: strong governance with, for example, uniform design specifications for the architecture. However, with the proliferation of client-server architectures, these have largely softened. But when it comes to governance processes or scalability, we can learn from legacy systems. Many modern architectures must first implement standards that were available out-of-the-box in previous mainframe computers. That is why, when choosing a possible replacement, you must carefully consider the degree of maturity of new technologies in advance and, above all, weigh the costs and benefits against each other. Do existing systems really need to be replaced or can they be modernized so that they can be better integrated and continued cost-effectively in the new world?”
- Dr Karsten Ballueder, Deloitte
“Today we have a very different way of developing software with a focus on functionality: Much of what a software application is supposed to do is made available through freely available frameworks. Developers therefore only focus on what is customer or application specific. Even with COBOL applications, the actual business functionality usually only makes up 20 percent of the entire code base. If you manage to find these valuable nuggets of functionality in the legacy systems and transfer them to the new world, then you have found the silver bullet because you only focus on the things that are really important and valuable to the business. ”
- Martin ReuschMicro Focus
“There is no one way to modernize legacy systems: the degree of maturity of the applications plays a major role, as do the individual challenges of the company. What do you want to achieve as a company and where are you in your current application development? Of course, there may be applications that actually need to be rewritten. But with applications that deliver real individual business value and are fit for modernization, it’s not enough to do something quickly and then do nothing for a long time. One should try to achieve a continuous modernization in order to keep it stable and functional in the long term. Like the Golden Gate Bridge, which is painted and maintained daily to keep it passable.”
- Heidi Schmidt, PKS
“The technical problems are already challenging enough. There are tools to gain transparency about the technical mess. However, these are useless if people are not able to put it forward with a common idea and with a common understanding of the real problems. It is essential that the department and IT speak a common language again, because the IT strategy must always be derived from the business strategy. This is a major challenge for the companies as they are under pressure to act simultaneously. Many still hope that with a short course of therapy they can solve all these problems in one go. But those don’t exist and the longer you experiment with such tablets, the more expensive it becomes and the more time you lose.”
- Constantin Klein, syntax
“How companies can keep their system landscape modernizable, of course, depends on whether they build their own software or whether their total landscape consists of many different solutions. There has to be a strategy for this and that is exactly what many software manufacturers (ISVs) face as a major challenge. They should ask themselves how big the scope should be for an application that you want to sell in bulk if possible. Anyone who has tried to develop the most comprehensive system with a lot of functionality for a specific industry or problem will have to make their solutions more open and easier to integrate in the future. On the one hand, to remain relevant in the software market. On the other hand, to enable business customers to embed a software offering into their own general architecture.”
- Gerald Hoff, T-Systems MARS
“There’s just a lack of people! And that’s what all companies struggle with. Especially when it comes to those with expertise who can operate such systems and are also responsible for them. They are hard to find and none of the young people want to an old energy company that produces CO2. So how do you make companies with legacy IT become so exciting as an employer brand that young talents really want to start there? pick up even with a small unit.”
This post is based on an article from our US sister publication Infoworld.