Meten is weten! 📈

Het aantal producten waar ik aan mee heb mogen werken is inmiddels vrij groot.🏅 Maar het aantal projecten hiervan met zichtbare sturing op de directe doelstellingen is helaas bedroevend laag. 🤔

En nee, ik bedoel hiermee niet nutteloze metrieken als”velocity” 🚲 of afgewerkte user stories 🗑️. Ik heb het over concreet meetbare doelstellingen voor het resulterende product 📦, en in hoeverre hier voortgang in wordt gemaakt.

Een voorbeeld hiervan is een project waar we met een klein team een “recommender” voor films herbouwden. 🏗️ Hierbij besloten we om vanaf het begin de kwaliteit van de aanbevelingen te meten, en alles ondergeschikt te maken aan het doorlopend opdrijven van die waarde. 📈

💡 De eerste sprint leverde een meetmethode op basis van data uit een bekende externe filmdatabase, en als eerste implementatie een willekeurige 🎲 keuze uit de beschikbare titels. De score was voorspelbaar dramatisch, maar de infrastructuur hiermee aanwezig met een “aanbeveling” als product resultaat. 🎯

Daarna werd het fascinerend: 🧐

Door het meten van elke verbetering van onze algoritmen, ontdekten we dat de briljante ideeën uit het verleden helemaal niet zo’n geweldige impact op het resultaat hadden. 📉 En voor sommige oplossingen bleek de impact op de performance al helemaal de verbetering niet waard te zijn. 😳

Het eindresultaat van het project was een veel eenvoudiger oplossing met een gemeten betere functionaliteit dan de vorige implementatie. 🏆

In een recent project vroeg een directeur 🎩 me in de context van een project met tijdsdruk de bevestiging dat ik “hopelijk niet uit een industrie kom waar alles aan strenge kwaliteitsnormen moet voldoen”.

Een goede vraag! 🎯 Het roept namelijk iets fundamenteels op over softwareontwikkeling: is er ruimte voor snelheid zonder in te boeten op kwaliteit? 🤔

🔎 Een nadere blik op de realiteit in softwareontwikkeling:

1️⃣ “Een stevige basis bouwen kost tijd” 🎓: In sectoren zoals de luchtvaart, medische technologie of de financiële wereld is het vanzelfsprekend dat je niet kunt inleveren op kwaliteit – en terecht. Maar die kwaliteit zit op een heel ander abstractieniveau dan waar we het in softwareontwikkeling doorgaans over hebben. Een fundamenteel doordacht ontwerp staat los van de toepassing van ducktape als constructiemateriaal tijdens het bouwen.

1️⃣ In wat door moet gaan voor “agile” omgevingen, streven we vaak slechts naar snelle releases tegen een krappe deadline. Maar wat we vaak vergeten is dat snelheid zonder kwaliteitscontrole door de complexiteit van moderne software met zekerheid leidt tot een enorme hoeveelheid fouten. 💩 En die herstellen kost uiteindelijk méér tijd, waardoor de bereikte snelheid niet te handhaven blijkt en de agile transitie “dus” niets op heeft geleverd. 😢

3️⃣ In mijn persoonlijke ervaring heb ik meerdere malen mogen ervaren dat de fundamentele keuze voor “kwaliteit boven meer features” 🌈 een wonderbaarlijk solide basis oplevert voor de toekomst: Het betekende veel minder tijd kwijt zijn aan het doorlopend herstellen van problemen, en dus volledige focus op features die werkelijk waarde aan het product toevoegen.

Dit klopt met de stelling over “technical debt” door Ward Cunningham: Snelle, suboptimale codeoplossingen lijken op korte termijn handig zijn, maar leiden uiteindelijk tot extra werk en onderhoudskosten die je later moet “aflossen” om de code onderhoudbaar te houden.

Investeren in kwaliteit levert daarmee juist de gehoopte verhoging van snelheid op. 🚀 Misschien niet in het absoluut aantal gesloten tickets, maar wel in het succes van het product. 💰💰💰

(En de “Hexagonal” architectuur dus ook.)

Nadat Uncle Bob (Robert Martin) jaren geleden zijn “Clean Architecture” in een vaag artikel op zijn blog beschreef, heb ik deze architectuur in verschillende Java backend projecten met wisselend succes toegepast. In eerste instantie door mijn onbegrip over zijn suggesties 🤷‍♂️, maar later ook door onbegrip over wat het werkelijk brengt. 🤦‍♂️

In de wereldwijde Flutter gemeenschap blijkt Clean Architecture inmiddels ook een enorme opmars the hebben gemaakt. Maar ook daar lijkt het onbegrip hoogtij te vieren, waardoor zelfs simpele apps trots worden gebouwd als enorme gelaagde gedrochten. 🦄

Fundamenteel is Clean Architecture een poging om vanwege “Separation of Concerns” het domein van de applicatie los te weken van de opslag en de toepassing in een IT omgeving (=de UX of een API). Hiervoor wordt de code in lagen verdeeld, met een strikte oriëntatie van alle afhankelijkheden richting de domein code.

En die strikte opdeling is waar het vaak mis gaat:

➡️ Is die volledige Separation of Concerns wel altijd zo zinvol als de applicatie niet zo groot is, of maar door een enkele ontwikkelaar wordt beheerd?

➡️ Wat nou als het “domein” in de UX of juist in de database is gestopt, en er dus nauwelijks domein over blijft?

Door in die gevallen toch vast te houden aan de voorgeschreven rigide opdeling, is het resultaat een wirwar van interface, classes, en conversies die alleen nog aan de onderhoudskosten en hoeveelheid bugs bijdragen.💩

Clean Architecture is volgens mij nog steeds een goed idee 🌈, maar het is zeker niet de oplossing voor elke situatie.

De meeste programmeurs blijven een voorkeur hebben voor het achteraf schrijven van automatische testen. Ik vind dat sub-optimaal, maar het is beter dan geen testen. Met de opkomst van code assistenten, is de nieuwste trend om deze testen door AI te laten schrijven. ✨

Maar is dat wel zo’n goed idee? 🤔

Voor eenvoudige code lijkt er geen vuiltje aan de lucht. Echter, zodra code complexer is (en de testen dus belangrijker), ontstaan er significante risico’s:

1️⃣ Testen zijn (ook) bedoeld om de intentie van de programmeur weer te geven. Bij een complexe implementatie raken die intenties verborgen in de slimme code, zodat de gegenereerde testen nog slechts de implementatie in plaats van de intentie beschrijven.

2️⃣ Als er bugs in de implementatie zitten, dan zullen de testen slechts bevestigen dat die bugs er in zitten. Naast dat dit false-positives over de correcte werking oplevert, zullen de toekomstige oplossers van deze problemen hierdoor zelf moeten gaan bedenken of het ongewenste gedrag wellicht toch met opzet is gebouwd.

3️⃣ Realiteit van automatische testen is dat (lang) niet alle paden te testen zijn, waardoor een menselijke programmeur zal kiezen voor testen die het bedoelde bedrag zo ver mogelijk afdekken. Omdat een AI die context niet heeft, zullen er ook onnodige testen worden geproduceerd die niets toevoegen maar wel onderhouden moeten worden.

Als we door AI gegenereerde testen dus niet (minstens) zorgvuldig handmatig controleren, zal hun waarde niet veel groter zijn dan de klassieke pogingen om de “coverage” op te krikken met testen die de code aanroepen zonder te controleren of het gedrag wel klopt. 🙈

Laten we AI vooral gebruiken waar het echt waarde toevoegt, maar de regie over kwaliteit voorlopig nog even bij mensen laten. 🤝