The Software Engineer Oath

Have you read the previous blog yet?: The Development Process, part 1?

In deze serie heb ik veel aspecten van het software engineering vak besproken die volgens mij belangrijk zijn voor een echte professional. Natuurlijk is mijn perspectief gekleurd door mijn eigen vaardigheden, ervaringen en wensen. Toch hoop ik dat het inzichten heeft gegeven in de wereld van softwareontwikkeling en vooral in de rollen en verantwoordelijkheden van de software engineer.

We hebben veel onderwerpen behandeld en ik vind het goed om ze hier nog een keer op te frissen.

Wat ik niet heb behandeld

Maar eerst een opmerking over volledigheid. Ondanks mijn beste bedoelingen en ondanks het feit dat deze serie tien delen telt kon ik niet alles bespreken wat ik wilde. Sommige aspecten van softwareontwikkeling pasten nergens logisch in. Andere schoten me pas enkele delen later weer te binnen. En sommige onderwerpen heb ik wel behandeld maar achteraf gezien te kort. Voor de volledigheid had ik graag meer gezegd over het belang van cloudontwikkeling, verschillende infrastructuurvragen, uitdagingen rond gegevensopslag, orkestratie, abstractie, ontkoppeling, de mogelijkheden van Kunstmatige Intelligentie en vooral de invloed van coderende Copilots, het belang van blijven leren, hoe je code kunt refactoren, wanneer je legacy moet herstellen en wanneer je het juist opnieuw moet bouwen, en zelfs een kleine aanwijzing over hoe je nee zegt. Dat heb ik helaas niet gedaan. Maar nu heb ik ze in elk geval allemaal genoemd en kun je doen alsof ik er zeer inzichtelijke dingen over heb gezegd.

Wat we hebben besproken

In het eerste deel begonnen we met waarom ik vond dat een blogserie over software engineering vakmanschap nodig was. De mate waarin ons vakgebied professionele, ethische en morele richtlijnen mist is verbazingwekkend en de jeugd van het vak is geen excuus, zeker niet omdat het vak exponentieel groeit. Ik probeerde ook het verschil te laten zien tussen coders, programmeurs en engineers, althans zoals ik die termen gebruik. Vrij naar mijn eigen woorden richten coders zich op code op het niveau van functies, zijn programmeurs verantwoordelijk voor features en zijn engineers verantwoordelijk voor software in al zijn abstracties, afhankelijkheden en realistische omstandigheden.

In delen twee en drie bespraken we de verantwoordelijkheden op codeniveau van een software engineer. Ik gaf aan dat het zien van code stijlen en patronen als het hoogste doel voor kwaliteitscode de plank misslaat en ontwikkelaars laat focussen op nette handschriften in plaats van op de boodschap die ze moeten opschrijven. In plaats daarvan pleitte ik voor drie dingen. Ten eerste het volgen van een duidelijk code proces zoals pair programming, code review, testen en mergen naar de main branch. Ten tweede het automatiseren van afgesproken stijlen en standaarden met tooling. En ten derde dat je wat je ook doet altijd testbare en automatisch geteste code schrijft. Verder stelde ik dat goede code zichzelf niet documenteert en pleitte ik voor het leren schrijven van kwaliteit documentatie of het laten genereren ervan, vooral over de redenen en momenten achter de gemaakte keuzes. Het wat van de code hoeft niet gedocumenteerd te worden tenzij we het bijvoorbeeld over publieke API's hebben zolang je ervoor zorgt dat de code eenvoudig te debuggen is en tests bevat die de verschillende codepaden beschrijven.

In delen vier en vijf zoomden we in op de verantwoordelijkheden op softwareniveau. Ik stelde dat kwaliteit code alleen belangrijk is voor zover het bijdraagt aan de kwaliteit van software als geheel. Ik noemde manieren om de kwaliteit van je software te meten en waarom dat belangrijk is. Defect density meet de correctheid van je software. Betrouwbaarheid wordt gemeten met Mean Time Between Failures en Mean Time To Repair. De winstgevendheid van software kan worden bepaald door de Return On Investment te berekenen. Ik besprak load testing, responstijd, throughput en resourcegebruik als manieren om prestaties te bepalen. Bruikbaarheid kan worden gemeten met analytics en vragenlijsten of soms iets eenvoudigs zoals het aantal klikken per veelvoorkomende taak. En tot slot bespraken we de mate waarin software integreerbaar is wat wordt uitgedrukt in integratie doorlooptijd en het aantal integratiepunten.

In deze twee delen noemde ik ook het belang van begrijpen waarom en wanneer we technische schuld aangaan en welke metingen helpen bepalen wanneer we die schuld moeten aflossen. Cycle Time, Bug Ratio en vooral de Technical Debt Ratio helpen inzicht te krijgen in softwarekwaliteit en de kosten van technische schuld. En tot slot noemde ik DevOps, de belangrijke feedbacklus ervan en het belang van verantwoordelijkheid nemen voor het hele proces van planning, bouwen, continue integratie, deployment en operatie wat weer terugvloeit naar planning. Ik stelde dat een softwareontwikkelproject DevOps zou moeten toepassen tenzij het door externe factoren niet mogelijk is.

In de volgende twee delen, zes en zeven, kon ik eindelijk praten over wat steeds meer een bepalende term in mijn loopbaan wordt: ethische softwareontwikkeling. Software maken die echt Goed is vraagt dat je zorgt voor veilige software en up to date blijft met betrekking tot beveiliging en dat security by design essentieel is. Een software engineer moet ook goed op de hoogte zijn van privacy en governance en we bespraken hoe je dat doet. We onderzochten de betekenis van verslavend ontwerp en waarom transparantie richting gebruikers belangrijk is. We keken naar manieren om vooroordelen te vermijden en inclusiviteit na te streven. We beoordeelden de voor en nadelen van open source software. Ik besprak het belang van transparante en overdraagbare code zodat anderen jouw software kunnen overnemen wanneer jij vertrekt en ook echt verantwoordelijk kunnen zijn. En in de meest idealistische alinea's van deze serie moedigde ik je aan om zowel de culturele als de milieutechnische impact van je software mee te nemen in je afwegingen.

In delen acht en negen bekeken we nog eens het softwareontwikkelproces en de mensen met wie we werken. We keken naar de problemen van Waterfall en naar wat er nog bruikbaar van is en naar de uitdagingen van Agile werken. Ik adviseerde je om efficiëntie te verhogen door vergaderingen te gebruiken als structuur en besprak ook hoe je vergaderingen efficiënt houdt. We doken in de ijzeren driehoek en hoe Kosten, Tijd en Scope allemaal moeten worden meegewogen bij deadlines. We sloten af met het bespreken van werken met mensen als essentieel onderdeel van het software engineering vak. We probeerden te bepalen hoe Product Leadership zich verhoudt tot Product Management en Product Ownership en ik betoogde dat een Product Leader in een bepaalde vorm een essentieel lid van elk softwareontwikkelingsteam is. We bekeken de fasen van groepsontwikkeling van Tuckman en hoe bewust zijn van die fasen Forming, Storming, Norming, Performing en Adjourning een software engineer kan helpen om het team efficiënter te maken omdat elke fase andere behoeften met zich meebrengt.

Mijn laatste punt was dat voor kwaliteit software een software engineer een paar belangrijke teamfactoren moet kunnen waarborgen, namelijk gelijkwaardigheid, emotionele veiligheid en plezier. Die zijn allemaal nodig om een teamcultuur te creëren waarin mensen samen kunnen bijdragen aan het maken van kwaliteit software.

Een laatste metafoor

In het allereerste deel van deze serie gebruikte ik de metafoor van een dokter om het belang van verantwoordelijkheid en professionaliteit in ons werk te illustreren. Toevallig is het dezelfde metafoor die deze serie zal afsluiten. Zoals je waarschijnlijk weet leggen dokters wanneer zij afstuderen een eed af. Terzijde opgemerkt dit is niet langer de eed van Hippocrates. Er zijn tegenwoordig zelfs meerdere varianten in omloop. Ze zouden dat eigenlijk moeten standaardiseren. In deze eden staat meestal hoe artsen zich proberen te gedragen als professional en aan welke standaarden zij zichzelf willen houden. Ik vind dat software engineers een vergelijkbare benadering nodig hebben.

Wanneer je de keuze hebt gemaakt om engineer te worden in plaats van coder of programmeur vind ik dat je een eed zou moeten zweren over wat die keuze betekent en waarom dat ertoe doet. Daarom presenteer ik je in dit laatste deel De Software Engineer Eed die ik Dijkstra’s Eed heb genoemd naar Edsger W Dijkstra bekend van Dijkstra’s algoritme. Het vat volgens mij op een overzichtelijke manier het absolute minimum aan verantwoordelijkheid samen dat iedere software engineer zou moeten naleven om ervoor te zorgen dat het vakgebied op een gezonde morele en winstgevende manier blijft groeien.

Dijkstra’s Eed

Ik zweer plechtig dat ik de volgende principes van vakmanschap en kwaliteit zal naleven in mijn werk als software engineer. Ik verbind mij aan het volgende:

Ik zal streven naar onderhoudbare testbare en efficiënte code.

Ik zal ervoor zorgen dat de kwaliteit van mijn code automatisch wordt vastgesteld met tests die de unit feature integratie en applicatie niveaus omvatten.

Ik zal automatisering omarmen om productiviteit te vergroten en tools gebruiken die de stijl en kwaliteit van mijn code en software beoordelen.

Ik zal ervoor zorgen dat mijn code en mijn software volledig worden gedocumenteerd waarbij ik de momenten werkwijzen en redenen achter mijn keuzes uitleg.

Ik zal beveiliging privacy en governance vanaf de vroegste mogelijke fase meenemen.

Ik zal metingen gebruiken om de kwaliteit van mijn software te kwantificeren en die metingen inzetten voor een feedbackproces dat toekomstige ontwikkeling ondersteunt.

Ik zal samenwerken met anderen de waarde van verschillende perspectieven erkennen en bijdragen aan een cultuur van gelijkwaardigheid emotionele veiligheid en plezier.

Ik zal mijn best doen om realistische deadlines vast te stellen op basis van beschikbare gegevens.

Ik zal verantwoordelijkheid nemen voor mijn software vanaf de planningsfase via de ontwikkelfase tot en met de uitrol en het gebruik ervan.

Ik zal mij verbinden aan een leven lang leren en blijf op de hoogte van de nieuwste technologieën trends en aandachtspunten binnen het snel veranderende veld van softwareontwikkeling.

Bij het nastreven van deze principes erken ik dat software engineering niet alleen gaat over het schrijven van code maar over het creëren van oplossingen die een positieve invloed hebben op de samenleving.

En nu?

Ik wil jou als lezer bedanken voor het lezen van alle tien delen van deze serie of op zijn minst dit laatste deel. Blijf vooral je gedachten en opmerkingen insturen want die zijn vaak erg waardevol geweest. Eerlijk is eerlijk de meeste waren waardevol. Ik ben vooral benieuwd naar jouw versie van een software engineering eed.

Zeker tegen het einde van de serie vroegen meerdere mensen mij of ik van plan was om na deze serie een nieuwe reeks te starten. Het is tijd om die vraag te beantwoorden.

Mijn plannen zijn om me eerst te richten op een paar losse blogs over nieuwe ontwikkelingen in AI. Ik begon deze serie begin 2023 met maandelijkse delen en dit jaar heeft AI vooral generatieve AI ongekend veel aandacht gekregen. Dat vakgebied heeft mij altijd al geboeid en ik denk dat ik waardevolle dingen kan zeggen over de huidige mogelijkheden en risico’s. Daarom voelt schrijven over dit onderwerp als een logische volgende stap. Maar daarna wie weet. Misschien maak ik nog een serie. Stuur me vooral suggesties. Misschien kom ik in de toekomst zelfs terug op deze serie en bespreek ik wat er sindsdien is veranderd. Want ik ben er zeker van dat ook als ik op de een of andere manier de hele serie volledig gelijk had tijd onvermijdelijk sommige van mijn waarheden in onwaarheden zal veranderen.

Kort gezegd ik ben niet van plan te verdwijnen en ik sta open voor ideeën. Het is ook niet alsof software engineering binnenkort zal verdwijnen.

Veel plezier met coderen.