Construction Zones: how to avoid developers getting in each other's way
Version control systems like git allow us to collaborate without getting in each other's way. There was a time when version control meant checking out files, much like checking out books in a library. When a dev checked out a file, you couldn't edit it until they returned it. These days, we have powerful tools for branching and merging. In theory, two developers could work on the same file in isolation and merge their results when done.
In practice, we try to avoid this as much as possible. We've learned that time spent on merging is time wasted. We prefer small teams, short-lived branches, and trunk-based development because they are much more efficient.
But sometimes, developers still get in each other's way. Sometimes, a codebase requires such a big overhaul that everyone on the team is impacted. I remember a team that agreed to replace their primitive-based identifiers with custom identifier classes. A Person
would no longer have an id
of the type int
but an instance of the class PersonId
. This would increase the readability of their code. So they made a Jira ticket.
Of course, the developer who picked up that ticket would constantly break other people's code. Since he was changing almost every function in the codebase and they were using trunk-based development, it was a guarantee that there would be a merge conflict whenever someone tried to check in another feature.
While such big, impactful changes are exceptional, they can wreak havoc on a team's productivity. I call these Construction Zones. Once a (part of a) building is a construction zone, you can't live in it. You have to be on the lookout for sharp edges and debris.
The symptoms of a construction zone are clear. A developer is making an awful lot of agreed-upon changes, and for a period of time, the codebase is rife with merge conflicts.
Typical examples of construction zones are:
Upgrading that old Java 8 application to modern standards. Every dependency will be touched, and some things will no longer run on the old JVM.
Moving from Javascript to Typescript. Massive changes to the codebase every time you pull git.
Breaking a microservice off a monolith. The code you're working on might all of a sudden be in a new repository.
It's an often frustrating mess where it feels like team members are actively sabotaging each other.
The bad news is big overhauls like this will impact your team's productivity. The good news is we can limit their impact by planning.
Construction zones should always be a team decision. If a developer starts doing these big overhauls without consulting his teammates, that's not a construction zone. That's a wrecking ball. That's a HR problem, not a technical one.
But, when teams agree on the construction zone, they can plan it. The problem isn't that we're renovating our kitchen. The problem is that we're trying to cook dinner at the same time. Multitasking in a construction zone is a massive waste of developer productivity.
The key here is to apply Iterative Buffer Planning. While "Upgrade to Java 21" sounds very technical, it is an acceptable Focus Block. The team will be laser-focused on solving that problem for a given timebox.
Typically, not everyone can contribute to the upgrade. More often than not, only one or two developers will be involved.
But that doesn't mean the rest of the team can't address the problem. It's the right moment to write additional tests to prove that the system still behaves as expected after the upgrade. This will raise the team's confidence in the upgrade and catch errors early. Now that we're taking a step back to look at the big picture, it might also be the time to update the system's documentation.
While this might instinctively feel wasteful to some, remember how wildly inefficient multitasking in a construction zone is. Building features in an unstable codebase is way more inefficient.
Try to spot construction zones before breaking ground and plan them as Focus Blocks.
Whatever you do, resist the urge to multitask in a construction zone.