By Tobias Schlitt, first published at Tue, 04 Apr 2017 10:04:31 +0200
Download our free e-book "Crafting Quality Software" with a selection of the finest blog posts as PDF or EPub.
You can also buy a printed version of the book on Amazon or on epubli.
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.
Qafoo experts can kick-start your team with a continuous refactoring process. We can show you how to improve your source code quality on the go and help you to get rid of the big quality chuckholes in your construction site.
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.
Stay up to date with regular new technological insights by subscribing to our newsletter. We will send you articles to improve your developments skills.
Edorian on Tue, 04 Apr 2017 11:37:27 +0200
The only legacy code we get to notice is the one valuable enough to a project/business to keep it around. Everything else is discarded along the way.
Link to commentOr to put in in other words:
"The reason we get to fix it up now is because it was good enough to get us to this point in the first place"
Jenko on Wed, 05 Apr 2017 10:24:31 +0200
Came to the same conclusion recently too.
Link to commentThe one thing I'd add is when working on legacy, you get a feeling that everything you're doing is making it better, you can't lose! Which helps massively with motivation/enthusiasm. Often on a greenfield project, one wrong turn and the enthusiasm you have for working on it fades quickly.
Legacy FTW!
Jeroen De Dauw on Fri, 07 Apr 2017 14:35:21 +0200
While I agree that working on legacy code can be a lot of fun and comes with its own unique challenges, it seems my view on business requirements in legacy projects differs.
Link to commentWhen you come into a legacy project, you do not know if it is doing what it is supposed to be doing. Presumably it does not of the things, and what is missing are bugs of a sort, which might or might not be tracked somewhere. Conversely the software might be doing many things that it does not need to do. This does not need to be straight out anti-features. It can be features that are not needed. Some of those might damage the user experience by means of feature clutter. Some might not matter to the user at all, such as unused API endpoints.
Furthermore, requirements change. So even properly implemented features might reconsideration.
So IMO legacy projects require a good amount of interaction with the business just like greenfield ones. If all you do is refactoring, you're just burning money.