Triple D : Design, Develop, Deploy

My first year at Triple D

A report of my first year at Triple D. How I discovered Triple D, why I wanted to join them, how I applied for a job and what we have done together since.

Vocabulary and Validation

A discussion on where and how to handle your validation of incoming data requests. Using domain primitives as core concepts and the application API as a bouncer.

Socrates BE 2022 Un-conference

A short report on the Belgian SoCraTes unconference that took place on 7-10 july 2022 in La Roche en Ardenne, Belgium

Six tips for successful ensemble programming

Ensemble (or mob) programming is a technique used by XP developers to improve a teams productivity and knowledge by working closely together. This post provides a few tips that we learned after doing ensemble programming for about 6 months.

Working with different environments

Having to work with different environments configs on your pc can be a hassle and dangerous. Let's explore an option that will improve your experience with it.

Communication is a Skill

Developing software, solving technical issues is hard. But so is communication efficiently and productively. Having productive discussions isn’t something that happens automatically. And they play a big role in the way how the software will be designed. Conway's law taught us the correlation between software design and people interaction. So we must recognize communication as a skill that we need to master. Turns out there are quite a few things to be learned from Mob Programming.

The importance of the dependency inversion principle

The dependency inversion principle (DIP) is at the heart of a lot of software design patterns, technologies and architectures. This article will try to connect those dots, and hopefully provide some additional insight into this important principle.

Event Storming a restaurant

Most people that use event storming use it for gathering the "Big Picture". But it can also be used for modelling out solutions to concrete problems. This blog post, I will try to demonstrate the power and usefulness of Event Storming for modelling out solutions. By using some simple building blocks, event storming allows us to model out complex systems rapidly. Without the need for very strict standardization.

The bully

In my series on heroics within software development teams, there is a type of 'hero' that I classify as the hero-bully. This is not the simple, ordinary bully, which may come to mind, who rules by force of intimidation. A hero-bully is someone placed on a pedestal by one group and who use the power from their received status to bully those around them that do not follow suit. This can even be completely unintentional!

The local hero

Throughout these posts of mine on heroic behavior, my main metaphor has been the wild west. One of the well-known archetypes there is the famous hero gunslinger. In this post, I'll address the software equivalent of this.

The posse

In software development it is possible that a posse forms inside or across teams when people start placing their loyalty to one another above their loyalty to the customer/employer

The lone ranger

In this post I will discuss my Lone Ranger pattern, a type of human behavior of software engineers, and the impact I think it has on its surroundings. Now the lone ranger is obviously someone who mostly operates alone. Lone rangers get the job done by themselves and are counted upon to save the day. Alas, the day needs constant saving.

The Young Buck

In this post, I'll elaborate on what I identify as the Young Buck pattern. With my Wild West metaphor in mind, with the Young Buck I refer to the image of the young gunslingers that are just leaving home, stepping out into the big world. Usually, they are still full of high ideals and have a simplistic sense of justice. Unfortunately, their lack of real-world experience sometimes lets them get played for a fool.


There are heroes in software development teams. They are software developers that are often well respected by their peers and well known by management. They can be held up as an example for others. Shining example to all. But there are downsides...

A construction tale

In the software industry, the metaphor that is probably used the most for explaining things is the construction of buildings. A lot of our terminology relates to it. Building, architect, architecture, design, engineer. Unfortunately it is all too often that this metaphor falls short and doesn't really address the problem sufficiently.

Connecting legacy to kubernetes

In this blog post I'll demonstrate how to make applications that are external to a Kubernetes cluster available to the applications that are managed by K8s. This is useful for when we have started using Kubernetes to deploy and manage some your applications but not everything is managed at once.

The MVC-architecture

A discussion about MVC, the model from MVC and the MVC - architecture.

Model anti-patterns

About model patterns and anti-patterns

What is domain driven design?

Tackling complexity in the heart of software. But what is DDD exactly?

Levels Of Abstraction

Writing code is all about abstractions, they help us grasp the complexity of the code by hiding low level details from high level concepts. The key to readable code lies in grouping the right level of abstraction in the same unit of code.

The anemic domain model

The anemic domain model pattern, with OO languages, is one of the most encountered "patterns". Yet it is considered an anti-pattern by many, despite it being so prevalent. What is it exactly? What are the arguments pro and con? How does it look in code? And what is my opinion on it?

The effects of TDD

What are the effects of TDD?