Designing architecture together means consciously making far-reaching software decisions as a team instead of leaving them to individual architects. Three experiments help here: a long-term product view as orientation, double pairs to compare two solution alternatives in the code and mob programming for joint implementation and knowledge transfer.
Key Takeaways
- Architecture decisions are difficult to reverse, which is why broad participation of all team members in making these decisions directly improves the quality of the solution.
- Double Pairs means: Two teams of two develop a solution in parallel in order to make architecture alternatives comparable on the basis of measurable criteria instead of purely theoretical discussions.
- Mob programming transfers architectural knowledge to the entire team because all participants see the code live, ask questions and clarify misunderstandings immediately before they become embedded in the production code.
- Architects, who participate in mob sessions instead of just commenting in the review, receive direct feedback on whether their design decisions are understandable and feasible in the code.
- New ways of working are easier to introduce if they are labeled as temporary experiments, because the label “experiment” measurably reduces resistance in the team.
Architecture decisions are expensive to revise, so it pays to have a common basis
An architectural decision carries a special weight: it is far-reaching and cannot simply be reversed later. This is precisely what distinguishes it from a random code change.
Anyone who discovers during testing that load and performance are not working quickly ends up with the same suspect: the architecture. At this point, a correction is a tour de force. The pressure of pain has to be great enough for someone to be 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 problem is. You would first have to prove that the investment will actually bring about an improvement before anyone will approve it.
Maximilian Aulinger and Melanie Brunnbauer therefore start earlier. Their conviction from working with software development teams: intensive collaboration in which everyone is heard, even the introverts, delivers a better technical and professional solution. Architecture decisions need as broad a basis as possible before they are made.
Double pairs: building two solutions in parallel instead of endlessly discussing them
Double Pairs is an experiment for precisely the moment when a team is wavering between two alternative solutions and both sides present plausible hypotheses.
Instead of continuing the discussion, two pairs each build a breakthrough in parallel. Hence the name: two pairs, two approaches. Both work towards measurable criteria, such as hard performance targets that must be achieved for end-user quality.
The result is something you can touch. Two comparable punctures or at least two stands that allow a conclusion to be drawn as to which approach is more suitable based on the criteria.
The constellation does not have to be rigid. Two pairs are the usual starting point, but it can also be twice three people. Close collaboration with a lively exchange usually works better in pairs than in larger groups because it requires a lot of trust. More than two approaches are rarely needed because the third or fourth has often already been discarded in the discussion.
When is twice the effort worth it?
Double pairs cost double the development time, so the team should clarify beforehand when to stop the experiment. There are two ways to do this.
With a resilient, measurable criterion, you develop until you can test and then stop. Without a hard criterion, a timebox helps: invest a day, run A against B and check the next morning how far both approaches have come.
It doesn’t always have to be about two completely new solutions. A sensible variant: one team knows one approach well, the other is technologically unknown. Then it only builds the unknown one in a test-like manner to feel how it feels and compares it with the known one.
There are no general criteria. What helps is to go back to the question of what the solution is supposed to achieve. If an organization or product manager clearly answers the purpose of an enhancement, measurable criteria can be derived from there.
Architecture decisions are often hidden in the code
Many architectural decisions are not even made consciously, but are manifested during coding. This makes them difficult to grasp and expensive in retrospect.
Typical questions that only become apparent hands-on in the code concern the connection of external APIs: blocking or non-blocking, synchronous or asynchronous, and how this feels on the surface. Cross-sectional functions such as the integration of logging can also be compared in this way because the result is tangible and answers the question of whether a production operation would be viable with it.
A concrete example: one team was asked to enable a digital signature in an ongoing business process. The process itself was the responsibility of another team, and they were 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 fraught with uncertainty: Would the integration work? How much effort is involved? Does it fulfill the promise of reusability? The team took one and a half to two days to try it out as a mock instead of discussing it in advance.
A decision needs a conscious decision rule, otherwise a trench war will ensue
If no solution feels clearly better by the deadline, the team needs a previously agreed rule on how to decide. Otherwise, a half-baked solution will remain, with one part of the team not going along with it.
An accompanied team has practiced this as a sporting competition: if both approaches are on a par, the pair with the faster, more resilient result wins. This saves further thought, but requires trust and people who will back down when in doubt.
A full consensus does not have to be the goal. A “good enough for us” is often the more helpful approach. The important thing is to make the decision consciously, whether by coin toss, best of five or clear agreement. Otherwise, a latent trench warfare arises because team members who have been ignored do not feel taken seriously.
If the criteria are very close to each other, this is also a realization. Then it may be right not to start the experiment at all because the double investment is not worth it.
Beforehand: a clear why beyond the next sprint
Before two solutions are built, it helps to have a clear goal. Teams that work iteratively usually only plan the next sprints and lose sight of the medium term.
Everyday life is often stuck in the operational turf: what will happen tomorrow, what in two weeks, what in four. Beyond that, it’s often a hand-to-mouth existence.
The antidote is a short, regular round with a fixed timebox. One hour is enough to take a step back and ask where the software product should be in six months’ time. Deliberately not down to the last detail, but as an overview that establishes the perspective for the upcoming decisions.
After: Mob Programming puts the decision in people’s heads
Every architectural decision is only as good as its implementation. If it is not brought to life in the code, it is invalid. And the implementation is usually as good as the understanding of those who write the code.
This is exactly where Mob Programming comes in. If two people have worked out a breakthrough via double pairs, the other two are not yet familiar with the implementation. The necessary knowledge transfer succeeds in the mob because everyone works together on the same code.
Remote has a practical advantage over the classic room with a screen. Everyone sits in front of their own computer and can see directly what is happening. The driver does the typing and comments as little as possible, while the others do the explaining. This creates a lively exchange, from “there’s a semicolon missing” to “that’s not how the structure was actually intended”.
It is important to change regularly, every ten minutes or so, so that everyone stays on the ball. During implementation, questions arise that you would otherwise ask yourself when coding alone. In the mob, there are people sitting next to you who have answers, sometimes throw a snippet into the chat, and the team makes progress faster than through downstream reviews.
The implementations are usually as good as the understanding of the people writing the code. That’s why it’s important to communicate an architectural decision clearly and show what it looks like in reality.
- Melanie Brunnbauer
Architectural knowledge belongs in the team, not in individual heads
In many companies, architectural knowledge is held by two or three people who have been there for years and distribute their “that’s not how it works” in individual reviews. This leaves no learning experience and the knowledge remains with these architects.
The most effective lever is to take these people into the mob if they are willing to help code. They think along with you, ask questions, give impulses and sometimes type themselves. Instead of just “not like this”, they deliver a “this is how it’s meant to be” that is tangible.
The effect goes both ways. The architect realizes whether his high-level concept is understandable, whether he needs to change his communication and, in extreme cases, even that the concept does not fit the problem. This last realization comes at a high price in the mob, but should be made a little earlier.
How do teams involve testers in these experiments?
Testers are not an afterthought in these formats, but often the best source of measurable criteria for whether a solution is better or worse. This is precisely why they are involved early on, right from the refinement stage, where they say what they will be looking at later.
There are also mob testing sessions. The team meets in a similar constellation and defines a focus: Are all masks consistent? Or are we trying to break the application as much as possible today?
It’s worth clarifying one thing in advance that is often missing: what is testing supposed to achieve? Rapid feedback for development and a TÜV in a regulated environment are two very different goals. Putting this question openly on the table helps the team move forward. In a mob session, people with a strong focus on quality criteria are also very good navigators.
How do you start a first experiment, even without a mandate?
You don’t need the approval of the project manager or the coach to get started. Find a colleague who is open-minded and try something out on a small scale, in pairs or threes.
If you work in an agile way, the retrospective is a natural place to make the result visible. “We tried this in the last sprint, we liked it” initiates a change from below without having to enforce it from above.
The way you speak makes all the difference. “We’re doing it this way now” creates resistance. “Let’s try this out as an experiment and evaluate in 90 minutes or two weeks whether it has helped us” lowers the hurdle significantly. A clearly labeled experiment does not commit you to anything.
Demonstration beats persuasion. When two people simply try a method and a third person stands next to them and realizes that it works, it has a completely different effect than any theoretical discussion.
Collaboration can be shaped, just like the software
The real quintessence of these experiments: It’s not just the software that can be shaped, but also the collaboration within the team. Both can be consciously shaped.
There is no patent remedy. What works for one team may not work for the next, but something else will work there. Different requirements require different forms of cooperation in order to provoke good solutions.
This includes seeing differences positively rather than as a disruption. The tester who asks agonizing questions is not a brakeman. In the right corner, he is the one you bring in. Particularly after phases of remote isolation, it is worth getting to know the strengths of the individuals again by working together.
