Beheers de kunst van software engineering

Gepubliceerd op: 03 september 2020

Auteur:

Nieke Roos

Hoofdredacteur bij Bits&Chips

Lees meer over Nieke Roos

Expert:

Robert Deckers EngD,PhD

Trainer

Lees meer over Robert Deckers

Deel

---

Met de groeiende afhankelijkheid van software in een steeds meer high-tech wereld, is het belangrijker dan ooit om als software architect de kunst van software engineering onder de knie te krijgen. Trainers Robert Deckers en Bart Vanderbeke hebben het op zich genomen om van ontwikkelaars vakmannen te maken.

“Een collega vertelde me ooit over een van zijn voormalige projectmanagers die, toen hij zich realiseerde dat de schattingen niet klopten met zijn tijdlijn, ze gewoon doormidden hakte om ze passend te maken. Ik vind het ongehoord, niet alleen dat je zoiets doet als projectmanager, maar ook dat mensen dat soort gedrag vertonen. Je hoeft hem niet uit te schelden, maar je kunt wel je mond open doen. In plaats daarvan klaagt iedereen aan het eind van het project, als alles in het honderd is gelopen, over hoe hen dit is overkomen.”

Geïnspireerd door Google executive Fred Kofman en zijn boek “Conscious business“, roept Bart Vanderbeke software architecten op om te stoppen met het spelen van het slachtoffer. “Het is onaanvaardbaar en ongezond”, beweert hij. “Jij bent de vakman. Als iemand je zegt dat je iets in de helft van de tijd moet doen, of het ontwerp moet overslaan, of geen reviews moet doen, dan zeg je nee – constructief. Software-architecten zijn schaars, dus je zit in een comfortabele positie, zeker geen positie om jezelf te beschuldigen. Verschuil je niet achter ‘management’. Als software vakman, om een term van Kofman te gebruiken, ben je ‘onvoorwaardelijk verantwoordelijk’ voor alles wat je wel of niet doet.”

“Je moet onvoorwaardelijke verantwoordelijkheid nemen, wat letterlijk betekent dat je het vermogen moet hebben om te reageren – op een zinvolle manier,” zegt Bart Vanderbeke. Credit: Bart Vanderbeke

Bij NXP in Leuven leidt Vanderbeke een team van vijftien softwarearchitecten die werken aan 2,4 GHz radiotoepassingen voor persoonlijke gezondheid – denk aan gehoorapparaten, koptelefoons en oordopjes. “Kleine systemen met kleine softwarestacks,” merkt hij op. “Maar zelfs als je een codebase van 100k of 200k hebt, zoals wij, is software vakmanschap van het grootste belang. Het bouwen van de hardware duurt ongeveer een jaar, gevolgd door misschien vijf jaar softwareverbetering. Ik heb een serie lezingen ontwikkeld om mijn collega’s te helpen hun innerlijke vakman naar boven te halen.”

De niet-functionele

Als geestverwant wil Robert Deckers ook het vakmanschap in software vergroten, maar dan met een focus op softwarearchitectuur – “de moeilijkste truc van het vak”, zoals hij het noemt. “Het begint al met de vraag: wat is softwarearchitectuur? Er zijn honderden boeken te vinden die een antwoord proberen te geven. Hoewel sommige slecht zijn, verschrikkelijk zelfs, zijn de meeste zinvol, maar ze vertellen allemaal een ander verhaal.” Dit was een van de twee triggers die hem ertoe brachten in het onderwerp te duiken, zijn eigen visie te ontwikkelen, zijn eigen boek te schrijven en zijn inzichten aan anderen te schenken.

De tweede trigger was het besef dat er in traditionele methodologieën te veel aandacht is voor de functionele eisen, terwijl de niet-functionele eisen het moeilijkst te doorgronden zijn en daarom de meeste tijd in beslag nemen. “Lang geleden, toen ik OOTI-stagiair was aan de Technische Universiteit Eindhoven, was ik de softwarearchitect voor een kopieermachine”, herinnert Deckers zich. “Na twee maanden ontwerpen begon het afwijkende gedrag van het systeem de kop op te steken en realiseerde ik me dat we ook aan foutafhandeling moesten doen – hoewel het voor de hand lag voor iemand met 20 jaar ervaring, was het niet bij me opgekomen. Toen we klaar waren, bleek tot mijn grote verbazing maar liefst 85 procent van al onze code voor foutafhandeling te zijn, dus slechts 15 procent van onze inspanningen was gericht op de functionaliteit. Op dat moment ervoer ik voor het eerst dat de echte uitdaging, de echte complexiteit, in het niet-functionele zit.”

Na het OOTI-traineeship – de PDEng Software Technology, zoals het tegenwoordig heet – scherpte Deckers zijn inzichten aan bij verschillende bedrijven, waaronder Philips Research en Sogeti. Sinds 2013 runt hij Atom Free IT, waarbij hij organisaties en hun architecten begeleidt bij het creëren van architecturen, het opzetten van het architectuurproces en het verankeren ervan. De laatste vijf jaar combineert hij dit met een PhD-project aan de Vrije Universiteit Amsterdam, waarin hij onderzoek doet naar de cognitieve aspecten van systems engineering.

Kom voorbereid

Vanderbeke en Deckers zijn de nieuwste toevoegingen aan de software- en systeemportfolio van High Tech Institute. Beiden willen software architecten helpen beter te worden in hun werk – echte vakmensen worden. “Als software vakman weet je hoe je je werk moet organiseren en heb je de assertiviteit om geen compromissen te accepteren over de manier van werken. In plaats daarvan ga je voor het optimale, rekening houdend met de invloedsvariabelen en omstandigheden. Je doet geen dingen omdat iemand je zegt dat je ze moet doen, maar als je de noodzaak begrijpt, beslis je autonoom om ze te doen,” vat Vanderbeke de waarden samen die hij in zijn workshops wil overbrengen.

Robert Deckers benadrukt het belang van het focussen op de niet-functionele eigenschappen, oftewel de kwaliteitsattributen.

Op een constructieve manier nee leren zeggen is een belangrijk onderwerp in Vanderbeke’s lessen. “Dat vereist dat je goed voorbereid bent. Als je wordt gevraagd om een koers uit te zetten in een project, moet je een aantal opties paraat hebben, niet tot in de kleinste details, maar zodanig dat je ze kunt afwegen en een weloverwogen keuze kunt maken. Als iemand naar je toe stapt en zegt dat iets kan worden gedaan in de helft van de tijd die je hebt geschat en je hebt je feiten niet op een rijtje, dan kan hij wel eens gelijk hebben – je hebt geen manier om dat te zeggen. Als je weet waar je het over hebt, zal dat niet gebeuren. Je kunt een constructief gesprek voeren en je kunt worden uitgedaagd, zelfs overtuigd, maar je laat je niet wegblazen door ongefundeerde beweringen. Iemand vroeg me ooit of we dingen konden versnellen door kortere wegen te nemen, waarop ik antwoordde: ‘De enige kortere weg die je kunt nemen is beknibbelen op de specificaties’ – en dat was het einde van de discussie.”

“Je moet onvoorwaardelijke verantwoordelijkheid nemen, wat betekent dat je het vermogen moet hebben om te reageren – op een zinvolle manier,” vervolgt Vanderbeke. “In mijn workshops gebruik ik verschillende kleine voorbeelden uit mijn dagelijkse werk om mijn punt duidelijk te maken. Iemand die zijn verantwoordelijkheid ontloopt, zou bijvoorbeeld zeggen: ‘Ik heb mijn schatting gehalveerd omdat mijn projectmanager me dat opdroeg’, in tegenstelling tot iemand die zich verantwoordelijk houdt, een ‘speler’ in de termen van Fred Kofman, die zou zeggen: ‘Ik wilde ruzie met mijn projectmanager vermijden, dus gaf ik toe’. Op dezelfde manier zou een slachtoffer zeggen: “Ik maak schattingen omdat ons proces dat vereist”, terwijl een speler zou zeggen: “Ik wil bij het bedrijf blijven, dus ik gebruik het vastgestelde proces”. Door ze bewust te maken van deze kleine dingen, zijn mensen eerder geneigd hun gedrag te corrigeren.”

Een goede architectuur is correct, consistent en wordt gecommuniceerd. Krediet: Robert Deckers

Vis noch gevogelte

In zijn trainingen geeft Deckers zijn ideeën over goede architecturen. “De rol van architectuur is om een oplossingsaanpak te bieden voor de belangrijkste systeemeigenschappen die het moeilijkst te realiseren zijn. Als systeemarchitect moet je er altijd voor zorgen dat je naar een oplossing toewerkt, begeleiding biedt en tegemoet komt aan de behoeften van je stakeholders, terwijl je ook een oogje in het zeil houdt voor dingen die fout kunnen gaan als ze niet in de architectuur worden aangepakt. Als je dit niet doet, ben je waarschijnlijk geen architect. Ik wil ook dat software-architecten begrijpen dat een architectuur zakelijke waarde moet bieden en dat het haalbaar is om het systeem binnen de organisatie te bouwen. Je kunt alleen een effectieve architect zijn als je bereid bent om uit je technologische comfortzone te stappen.”

Volgens Deckers is een goede architectuur correct, consistent en gecommuniceerd. “Een systeem moet correct zijn in die zin dat het moet voldoen aan de belangen van de belanghebbenden en de technische omgeving. Het ontwikkelingsproces moet consistent zijn. Bij Philips in Brugge was ik er ooit getuige van hoe een softwarearchitect alle voorwaarden testte van alle functies die hij programmeerde, omdat hij wilde dat zijn code robuust was. Ondertussen gebruikte een collega in het hokje vlak naast hem pointers zonder iets te testen omdat hij wilde dat zijn code snel was. Gecombineerd in één systeem levert dat vis noch gevogelte op. Je moet duidelijk zijn over de belangrijkste eigenschappen – mijn advies: hang de top vijf aan de muur. Tot slot moet een architectuur zo worden beschreven dat je hem kunt bespreken met de verschillende belanghebbenden, wat betekent dat je verschillende views moet gebruiken voor verschillende aspecten.”

Deckers benadrukt het belang van het focussen op de niet-functionele eigenschappen, oftewel de kwaliteitsattributen. Hij erkent dat dit haaks lijkt te staan op het populaire Agile principe om zo snel mogelijk werkende software op te leveren. “Mensen vragen me vaak: hoe match je Agile en architectuur? Mijn antwoord aan hen: dat doe je niet. Het zijn twee verschillende denkwijzen. Bij architectuur gaat het erom dat je eerst kijkt voordat je springt, terwijl je bij Agile gewoon gaat en bijstuurt op basis van de feedback die je krijgt. Dat is prima voor sommige bedrijven, maar niet voor een kopieermachine of een medische scanner, waar aspecten als betrouwbaarheid en veiligheid van tevoren bekend zijn. De beste manier om Agile en architectuur op elkaar af te stemmen is door de regels om te buigen en de eerste paar sprints te wijden aan de belangrijkste aandachtspunten.”

Als je afdaalt in de managementtrechter, wordt de focus smaller en het risico op conflicten groter.

Betere beslissingen

Bij samenwerking is er altijd wrijving. Een software craftsman heeft daarom ook tools nodig om conflicten op te lossen. In zijn workshops presenteert Vanderbeke een managementtrechter die tegelijkertijd een omgekeerde conflictpiramide is. Het gaat van breed naar smal in drie niveaus: strategisch, tactisch en operationeel – van het wat naar het hoe. Als je afdaalt in de trechter, wordt de focus smaller en het risico op conflicten groter. Als er daadwerkelijk een conflict ontstaat, gaat u terug naar boven in de trechter om te proberen een gedeeld doel of principe te vinden om de zaken glad te strijken.

“Software-architecten die het oneens zijn over de manier waarop een probleem moet worden aangepakt, zitten vaak onderaan vast in hun eigen oplossing. Door hen op te pakken en de probleemcriteria te bespreken, komt er meestal een einde aan de impasse omdat ze het met elkaar eens zijn,” illustreert Vanderbeke. “Het is ook een zeer nuttig instrument in procesmanagement. Als je in een vergadering zit die nergens toe leidt, ga dan nog eens na waarom de vergadering überhaupt is opgezet en er zal zich bijna automatisch een uitweg aandienen.”

Met een gevulde gereedschapskist in de hand zijn software-ingenieurs goed uitgerust voor vakmanschap. Met Deckers besluit Vanderbeke: “Het zou geweldig zijn om ze betere beslissingen te zien nemen. Om ze autonomer te zien werken. En tegelijkertijd meer plezier te zien hebben in wat ze doen.”

Dit artikel is geschreven door Nieke Roos, tech-redacteur van Bits&Chips.