This is a first step in my series on fixing a real-world legacy application. It focusses on updating Bootstrap, but the broader issue here is that you should update the components you are using. The application was using Bootstrap 3. Updating to version 4 was fairly easy. I first uninstalled the NuGet packages bootstrap.less, Twitter.Bootstrap and respond.js. I chose to use the Bootstrap CDN so all I need to do was: remove the Bundle in  my BundleConfig.cs file change the

For the FIFA World Championship of 2014, my friends and I wanted a website where we could “bet” on the games. Not for money, just for fun. In the past, we used an Excel file with some fancy formula’s. But then came the idea to write a web application. As the only developer, I accepted the challenge. It was done in a rush, with the technology of the time. Four years later, this gives me an excellent exercise for refactoring.

This post was written for the NCrunch blog. You can find the original here. Test-driven development is a technique to drive the development of your project. TDD enables you to verify your code, it provides confidence for refactoring, and it enables a cleaner architecture. But what if you already have an existing codebase that wasn’t developed with TDD? How can you get started with TDD in such a (legacy) project? There are several approaches to this, so let’s dive in! The Situation

At one of my previous customers, a developer once asked me what I do when a client chooses the quick & dirty solution after being confronted with different options. The story behind it was that some members of the team were frustrated with the technical choices their immediate managers were making. When asked for an analysis of a feature, they would propose a solution that involved clean code, modern standards, tests, etc. In short, the ideal solution. But they would

Note: I originally wrote this for SubMain. You can read the original here. Depending on your age and experience as a .NET developer, you might or might not be familiar with the technology known as Windows Forms. Windows Forms, or WinForms, was introduced together with .NET 1.0 in 2002. It was the first desktop UI technology for .NET. We’re now 16 (!) years later, and WinForms runs on the latest version of the .NET Framework (currently 4.7.2) and .NET Core

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.

A while ago, I had to explain, not for the first time in my career, why using interfaces, having loosely-coupled code, and writing tests (first) is a good idea. Time and again, I find developers, teams and companies resisting certain ideas that have been around for years or even decades. One of the reasons often stated, is novelty. An idea, principle or technology is refused because it is new and who knows what the next thing will be. Better to