I’m a big fan of projects that deliver value in small, incremental steps. Unfortunately, some of the projects I worked did not turn out that way. After one of the not-so-great projects, I decided to do a personal retrospective. Instead of listing all the things that went wrong, however, I decided to write about what could have been. Read article
Articles
I’ve spent a lot of my time as a developer chasing, handling and catching all sorts of errors – be it logical or fencepost errors, disk and network failures or compiler errors and runtime exceptions. Read article
Writing an RFC is a great way to improve your designs and to make better decisions. Over the years, I’ve written dozens of RFCs and every one of them turned out to be invaluable. Unfortunately, writing an RFC always costs me a lot of energy. As a result, I write less RFCs than I probably should. Read article
I still remember that one time when my colleague and I worked on a difficult project together. After we had completed the most difficult part of the work, he came over to my desk to thank me. Read article
Conversations about software projects are packed with jargon. But if you’ve been in the industry for long enough, you may not notice it anymore. Just bring in someone from a different industry though, and they’ll be surprised by some of the words we are using. Read article
Quite recently, one of my dear colleagues told me that he had accepted a new job with a different company. I got really excited and asked him to tell me more. From his description, it sounded like the new job was going to be exactly what he had been looking for. Read article
To make your microservice architecture successful, you have to consider a lot more than the technical aspects. Unfortunately, one aspect in particular often gets overlooked: the relationships between teams. Read article
When you switch to a microservice architecture, you should expect a change in your team’s effectiveness. When done well, you might unlock the full potential of your team. When done badly, however, all progress might grind to a halt. Read article
When you switch to a microservice architecture, many aspects of your day-to-day experience will change. One of the things that will change is the way you run your software. Read article
Writing doesn’t come naturally to me. Well, that’s mostly true. Occasionally, a flash of inspiration helps me to finish an entire article in one go. But these moments are rare. Most of the time, writing is an excruciating process. Read article
Microservice architectures are terrible in many ways. Things that are straightforward in a monolith often turn into complicated issues. All of a sudden, you have to abandon some of your most powerful tools: transactions, consistent backups and automated refactoring. Read article
This article is a small intermission in our series about the socio-technical aspects of microservices. I realized that I hadn’t quite covered why you would choose a microservices architecture in the first place. This is what we’ll cover today. Read article
Today we will discuss one of the most important aspects of microservices: ownership. More specifically, we will explore why each microservice should have exactly one owner and why those owners should always be backed by teams. Read article
I’ve learned a lot about microservices in the past seven years. During that time, I helped to design, deploy and operate a handful of systems based on microservice architectures. Some of those systems turned into success stories. Others caused more trouble than they were worth. Read article
Like everything else in software development, microservices have trade offs. They can do much good, but they can also be harmful. How beneficial they are depends on the context they are used in. I’ve seen microservices work well for an organization if: Read article
At the beginning of my career, my mind was preoccupied with technical details. I believed that by learning all about the intricate details of computers, I could become an expert software developer. But even though my understanding of computers kept growing, many aspects of software development remained a mystery for me. Read article
I’ve heard people talk about Conway’s law many times throughout my career. However, I only recently understood the central insight that it is built upon.
Read articleI am no longer in fear for my father’s life. I’m so glad that he’s won his battle with Covid-19 induced pneumonia. It’s been a tough fight and the disease has certainly taken its toll: even climbing a small set of stairs has become an insurmountable problem for him. But he’s started his recovery and is getting stronger every day.
Read articleToday my father was diagnosed with pneumonia. He’s already been weakened by twelve days of recurring fever. Despite his best attempts to stay strong, he’s lost a lot of weight. When I learned that he has tested positive for Covid-19 last week, I was worried. Read article
When I decided to write about the basics of Domain-Driven Design, I thought I could capture the key concepts in two or three articles. In hindsight, I was a bit naive. Domain-Driven Design is a huge topic, so there’s plenty to learn about. Read article
Today I’m going to make good on my promise: we will finally apply the concepts of Domain-Driven Design to a piece of source code. I’ve developed a fictional case study that I hope to be both, simple enough to understand, but also realistic enough to be useful. Read article
There are many ways to design a system. Some are more fit for purpose than others. If your team spans different roles, your design should facilitate teamwork. In this article, we’ll learn about a technique to evaluate that particular aspect of your design.
Read articleDomain-Driven Design asks us to experiment with the words and concepts we use in our models. Each change must be consistently applied across all artifacts though. Otherwise, our systems will become tough to understand. Keeping our artifacts up to date is a lot of work, but there are ways to reduce the burden. Read article
Model refinement is an important part of Domain-Driven Design. Although this sounds easy at first, it turns out there is a tension between model refinement and ubiquitous language.
Read articleThe way we look at the world influences what we perceive. A different perspective often allows us to discover new details. Looking at something in just the right way can lead to powerful insights. Read article
In discussing the benefits of a shared mental model we always did so in the context of a team. But many organisations consist of more than one team. Can we take the ideas of Domain-Driven Design and apply them to an entire department or even the whole company? Read article
A shared mental model and a common language can make a team more productive. But what if your team lacks both? How can you help your team to start the journey towards a shared mental model? Read article
Last week we’ve learned how beneficial a shared mental model can be to a team, especially when that team is in the business of developing software. Unfortunately, I noticed that many teams don’t have a shared mental model. Read article
About eight years ago, I came across the concept of Domain-Driven Design (DDD) for the first time. Back then, I was still working in a tiny startup with only a handful of developers. And although I did learn about entities, aggregates and the like back then, I completely failed to understand that DDD really is about teamwork. Read article
I realized that one of my favorite work-related stories from last year is worth sharing on this blog, because there is such a powerful lesson in there. It’s a great example of how useful it can be if you take a step back and look at the larger picture. I’m quite sure that you’re going to enjoy it.
Read articleLet me tell you about one of my favorite techniques for helping teams to accomplish their desired outcomes: user stories. If you find your team being slowed down by an enormous backlog of tasks, user stories might be just your thing. Read article
The one thing that gets me out of bed in the morning is a chance to help those around me to accomplish great things. So when I found myself in a struggling remote team I couldn’t resist the opportunity to make improvements. This article outlines the principles that guided me along the way.
Read articleI think of pair programming as a powerful technique that I would never want to miss in my tool belt, no matter what the project is. But similar to any other skill it takes a good amount of practice to master it. Read article
From time to time I join a team, department or company that has not (yet) formed the sort of culture necessary for Agile software development to flourish. In situations like that I begin looking for opportunities to help my colleagues succeed. One thing I like to look at is how projects get started.
Read articleFor the majority of my career as a programmer I believed that I was way more productive when working solo. Had you been on my team back then, you would have found me almost exclusively wearing noise cancelling headphones, in a deep state of focus, trying to turn out lots of high quality code. Read article
Today I want to share with you an experience that has profoundly influenced the way I think about software development. It is a story about a bunch of programmers that came together, learned to collaborate and became a successful team. Read article
As we’ve established in the previous article, to do the best work of your life you want to be part of a great team. But what do you do if the team you’re currently on is not that great? Read article
This is a website about working together. We’ve got a whole bunch of topics to cover, spanning pretty much all aspects of software development. Occasionally, we’ll be venturing out into related topics such as change management, mentoring, and good old-fashioned trust. Read article