Refactoring legacy code

We have extensive experience in modernizing and refactoring legacy code for applications in engineering and science. Many of our customers have software that has been developed over several decades. From time to time, a refactoring is needed to weed out clutter and to prepare the code for further development.

Essential but outdated

Many of our clients rely on computing software that has been developed inhouse over many years. It is the codification of decades of experience and a world of knowledge. So, this software is not easily replaced.

But the quality of the code is often poor. Sometimes, parts of it were written as long ago as the eighties of the previous century. In those early days of software development, people had less knowledge about programming in general. And the fact that various generations of developers have worked on it, each with his/her own style and skills, doesn’t help either.  This kind of software is known as legacy code. That may sound nice, like some sort of treasure that was left for future generations. But developers are usually not too enthousiastic about it.

As long as the software is just used as-is, everything is pretty much ok. But when something needs to be changed, the poor quality starts to hurt. Then it may be necessary to modernize part or all of the code or to improve the quality by refactoring.

Modernizing and refactoring

Our scientific software developers work on legacy code almost every day. Over time, we have developed methods and techniques to deal with such code efficiently. Here is a couple of examples of what we typically do:

  • Split large pieces of code into smaller units that are easier to understand and to test.
  • Replace outdated language constructs by modern ones.
  • Remove language constructs that are known to cause problems, like COMMON blocks in Fortran.
  • Create internal documentation (code comments) and improve naming of variables to make the software better readable.
  • Reorganize data structures into more meaningful entities.

Before we start to make changes, we will develop a proper test suite together with the client. This is part of our strategy to make sure that our changes do not introduce errors. In fact, our changes often reveal errors that were there all along but were never discovered.

In most cases, there is no need to change the entire code. Large parts may remain untouched as nothing needs to change there.

Is legacy code an issue for you?

If you have a problem with legacy code, please contact us to discuss what we can do for you. If you want to know more about our approach to legacy code, the blog series by Koos Huijssen may be of interest to you.