This post was written for the NCrunch blog. You can find the original here. When you first start writing unit tests, all is well and the few tests run in a matter of seconds. After having written hundreds or thousands of tests, running them might take…long. Too long. But when is long too long? How long should your unit tests take to run? And how can we reduce the time it takes, without removing or skipping tests? Why Do We

I’ve sung the praise of TDD/automated testing many times before, but recently encountered an angle I hadn’t considered yet: the importance of automated tests for onboarding. Automated tests have several benefits: if you’re practicing TDD, it generally drives your design in a good direction it provides a safety net for refactoring it can catch bugs it speeds up development it provides some documentation for your code But here’s another advantage: it helps new developers tremendously. In part, because of the

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

Note: I originally wrote this for SubMain. You can find the original here. In one of my previous posts, I wrote about the .NET build configuration system. I mentioned the app.config file, but didn’t really dive into it. So let’s take a closer look at this file now. When you create a (non-web) .NET Framework application in Visual Studio, an app.config file is added to your project. When you create a class library or a .NET Core project, such a file

Editorial note: I originally wrote this for the NDepend blog. You can find the original here. 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 let’s dive in. What

Editorial note: I originally wrote this post for ASPE. You can check out the original here, at their site. When developers use Git, they often use a combination of a graphical user interface and the command line. A GUI has a low barrier to entry, but many of us want to leverage the power that Git CLI. Once you’ve learned the basics of the Git command line, you have some powerful commands at your fingertips. And it only gets better

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