Imagine a world where, every 10 years, the gauge of train rails, the resistance of rail beams, the size and voltage of electrical outlets would change. Well, this world is the world of software development.
Under these conditions, one could imagine that it would be wise to just throw away old software to develop new ones. However, this is complicated for several reasons.
Why we don't throw away old software
First of all, this software is often essential to the proper functioning of the companies that use it: without it, there is no business. No one imagines a supermarket without stock management software! It is therefore not possible to get away from it.
Then, developing software is a long and expensive process for companies. This is all the more true since nearly one in three projects fail: either it was abandoned before the end of its development, or it experienced overruns in development time or money, or it does not respond perfectly to the needs of the users. Rewriting software also means being able to correctly capture the business and the field in which it will have to fit. A few years ago, the overhaul of the military payroll software was such a fiasco that the minister himself had to take action. This project has also cost a lot of money to the French state.
In addition, any software development brings its share of bugs. Development techniques (such as agile development, intensive use of testing, continuous integration, etc.) make it possible to reduce their number before delivering the software to customers, but it is common for some to remain. As a result, rewriting software is often dangerous: software that has evolved over the past 30 years has had years of patches to correct its flaws and bugs.
Finally, users are reluctant to change. It often happens that users complain because the position or color of a button has changed. Faced with completely new software, with new graphical interfaces, they can find themselves completely lost.
Under these conditions, it is easy to understand that companies, whatever they are, seek to keep as long as possible a software on which a large part of their operation is based.
It will therefore be necessary to maintain this software to meet new user needs, new laws, new technologies… Indeed, only software that is successful, that is to say that is used, is maintained. .
Software maintenance
There are two main types of maintenance: that which occurs on a daily basis and which concerns a tiny part of the software, and that which occurs more rarely, but which concerns a large part of the software. In the first case, a microscopic vision is sufficient, while in the second a vision that is both macroscopic and microscopic, global, but precise, is necessary. It is this type of maintenance that is in question here.
Maintaining software is often very complicated, and often places great stress on the developers and companies that must maintain this software. This can be explained by several reasons.
Maintaining or upgrading software is a complicated task.
Yuri Samoilov/flickr, CC BY
Software complexity.
Although abstract to most people and taking up as much space on a hard drive as a few MP3 songs, software is often very complex. For example, if we had printed the Windows code on A4 paper in 1993, we would have had more pages than the Encyclopædia Britannica (in 15 volumes) or one floor of a building. Ten years later, printing out Windows 2003 code would have resulted in a stack of papers taller than the Statue of Liberty. Since then, the amount of code has only increased.
The lifespan of software and the renewal of teams.
The duration of a software is dictated by the business, the possibility of meeting the needs of the customers in a given time and the possibility of investment of the publishing company. It is clear that the majority of mobile applications do not have the same lifespan as software that runs entire companies. These can have a lifespan of 20 to 30 years.
This long life means that often the developers who designed this software are not the ones who must (or will have to) maintain it. This makes the development of software even more delicate: it is difficult to work on programs that one does not know and that one understands only imperfectly. In addition, it is common for several people with different ways of coding to be involved.
The use of programming languages unknown today.
Finally, some very large systems (used by banks or insurance companies, among others, and having a central role for these companies) are written in languages that even Google does not “know” (like Mantis). Other languages have very little online documentation (like Natstar). This means that very few people know about them.
An example of a maintenance requirement.
The Berger-Levrault company makes massive use of the GWT (Google Web Toolkit) in the software it develops for their graphic parts. Well, that was before. Indeed, GWT has not evolved since 2015 and is no longer maintained by Google. As a result, new web browsers will soon no longer support this technology, and it becomes difficult for developers to make fixes or improvements. It is therefore essential for the company to change technology and use a more recent one. The company estimated that it would take more than 8000 man-days (i.e. the work of one person for approximately 22 years), and therefore several years with a team of several developers, to migrate a aging application and switch GUIs from GWT to Angular. But by then, today's target technology will be obsolete; they will have to start a second migration again before they have even finished the first one.
However, IT tools can help shorten this type of migration.
X-ray old software for more efficient migration
To face these modern challenges, our team, RMOD, as well as other teams in the world, develop tools which will help the developers to better know their software, and to help in decision-making.
Our tools work like x-rays to the human body, but on software. Thanks to them, developers can obtain maps of their software at different levels of granularity. The information removed from the software can be of several types:
How is the software structured?
What is the most used part?
Is the quality of a part good enough to be reused?
Which parts are tested?
In addition, an architect or developer can also define specific requests that only he (as an expert in the domain and in the software) may want or need to express. It's hard for us to illustrate without getting technical, but here are some examples. What are the subroutines that use class X, knowing that normally there should be only one user of class X? Can we split this program in two, considering that the blue data are all called by blue operations, and the same for the red ones (if we consider these colors as properties of program elements)? Which operations use both colors and prevent clipping?
But we can also extract information about the developers responsible for a particular part of the software. Indeed, there is a somewhat macabre metaphor called the Truck factor, which expresses the following thing: what is the risk for the software (and therefore for the organization that uses it) if one of the developers is run over by a truck, or, in a less violent way, if he quits his job? How much knowledge does this developer take with him? What information does the company lose on its software? Indeed, as we have seen above, having to work on software that you know little or nothing about is much more delicate than if you know it perfectly.
Finally, our tools also help developers to reorganize their system, for example to make it more modular. Thus a part can be changed or used separately without impacting the rest of the system, thus making maintenance simpler and cheaper.
Such solutions make it possible to automatically migrate part of the application, and can save more than 60% of the time. For example, an architect from a large German firm told us that she spent 7 months manually restructuring the code of a strategic application for the company, whereas with our tools, she completed the same task in two weeks.
This article was written in collaboration with Nicolas Anquetil, lecturer in computer science and software engineering at the University of Lille
