Forem: Markus Decke

From branches to trunk (a journey)

Markus Decke — Tue, 20 Jan 2026 22:01:29 +0000

Preface

In environments where people are used to using some sort of Gitflow variant, the norm is having main, develop, and long-lived feature branches. There are often not enough good automated tests and use-case coverage to deliver with confidence, so branch isolation and friction-creating processes are used to ensure some quality. At least having a DEV stage where builds get deployed after they successfully created a container image is the usual case. This doesn't mean there is an automated release process or additional stage for testing prior to a release, also known as merging into main.

This means the DEV stage can be a moving target for testers, if the first stable stage is the INT stage, where Releases (2 weeks of work) are deployed for delivery towards production. Here, the testing works on a fixed set of features and stable servers, without the surprises of new features popping up when something is merged.

Since Releases happen every 2 weeks, people can be eager to merge instead of waiting another 2 weeks when they are nearly but not yet done, especially clients and project managers, who can get restless. So we get bugs that get caught on INT, and then we need to create hotfixes and test again. If there were merges in between, the fix needs to be cherry-picked, which means the hotfixed Release isn't the same set of features as the current develop branch.

Current setup

Delivery Stages

DEV (develop) - develop branch gets deployed after merge (build takes hours)
INT (Integration) - main branch gets deployed every 2 weeks after release build
...
PROD (Production) - gets deployed 2 weeks after INT

This means the state on INT is not the same; if errors occur, we need to have a hotfix, and this means more friction.
The often-used solution is to have a merge-freeze on develop until Release, to ensure everything on DEV gets tested. So main in the end is the Release branch and has no other function. You could also tag a commit in develop and release that without going through the motions of PRs from develop to main, which is done by hand; this is cumbersome and creates a lot of friction and therefore waste.

A new idea is to have a TST (testing) stage, so that a fixed set can be tested and released.

New setup

Delivery Stages

DEV (develop) - develop branch gets deployed after merge (build still needs hours)
TST (testing) - a fixed state of develop can be tested and then merged into main
INT (Integration) - main branch gets deployed every 2 weeks after release build
...
PROD (Production) - gets deployed 2 weeks after INT

Question: How do we get the tested commits into main after new merges into develop?
Answer: More branches!

Branches everywhere?

So now we have develop and main as branches with the new setup, we need to branch from develop with a certain set of commits to merge into main.
One way could be to create a new branch from develop and merge into main, so that we still have PRs and manual actions and waste.
Instead, we could tag a commit and merge the tag into main, which we can do by hand or we can automate.

Moving towards trunk!

Question: If we do this, do we really need main anymore?
Answer: I think not.

Question: Could we instead work and release only develop?
Answer: Yes, let's call it trunk instead of develop.

We could tag a commit in develop and release the tagged commits, that way we don't need an extra branch and manual motions to get the commits into it. Less manual work and friction, less waste.
Depending on your view, we could call it successfully moving towards trunk-based development.

What do you think? Let me know in the comments.

For me next stop in the journey is moving towards continuous delivery :)

Be explicit about your code base style and software design

Markus Decke — Tue, 16 Jan 2024 09:59:43 +0000

Imagine you start at a new workplace or a project you haven't had previously worked on.
Checking out a code base can be tedious and it can be unclear what to expect from it.

Some questions come to mind:

Where can I find the important things?
Why isn't this framework replaced by something modern?
Do I need to install something to make it run?
... there can be many more questions arising.

It is good to understand early on what practices are followed and what design is aimed for. There is even more one would like to know or what one can expect from that code base.

As a project maintainer you can help with that. Write down what goals you are aiming for and which practices support you to reach this goal.

Write it down. Make intentions clear. Be explicit.

During my journey in software development, I once worked in a team where we did that. It helped a lot. We got less questions on why we chose what and if we considered that.

README example:

We are using <formatting style XYZ> to have a consistent format throughout the code base and use this <XYZ formatting tool>.

We make use of linting to be able to mitigate common problems and use <linter XYZ>.

We use unit tests for testing business rules.

We use integration tests to check if the pieces fit together.

We organise our code following hexagonal architecture, to separate our domain from frameworks and other details.

We use domain objects instead of generic ones, e.g. Username object instead of plain String,

...

We stated the software design goals and architecture even before we wrote any code, so that we knew immediately what we are looking for when we start the work on the code. It supported us to have less things in our heads while we implemented.

A different way would be to write these things down as architecture decision records (ADR) inside the repository itself.

The decisions don't need to be architecture related, they can be any decision in the context of the code base's repository. You can document dependency choices, software designs, and tech debt; don't forget to include pay back plans.

With these, anyone who checks out your code can have a faster introduction to it, and understands from the start what things are considered important and intentionally not considered.

This also helps to have better code reviews, since expected things are explicitly stated already; like code style, linting, design patterns, and architecture. This should speed things up and have less comments about these items that got already decided.

You can focus on the details that are important.

To make the implicit explicit helps to communicate the context and why things are as they are.
Your future self and colleague will be thankful. :)

Behaviors for a better pair programming experience

Markus Decke — Tue, 03 May 2022 21:01:36 +0000

I want to share my experiences and observations of pair programming, that I have made pair coding at work and facilitating coding workshops such as coding dojos and coderetreats the past years.

I think it is more than just two people sitting in front of a computer and doing the work of one.

First I would like to introduce you to XP, you might be familiar with the abbreviation XP as in experience, but it also stands for eXtreme Programming (XP) and it originates from the 1990s. Kent Beck and his colleagues described pair programming in the book “Extreme programming explained”. At the time these ideas were considered extreme and pushing collaborative programming to a different level. This was in the 1990s, and now with agile method having been adopted more and more since the 2000s one might think pair programming is more widespread. A lot of XP things have been adopted and you may be familiar with concepts of collective code ownership, continuous integration, code testing, talking to the customer, but these human-centered practices have still as far as I can tell not been so widely adopted.

In the past when computer time was precious people were working together to get things done and correcting before running a program on a computer and to be sure to use its computer time effectively. In a way pairing was the usual mode of working, you can take a look at “Psychology of computer programming” by Gerald Weinberg from the 1970s, where he describes a lot of practices and collaboration patterns people used before one computer per person became the norm.

So let's not wait another 20+ years!
Let's and dive into the topic now.

In his book Kent Beck explicitly described pair programming as a practice, where two people equally share the responsibility for doing the work and getting it done.

How do they do that when there is only one keyboard?

In pair programming two people occupy distinct roles, the one is the driver and the other one is the navigator. In the sense of going on a road trip together, where the one is paying attention to immediate things and the other one checks what will come ahead. They arrive together and the fashion in how they do that, is determined by how they work and interact together.

As a driver, you will have the keyboard and your job is to write the code. As a navigator, your job is to support the driver while observing what is being written and keeping an eye on the overall context it is in. Keeping this in mind both need to communicate about what they are writing or what they deem as being important as the next step. As a driver, you keep the navigator updated about what you want to write next, this way the navigator can more easily support you. As a navigator, you keep the driver on track so that you both don't end up in a ditch. It is necessary to give feedback on the code, or quickly read some documentation so that the task gets done. Switching roles every now and then can help you to keep focus and also change the way you think about the task ahead.

Even if you try to keep all these things in mind it doesn't guarantee that you will have a great pair programming experience.

Some things can diminish your efforts in doing pair programming productively and some behaviors can enhance your and your pair's experience.

Collaborate!

Read the task and discuss what needs to be done. Plan it together and agree on what and how to do it. This can save a lot of stress and time.

Don't dominate!

Don't try to show off or cling to the keyboard all the time, this will disengage your pair partner, nobody likes to observe somebody programming alone. Instead, slow down and keep your pair partner engaged and informed about what happens next. This way the navigator can support you better and can give feedback while being in the loop with you.

As a navigator don't tell the driver constantly what to do, this isn't dictation, and the other one is not your scribe. Instead, communicate about what you would like to do next or differently and maybe switch roles.

Be constructive!

Don't blame your pair partner or the code you end up working with, it is not productive and probably it is your own code you are blaming. Give directions or ideas on how to improve things and demonstrate how to do it better. That way you and your pair partner can learn something together and also have a sense of achievement in having left the place better than you found it.

Turn off notifications!

In most cases it is not beneficial to work if there are too many distractions or when one is preoccupied with something else. Everything that is not focused on the task ahead should be avoided such as, reading emails and chat messages that can be done later. Turn off notifications, also on your phone.

Celebrate!

If you get a test green or some things finally fall into place, celebrate and congratulate each other for this achievement. Every little step is part of the whole and it is worth acknowledging its positive impact.

Take breaks!

There is always some things that cannot wait, so take a break or schedule breaks before hand and make them explicit and long enough so that you can use them to defocus from work. When you come back to the task, you'll have a fresh view and relaxed mind and will be able to focus more effectively than if you had paired and sat there for hours.
When you find yourself not being able to concentrate, both of you take a break and come back together and continue working.

Switch roles regularly!

Breaks are a great way to initiate a switch in roles, there are many ways to do it, e.g. writing a new failing test and the other needs to implement it to make it green. It supports in getting a different perspective to the task and to the work when you switch the roles and have to focus on different things.

With these behaviors in mind I am certain you will get the benefits you are looking for.

Faster feedback and getting unstuck faster

You have your colleague at your side to check the code and to support you when you are stuck and vice versa. You can measure cycle time of tickets that you did while pairing, it probably doesn't need a code review with the PR, since two people have worked on it and checked if the design is up to the teams standard.

Fewer defects.

Bugs found in production would be a thing that can decrease since 2 people thought about edge cases and other problems while having the context of the work item in mind. A code review probably won't catch these since the reviewer does not have the full context in mind. It would need a deeper code review that goes beyond "lgtm" and "+1".

Less knowledge and skill silos

You are actively working together and sharing how you would like to solve a problem. Talking about solutions and the domain will certainly help you and your pair partner to not be the only one who knows what was done and why and how it got in the new state.

Staying focused

Two people are usually less likely to be interrupted, especially in an office setting. In a remote setting you can benefit from having turned off notifications while pairing.

Pair programming is not a one size fits all practice since everyone is different. To get a better experience each time discuss what was good and what can be improved for the next time.

Happy pair programming!

Three modes for an enhanced pair programming experience

Markus Decke — Tue, 20 Jul 2021 07:43:54 +0000

You may have heard about pair programming and have a rough idea of what it is about. If not, “No problem” – we are going to look into it in this post and there is another nice blog post written in German regarding best practices of pairing.

One aspect of pair programming is that two people sit in front of one computer and work. This is what pair programming looks like from the outside, but there is more to it than just that. While two people sit in front of one computer, only one person is able to operate it; without any bad intentions, it is possible that this person is showing the other one “How things are done”, while the other person is passively observing. The observer’s mind may wander somewhere else or she/he may start checking emails and social media instead of working on the task. This observed pattern is called watch the master and should be avoided since only one person is actively engaged. It is very unfortunate if only one person is engaged and the other one feels they cannot contribute.

You may have started out on the wrong foot with pair programming or you want to try it (again?).

Let’s start over with a quick recap of what it is. Pair programming has a few formalities you should take into account before starting. There are two roles: the driver and the navigator. While the driver has the keyboard and types in what is currently needed to be done, the navigator helps in looking ahead for how that code will fit into the codebase. There may be things to restructure, refactor or reimplement so that the work item fits into the project better. Both people focus on their roles and should communicate all the time about what is happening or about what will need to be done. Communication is the key in pair programming.

Now that we aware of the roles and their responsibilities, when do we switch? You can switch whenever you feel like, this needs to be decided together. Let’s look at three modes of pair programming that can help you switch and work more collaboratively while focusing on the task at hand and less on the mechanics of pair programming.

Mode 1: Ping Pong

The Ping Pong Mode is a way for both of you to switch the keyboard regularly. It goes like this: The starter is writing a failing test and hands over the keyboard. Then the other one implements what is needed so that the test no longer fails and then writes a new failing test and hands over the keyboard to the person who started. In that way the keyboard is hopping from one person to the other like a ball in a game of ping pong. While the tests are not failing, you are able to refactor the code both of you have written. This continuously improves your code and mitigates your codebase from deteriorating.

This mode fits nicely into the workflow of TDD.

While Ping Pong is focused on switching the keyboard task wise, you can also try out to switching by using time boxes.

Mode 2: Pomodoro

Pomodoro is a time-box technique for tracking the time spent solely focused on one work item. You can use it as a Mode for pair programming. The base line of Pomodoro is: set a timer to 25 minutes and start working on the task you want to work on. While the timer is running, you are not allowed to work or do anything else, than the task you have committed yourself to work on for this time box. Where is the switching in this mode? You can choose to switch after each iteration. Each iteration has a following 5-minute break. This can give you enough time to switch the keyboard or computer. You could invite your colleague to your desk for the next iteration of collaborative work.

Mode 3: Let's discuss!

The next approach is not focused on task or a time-based switching of roles as the other two modes presented. It is heavily influenced by mob programming, first you discuss what you want to do, and if you come to a conclusion, you do it. No code should be written that has not been discussed and decided on by both members of the pair. This style creates room for discussion, assists in making compromises and can create a better shared understanding of the task and codebase you are both working on together.

It's time to experiment and reflect!

Take your time experimenting and try to find what works best for you and your pair member. To enhance the learning experience, reflect on each session. Tell what was good and what could be improved, write action items down and take them into account for the next session. This alone can already improve your current mode of pair programming.

Experiment on modes, mix and match modes, and try out new things to find what matches the needs of both members of the pair.

Have a happy and productive day of coding!

Photo by Christina Morillo from Pexels