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
Most developers know you should never break the build. Most will also take care not to do so. And when it happens, they know it should be fixed as soon as possible. But why is that? Why is the build so important? And what arguments can we give to the more sloppy developers who don’t agree? Why Do We Have a Build? In it’s simplest form, the build picks up the latest commit to source control, and compiles the code.
Editorial note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. Most people that start programming learn to program in an imperative way. Shortly after, they will probably learn a declarative language too. Many developers go a long way without knowing the difference. Many will probably never know. And they could very well be great developers. But knowing the difference could change the way you write code for the better, so
Editorial note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. When I was attending night school to become a programmer, I learned several design patterns: singleton, repository, factory, builder, decorator, etc. Design patterns give us a proven solution to existing and recurring problems. What I didn’t learn was that a similar mechanism exists on a higher level: software architecture patterns. These are patterns for the overall layout of your
Editorial note: I originally wrote this post for the Submain blog. You can check out the original here, at their site. When you create a .NET application in Visual Studio, it contains two build configurations: Debug and Release. But what does this mean exactly? Most developers will tell you that you can transform your Web.config or App.config based on the selected build configuration. For example, when you select “Debug,” your database connection string might point to a database on your
I focus on helping teams and organizations reduce technical debt. This means a lot of work in legacy applications. But once technical debt has been reduced, it’s important to think about how we will avoid creating too much new technical debt in the future. Of course, there will always be technical debt, but we should try keeping it to a minimum. Today, I would like to write about company frameworks and how they often increase technical debt, while providing little
Editorial note: I originally wrote this post for the Submain blog. You can check out the original here, at their site. Documenting your code is important. It tells other developers what the code does, why it is constructed in a certain way, and how to use it. Good documentation saves them time when they are trying to perform a certain task that isn’t straightforward. It will probably also save you time because the human brain can only store so much information.
Editorial note: I originally wrote this post for the Submain blog. You can check out the original here, at their site. Put two developers together and they’re bound to have a discussion about coding style. No two developers write code in the exact same way. More often than not, one isn’t better than the other and it’s just a matter of taste. In a team or in a single project, it’s more important to be consistent than it is to choose the