This post tries to summarize my professional experience with legacy code and define the scope where MDD can help with it.

In recent years there has been a debate about how to define legacy code. I am probably not qualified to attempt any formal definition, but I am going to give one that corresponds to my experience.

Legacy code is that type of source code you are required to work with when you join a team of an already long-running project and you, like most of the team, don’t have a clue, not only about what the code does, but also about what the software is supposed to do. In a high percentage of cases you are immediately told by senior team members that the documentation is out-of-date, if available at all.

Very soon, new requirements, or, worse, “bugs” to deal with start to arrive.

Should they come either from a newly agreed set of requirements, or a formal test procedure, or from a phone call of an angry customer, the situation is the same, the new member is hardly in the position to deal with the requests with the necessary confidence. Add to that the pressure from the Project Manager that sees a red bar about bugs growing up in some spreadsheet and the life of the new member may become immediately very miserable indeed.

I am sure many of us have been there and you know what I mean.

Luckily, Model Driven Development can help in these situations. It’s not a panacea, also because it can have different levels of acceptance in different teams, but it’s the process that I have used every time as soon as I am given access to the source-control system of a project, with a very satisfying success rate.

From a practical point of view, we need to understand what the customers have requested the developers to do, based on what the developers have told the computer to do in their programming language. The process is called reverse-engineering. In theory we could look at the code and create the model ourselves, but this would be (extremely) time consuming even for small projects.

Here is where tools for “round-trip engineering” (meaning, in essence, forward- and reverse-engineering), like Enterprise Architect and few others, can help.

Developers normally create different “programming entities” in their languages to implement the requirements. They are normally classes, functions and more.  Together they form the Structural Environment of the application. These entities work together by exchanging requests and data. In other words, using them the behavior of the system is implemented. Generally speaking, MDD tools are better at finding the structural entities in the code than at reporting the behaviour of those entities. However, capabilities for creating behavioral reports are generally much better for interpreted programming languages like Java and C#. This and related posts will concentrate on reverse-engineering to find the structural entities in the code.

The first important aspect is to define the scope of the intervention. This may vary from the need for a quick, personal “ramp-up” in a new project to a complete commitment of the whole team to MDD for the future and the consequent refactoring of the code. The second limit of the range has never happened to me in my now long professional career.

MDD is normally embraced from the beginning of a project. If a team decides to use different technologies it’s very, very unlikely that they will accept the cost of refactoring at a later stage. You can hear managers saying “Why should I spend money on refactoring something that works?” Nowadays the same tools used for MDD also support almost seemless code “synchronization“, that is, reverse-engineering the code written by programmers into a UML model. They do it pretty well, it has to be said, thus creating something like a CDD “Code Driven Development” process, which gives the false impression that we can have both things starting from the code. My experience tells me that this is normally considered good enough.

However, we shouldn’t forget that the model of a system should be the result of agreements with the customers and that the source code is just a translation of those agreements to be performed by a computer. Of course, we could write code, in small incremental steps, test that it does what the developers want it to do, “synchronize it” in a UML model and then rush to the customers and ask them continuously if that it’s what they actually wanted.

My recent experience is that this process resembles more a Brownian motion than a proper path to a specific goal. And it seems that I am not alone. My previous post shows a study about a project that resembles quite a few projects I have been involved in and not using MDD.

Because of all the considerations above, my next post will be written thinking about a new team member who needs to gain knowledge of some code as soon as possible. Simple techniques about reverse-engineering will be shown.

Notice on copyright holders

Visual Studio is a registered mark of Microsoft Corp., USA. Enterprise Architect is a registered mark of SparxSystems Ltd., Australia. Embedded Engineer is a registered mark of LieberLieber Software GmbH, Austria

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.