---
title: "Building New Code Beside the Old Lets Teams Redesign Without Merge Conflicts"
description: "Answering Tim Ottinger on why redesigns stall, Mark Seemann says to build new code beside the old and migrate call site by call site."
author: "rews desk"
published: 2026-10-02T12:00:00Z
modified: 2026-10-03T08:39:28Z
url: https://rews.cc/a/building-new-code-beside-the-old-lets-teams-redesign-without-342ab3
language: en
tags: ["programming", "software", "architecture", "git", "feature-flag", "tech"]
publisher: "Rews (https://rews.cc)"
---

# Building New Code Beside the Old Lets Teams Redesign Without Merge Conflicts

*Answering Tim Ottinger on why redesigns stall, Mark Seemann says to build new code beside the old and migrate call site by call site.*

By rews desk · October 2, 2026 · https://rews.cc/a/building-new-code-beside-the-old-lets-teams-redesign-without-342ab3

## In brief

- Tim Ottinger argued merge conflicts and social blame keep teams from attempting large redesigns
- Mark Seemann published a response on Friday prescribing side-by-side implementation
- The method: add the new design as new files, push it early, then migrate call site by call site
- Seemann advises validating the design in a private local Git branch before sharing it
- He cites Feature Flag and Strangler Fig patterns from his book Code That Fits in Your Head

Two programmers, writing a day apart, have laid out why redesigns in shared code bases so rarely happen and what might make them safer. The Danish developer and author Mark Seemann published his answer on Friday: add the new design beside the old code, never in place of it.

Mr. Seemann was responding to Tim Ottinger’s post “Why redesign doesn’t happen (enough),” a five-minute read he recommended outright. Mr. Ottinger’s argument runs like this: sweeping changes touch files that colleagues are also editing, the resulting merge conflicts reflect poorly on the well-meaning programmer who attempted the improvement, and that risk teaches teams to leave bad design alone. He closed with a question. “What interventions would defang this fear and allow teams to move the design and architecture forward?”

Mr. Seemann’s intervention is the Strangler Fig pattern, applied at the level of code rather than systems. Write the new object model as fresh files that nobody else calls, then push them so the whole team shares them. Since no one else’s work touches those files, conflicts have almost nowhere to start.

Only later does the migration begin. Where the old, problematic code sits, replace it one location at a time with simple calls to the new API, at whatever granularity feels safe. Small batches, small diffs, small chances of colliding with a teammate’s work.

He concedes an obvious objection: a design nothing uses is a design that might not work, and early feedback matters. His remedy is to test the design quietly first, by doing some of the real replacements in a private Git branch kept on one’s own machine. If the evidence says the design holds, push the new API first and the migration commits later. If the code base has moved on in the meantime, he wrote, it can be easier to redo the migration from a newer snapshot than to resurrect the old branch.

Much of the approach comes from his book *Code That Fits in Your Head*, whose larger point he repeated: changing a code base is easy for a solo developer and a learnable skill on a team. The techniques he lists include feature flags, explicit versioning and keeping changes to automated tests separate from changes to the system under test.