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.