Category: Tackling Legacy Code

This is the third and final part in my short series on tackling legacy code. Previously, I wrote about general coding techniques, and about the organizational and operational requirements. I would like to close with some final thoughts. Technology isn’t the problem We developers can’t help but get enthusiastic about new technologies: languages, frameworks, libraries, techniques, etc. But more often than not, the problem with a legacy project is not the chosen technology or its age. Rather, it’s the way

In my previous post, I gave some insights into how you can start turning the legacy ship around. In the end, I talked about preconditions that should be fulfilled before you start. I’ll dive into those now. The organizational First and foremost, the organization must agree that tackling the legacy code is something they want to do. “The organization” can be defined on several levels: from the team to upper management. But the more support you have upwards, the better.

Legacy code is usually the code nobody likes to touch. It’s often complex, violates all kinds of best practices, has little or no tests, etc. Yet I find it very rewarding to work in legacy code. It takes a while, but when you start to tame that beast and understand its intricacies, it can actually be fun! But how do you start changing a legacy project, putting in modern standards, and making it maintainable? This article will explain some techniques