Menu

De één schrijft code, de ander observeert

In agile software ontwikkeling is pair programming een bekend fenomeen. De één schrijft de code, terwijl de ander observeert. De voordelen zijn onder andere hogere kwaliteit van de code, betere samenwerking in teams en, niet onbelangrijk, een groter plezier in het werk.
Op het gebied van software architectuur missen we dit eigenlijk. In de praktijk zie ik vaak dat architecten in agile teams behoorlijke eilanden zijn. Zeker in omgevingen waar meerdere Scrum teams werken aan producten die onder een bepaald programma vallen kunnen daardoor op het gebied van architectuur al snel misverstanden ontstaan. Hierdoor kunnen de teams te ver uit elkaar gaan lopen en zijn de onderdelen van de uiteindelijke totaaloplossing niet goed op elkaar afgestemd. Dat kan ook leiden tot moeilijke beheerbare oplossingen en veel refactoring.

Zou pair architecting (volgens mij bestaat de term nog niet) hier niet een oplossing kunnen bieden?

Er bestaan verschillende vormen van pair programming en dus ook van pair architecting. De twee meest voorkomende zijn:

  • Expert-Expert.
  • Expert-Nieuwkomer.

Beide varianten hebben hun voor- en nadelen. In het Expert-Expert geval zal minder vaak tot nieuwe inzichten worden gekomen, omdat de al jaren toegepaste principes niet snel zullen leiden tot vragen of kritiek. Het Expert-Nieuwkomer model levert vaker verrassende inzichten op, omdat de Expert zaken opnieuw helder moet proberen uit te leggen aan de Nieuwkomer en daardoor tot nieuwe inzichten kan komen én de Nieuwkomer zal vaak al jarenlang toegepaste principes ter discussie stellen, als hij of zij een beetje assertief is. Beide varianten leveren in de meeste gevallen een betere en beter onderbouwde architectuur op.

Het belangrijkste is echter dat er meerdere mensen bezig zijn met het bedenken, tekenen en documenteren van architectuur en dat men elkaar scherp houdt. Waarbij de één ook meer tactisch bezig is en de ander tegelijkertijd meer strategische inzichten kan bieden. Tegelijkertijd is er borging van kennis bij meerdere personen en kan de rol van het borgen van architectuur in de agile software-ontwikkelteams altijd ingevuld worden, al is het maar parttime. Door regelmatig de rollen om te draaien in de paren (dan tekent en documenteert de één en observeert de ander en dan weer andersom) houdt men het architectenpaar ook fris.

Architecten die in paren samenwerken zullen in de praktijk ook, net als bij programmering, merken dat:

  • De kwaliteit van de architectuur beter is en men met meer zekerheid achter de gekozen architectuur staat.
  • De ontworpen architectuur breder gedragen wordt.

Een laatste belangrijke conclusie is dat hoe eerder in een software-ontwikkeltraject fouten worden voorkomen, hoe goedkoper het is om het op te lossen. Architectuurfouten te laat ontdekken kan leiden tot zeer dure refactoring. Wat dat betreft levert pair architecting potentieel nog veel meer voordeel op dan pair programming.