Blog

Microservices are very popular right now, because supposedly, they allow you to develop, deploy and maintain them separately. It allows you to keep a clean architecture and avoid coupling. A contrasting opinion is that a monolith can do these as well, and remains simpler to deploy and support. But it should be a well-factored monolith. But not many people really tell you what that looks like. Let's do the exercise of thinking what a well-factored monolith would look like. Note: if you're unfamiliar with these architectural patterns and want to learn more, I have a LinkedIn Learning…

Companies that handle physical goods usually want to keep their inventory to a minimum. As software developers, we should do the same. Physical Inventory Physical inventory is all the physical goods a company owns. Think buildings, computers, furniture, but also items they will sell, either directly or assembled. Product parts for example. Or food items that need to be shipped to shops. All these items amount to a certain value for the company. But there are also costs. Costs when buying them, but also costs maintaining and storing them. Costs when things perish (like food) or deteriorate…

The monolith is an architectural pattern where the software application consists of a single executable that is deployed as a whole. It can be difficult to work with when it is being maintained by a single team. But matters worsen if it is managed by multiple teams. Here's why. How Monoliths Grow When a company starts a software product, it usually is a single application. Especially when things need to move fast and there isn't a lot of time for architectural concerns. That doesn't have to be a problem. The application is small and can be supported…

Many legacy applications are difficult to run locally, on the developer's machine. I always recommend teams make it possible to run their code locally. After automated tests, it's a powerful enabler for developers to improve the code quality. Here's why. Working Offline In the past, internet connections weren't always reliable or, when commuting, not available at all. Which was why being able to run your application offline was important. This reason has become a bit outdated, with the increased reliability of networks, mobile phone hotspots and free wifi in so many locations. However, it's still very frustrating…

Should startups disregard code quality so that they can test their product-market fit as quickly as possible? Or should they write high quality code from the get-go? I used to think the former, but an interesting conversation with Kurt Biesemans made me change my mind. Although there is still room for exceptions, depending on the context. Let's explore this more deeply. Finding Product-market Fit The first thought that comes to mind when talking about technical debt and startups is that they shouldn't bother about it too much. They should focus on product-market fit, i.e. get a minimal…

Here's a great story to get you thinking about how legacy code can build up (I can't find who originally told it). At Christmas, a father prepares a Christmas ham. He cuts of both ends and puts it in the baking pan. His child asks why he cut off the two ends, wasting the meat. The father says it's how he learned it from this mother. Later, he wonders about his child's question and calls his mother to ask the same question. She can't answer however, and tells him to call his grandmother, whom she learned it…

Technical debt and legacy code are closely related but not exactly the same. Legacy code is a derogatory term to indicate old code that is no longer well-maintained. Technical debt, on the other hand, is debt accumulated in order to release software. It can be more than just your code. Let's take a look at the different kinds of technical debt that we can accumulate. Code Debt Code debt is the most obvious form of technical debt. It's what matches best with the term "legacy code". It's code that still serves a purpose but developers don't like…

I've written about avoiding technical debt before, and probably will do so more in the future. There's just so many ways to avoid it or at least limit its consequences. At the very least, you should be writing automated tests. But let's look at another way to avoid technical debt: no writing the code at all. Am I joking? Not at all! Technical debt inevitably starts accumulating early on in a project. Either corners need to be cut, or situations change. This leads to different kinds of technical debt, but it's inevitable that your software will end…

I've written about the test pyramid before. It provides a guideline on the type of tests you need and how many. But recently, I got in a conversation on what the test pyramid actually means. Is it about code coverage? Or is it purely about the number of tests? A Brief Recap The test pyramid gives us guidance on how our test suite should look like. We should have less tests that use many components and more that test only one or two components: The reason we follow this guidline is that the tests higher up the…

I was recently on the Tiny DevOps podcast and mentioned the Disaster-Release Ratio metric. And although I've written about it before, but the podcast made me decide I should dedicate a separate article to it. But before we continue, I came up with this metric while at work with a client, but someone else might already have thought of it before me and just named it differently. If so, feel free to point this out to me. What is a Disaster? The Disaster-Release Ratio is a simple metric that focusses on "disasters." These are bugs that make…