Loving Legacy Code

Many developers want to "rewrite the whole application" and "get rid of all that sh*t". Most of them are pretty blank when I tell them that I really like working on such code bases, even if I just jumped into the code. I recently talked about that to the other Qafoo members and all of them agreed to my views. Therefore I want to explain our love of legacy code in this post.

The first thing to realize about existing code bases - no matter how bad you feel their quality is - is that it provides business value. The code is in production and people use it and gain value from that. For us as developers that means: The business rules that the appplication is meant to reflect are already written down in code. There is no need to discuss the purpose, how things are meant to work and which goals should be achieved. We already have a machine readable version of the business vision and it works. One of the biggest issues in software development has already been taken from our shoulders: Understanding the business and implementing a solution accordingly.

When implementing a new program on the green field you have a high amount of uncertainty about the eventual goals. Extracting and documenting requirements is a tough part for all stakeholders and many iterations need to happen before we even reach the stage where software is usable and production ready. Which applications that have grown throughout years these steps have already been done. As developers we can read the eventual decisions how the software should work: It is already there, written down in a language we can naturally understand: Code!

Even better we also know what are common change and extension points and use the technical patterns which are optimal for the change we saw in a couple of years. Developers are often wrong when anticipating change, but in this case we can analyze the past development and have data to base on when anticipating change.

Now we "only" need to move around the code so that its functionality does not change but that we can better maintain it and get rid of technical dept. Of course this is not a picnic, too. But instead of tackling on an additional layer of complexity we can focus on refactoring. If we created a good refactoring basis already, we can even perform that task on the go beside implementing new features and fixing bugs.

I could even go that far to tell you that implementing software on the green field is rather boring for me. Of course there are always smaller parts which are interesting and challenging but most tasks are just boring. It's different with unknown legacy code bases. You need to be creative to apply at least a minimal amount of testing before you can start to refactor. You need to follow the minds of multiple developers of which some even might not be in sight anymore. You need to understand what patterns are realized in a software, what would improve the code quality and find ways to reach that goal without disturbing every day work. This is the interesting stuff. :)

In legacy software you can let technical patterns emerge for a proven domain.

You can read more about refactoring approaches which can help you in our posts on Extract Methods and Extract Services.