Shaping architecture together means making far-reaching software decisions deliberately as a team instead of leaving them to individual architects. Three experiments help: a long-term view of the product for orientation, Double Pairs to compare two solution alternatives in code, and mob programming for shared implementation and knowledge transfer.
Key Takeaways
- Architecture decisions are hard to reverse, so involving the whole team in making them directly improves the quality of the solution.
- Double Pairs means that two pairs each build a spike in parallel, so architecture alternatives can be compared against measurable criteria instead of being argued over in theory.
- Mob programming spreads architectural knowledge across the whole team, because everyone sees the code live, asks questions and clears up misunderstandings before they settle into production code.
- Architects who type along in mob sessions instead of only commenting in reviews get direct feedback on whether their design decisions are understandable and workable in code.
- New ways of working are easier to introduce when they are labeled as time-boxed experiments, because the word “experiment” noticeably lowers resistance in the team.
Architecture Decisions Are Expensive to Revise, So a Shared Foundation Pays Off
Architecture decisions carry special weight: they have far-reaching consequences and can’t simply be taken back later. That is what sets them apart from any ordinary code change.
If testing shows that load and performance don’t hold up, the suspicion quickly falls on the usual suspect: the architecture. At that point, fixing it is a major effort. The pain has to get bad enough before anyone is willing to spend money on the necessary change.
Then there is the problem of proof. From the outside, it is often impossible to say for sure what the cause is. You would first have to show that the investment will actually make things better before anyone approves it.
That is why Maximilian Aulinger and Melanie Brunnbauer start earlier. Their conviction from working with software development teams: close collaboration in which everyone is heard, including the introverts, leads to a better technical and business solution. Architecture decisions need the broadest possible foundation before they are made.
Double Pairs: Build Two Solutions in Parallel Instead of Debating Forever
Double Pairs is an experiment for exactly the moment when a team is torn between two solution alternatives and both sides present plausible hypotheses.
Instead of continuing the debate, two pairs each build a spike in parallel. Hence the name: two pairs, two approaches. Both work toward measurable criteria, such as hard performance targets that have to be met for the quality end users experience.
The result is something tangible: two comparable spikes, or at least two working states that let you judge against the criteria which approach fits better.
The setup doesn’t have to be rigid. Two pairs are the usual starting point, but it can also be two groups of three. Close collaboration with a lively exchange usually works better with two people than in larger groups, because it takes a lot of trust. More than two approaches are rarely needed, since a third or fourth has often been ruled out during the discussion already.
When Is the Double Effort Worth It?
Double Pairs costs twice the development time, so the team should agree beforehand when to stop the experiment. There are two ways to do that.
With a solid, measurable criterion, you develop until you can test, and then you stop. Without a hard criterion, a timebox helps: invest one day, run A against B and check the next morning how far both approaches have come.
It doesn’t always have to be two completely new solutions either. A useful variant: the team knows one approach well, and the other is technologically unfamiliar. Then it only builds a spike for the unfamiliar one, to get a feel for it, and compares it with the known approach.
There are no universal criteria. What helps is stepping back to ask what the solution is supposed to achieve. An organization or product owner who can clearly answer what an extension is for can derive measurable criteria from there.
Architecture Decisions Often Hide in the Code
Many architecture decisions aren’t made consciously at all. They take shape while coding. That makes them hard to pin down and expensive after the fact.
Typical questions that only show up hands-on in code concern the integration of external APIs: blocking or non-blocking, synchronous or asynchronous, and how that feels in the user interface. Cross-cutting concerns such as adding logging can be compared the same way, because the result is tangible and answers whether it would be viable in production.
A concrete example: a team was asked to add a digital signature to a running business process. The process itself belonged to another team; this team was only responsible for the signature component. There were two options: redirect the customer to a separate page, or build an integrated, reusable web component.
The second option was new and uncertain. Would the integration work? How much effort would it take? Would it deliver on the promise of reusability? The team took a day and a half to two days to try it out as a mock instead of debating it upfront.
A Decision Needs a Deliberate Decision Rule, or It Turns into a Lingering Conflict
If neither solution feels clearly better when the deadline comes, the team needs a rule agreed in advance on how to decide. Otherwise a half-baked solution stays in place, and part of the team doesn’t get behind it.
One team the two supported treated it as a sporting contest: if both approaches are level, the pair with the faster, reliable result wins. That saves further deliberation but requires trust and people who are willing to step back if needed.
Full consensus doesn’t have to be the goal. “Good enough for us” is often the more helpful standard. What matters is making the decision deliberately, whether by coin toss, best of five or a clear agreement. Otherwise a lingering conflict develops, because team members who were overruled don’t feel taken seriously.
If the criteria come out very close, that is an insight too. Then it may be right not to start the experiment at all, because the double investment isn’t worth it.
Before: A Clear Purpose Beyond the Next Sprint
Before two solutions get built, a clear goal helps. Teams that work iteratively usually only plan the next few sprints and lose the medium-term view.
Daily work is often stuck deep in day-to-day operations: what’s coming tomorrow, in two weeks, in four. Beyond that, it’s often living hand to mouth.
The remedy is a short, regular session with a fixed timebox. One hour is enough to step back and ask where the software product should be in six months. Deliberately not down to the last detail, but as an overview that sets the perspective for the decisions ahead.
After: Mob Programming Gets the Decision into People’s Heads
Every architecture decision is only as good as its implementation. If it doesn’t come to life in the code, it is worthless. And the implementation is usually only as good as the understanding of the people writing the code.
This is where mob programming comes in. When two people have worked out a spike through Double Pairs, the other two don’t know the implementation yet. The knowledge transfer happens in the mob, because everyone works on the same code together.
Working remotely has a practical advantage over the classic room with one screen. Everyone sits at their own computer and sees directly what is happening. The driver does the typing and comments as little as possible, and the others do the explaining. That creates a lively exchange, from “there’s a semicolon missing” to “that’s not how the structure was meant.”
Rotating regularly, about every ten minutes, keeps everyone engaged. During implementation, the questions come up that you would otherwise ask yourself alone while coding. In the mob, people sitting next to you have the answers, sometimes drop a snippet into the chat, and the team moves faster than with reviews after the fact.
“Implementations are usually only as good as the understanding of the people writing the code. That’s why it matters to communicate an architecture decision clearly and show what it looks like in reality.”
(Melanie Brunnbauer)
Architectural Knowledge Belongs in the Team, Not in a Few Heads
In many companies, architectural knowledge sits with two or three people who have been around for years and hand out their “that won’t work” in one-on-one reviews. Nobody learns anything from that, and the knowledge stays stuck with those architects.
The most effective lever: bring these people into the mob, as long as they are willing to code along. They think along, ask questions, give input and sometimes type themselves. Instead of just “not like that,” they deliver a tangible “this is how it’s meant to work.”
The effect goes both ways. Architects find out whether their high-level concept is understandable and whether they need to change how they communicate, and in extreme cases that the concept doesn’t fit the problem. That last insight is costly in the mob, but it is better to reach it a little earlier.
How Teams Involve Testers in These Experiments
In these formats, testers aren’t a downstream checkpoint. They are often the best source of the measurable criteria that decide whether a solution is better or worse. That is exactly why they belong in early, already in refinement, where they say what they would look at later.
There are also mob testing sessions. The team meets in a similar setup and sets a focus: are all screens consistent? Or shall we try to break the application as thoroughly as we can today?
One question is worth settling upfront, and it often gets skipped: what is the testing supposed to achieve? Fast feedback for development and a compliance check in a regulated environment are two very different goals. Putting that question openly on the table moves the team forward. In a mob session, people with a strong eye for quality criteria also make very good navigators.
How to Start a First Experiment, Even Without a Mandate
You don’t need approval from the project manager or the coach to get started. Find a colleague who is open to it and try one thing on a small scale, with two or three people.
Teams working in an agile way have a natural place to make the result visible: the retrospective. “Last sprint we tried this, and we liked it” triggers change from the bottom up, without anyone having to push it through from the top.
The wording makes the difference. “This is how we do it now” creates resistance. “Let’s try this as an experiment and evaluate in 90 minutes or two weeks whether it helped us” lowers the barrier considerably. A clearly labeled experiment commits you to nothing.
Leading by example beats persuading. When two people simply use a method and a third person standing next to them notices that it works, that has a pull no theoretical discussion can match.
Collaboration Can Be Shaped, Just Like the Software
The real takeaway from these experiments: it’s not only the software that can be shaped, but also how the team works together. Both can be designed deliberately.
There is no silver bullet. What works for one team fails for the next, where something else works instead. Different requirements call for different forms of collaboration to bring out good solutions.
That includes seeing differences as a strength rather than a disruption. The tester who asks awkward questions isn’t slowing things down. In the right place, that tester is exactly the person you want to bring in. Especially after long stretches of working remotely and in isolation, it is worth rediscovering each person’s strengths by working together.
Frequently Asked Questions
Why is it nearly impossible to correct a wrong architectural decision later on?
Because it has far-reaching consequences and can’t simply be reversed. If testing reveals that load and performance aren’t up to par, suspicion quickly falls on the architecture, and correcting it becomes a Herculean task. The pressure has to be great enough before anyone will approve funding. On top of that, there’s the problem of proving the case: You have to demonstrate in advance that the investment will actually lead to improvements.
How many alternative solutions should a team develop in parallel?
Two are usually enough. Two teams of two is the usual starting point, though two teams of three are also possible. Close collaboration with lively exchange usually works better in pairs because it requires a high degree of trust. A third or fourth approach is rarely necessary because it has often already been rejected during the discussion.
Which architectural issues only become apparent during programming?
Above all, the integration of external APIs: blocking or non-blocking, synchronous or asynchronous, and how that feels in the user interface. Cross-cutting concerns, such as integrating logging, also only become tangible in the code. A team tasked with implementing digital signatures tested an unfamiliar variant of a reusable web component as a mock in one and a half to two days.
What should you do if, in the end, both approaches perform equally well?
In that case, a previously agreed-upon decision rule applies. One team we worked with, in the event of a tie, went with the pair with the faster, more robust result. A coin toss or a “best of five” are equally valid, as long as the decision is made deliberately. A “this is good enough for us” often helps more than full consensus. Without a rule, a half-baked solution remains in place, and a latent turf war ensues.
How does a solution developed in a pair find its way to the entire team?
Through mob programming, because everyone works together on the same code. The driver types and comments as little as possible; the others take over the explaining. Switching roles roughly every ten minutes keeps everyone on their toes. Remote work has an advantage over a room with a single screen: Everyone can see exactly what’s happening right on their own computer. Questions are clarified during implementation rather than in a later review.
What do experienced architects gain by programming in a mob?
Direct feedback on whether their design is understandable and implementable in the code. Instead of a “that won’t work” in an individual review, they provide a “this is how it’s supposed to work” that’s tangible. They realize whether they need to adjust their communication or, in extreme cases, that the concept doesn’t fit the problem. This insight comes at a cost in the mob, but it’s better to realize it there than later.
Who on the team provides the measurable criteria for comparing solutions?
Often the testers. In such formats, they aren’t a downstream entity but rather the best source for criteria that determine whether a solution is better or worse, and therefore belong in the refinement phase from the start. It’s worth clarifying in advance what the testing is intended to achieve: rapid feedback for development and a regulatory compliance check in a regulated environment are two very different goals.
Why do new ways of working often meet with resistance within a team?
Because saying, “This is how we’re doing it now,” generates resistance. When framed as a clearly defined experiment with an evaluation after 90 minutes or two weeks, the barrier to entry drops significantly, because an experiment doesn’t commit you to anything. You don’t need authorization for this: two or three open-minded people are enough, and the results can be highlighted during the retrospective. Leading by example is more effective than trying to convince others.
