Omdat ik voor het vinden van bezienswaardigheden 🏛️ en goede eetgelegenheden 🍽️ regelmatig gebruik maak van Google reviews, deel ik zelf al jaren mijn ervaringen voor anderen. Zo ben ik in Google Maps langzamerhand opgeklommen tot een “Local Guide” van (bijna) niveau 8, met onder andere ruim een miljoen fotoweergaven.

Om dit bij te houden ga ik er soms even voor zitten om korte reviews ✍️ te schrijven, foto’s 📷 te uploaden en simpele vragen ✅ te beantwoorden over de plaatsen waar ik ben geweest. Hierbij is het telkens weer fascinerend hoe goed Google weet waar ik allemaal ben geweest.

Maar deze week gebeurde er iets vreemds: Ik kreeg vragen over een bedrijf waar ik een paar weken geleden slechts met een bemiddelaar over heb (gebeld en) gemaild. 🕵

🤔 Zou Google werkelijk mijn emails en fysieke locatie combineren tot een (hallucinante) nieuwe werkelijkheid?

Stop dus met fantaseren 🦄, en begin met bouwen! 🚀

Ken je dat? 🤔 De harde eis dat er eerst een volledige specificatie 📚 moet zijn voor we “veilig” aan de realisatie kunnen beginnen? Bij een van mijn klanten lag er na een jaar zwoegen een enorme berg documentatie, waar zelfs de auteurs het overzicht kwijt waren 😅. – Wat zouden we ook alweer bouwen?

Het probleem: te veel tijd in plannen, te weinig tijd in de praktijk. Documentatie is waardevol, maar alleen als het project vooruit gaat. Analyseren blijft belangrijk, maar er komt een punt waarop je gewoon moet starten met bouwen! Door direct aan de slag te gaan, leren we sneller en ontdekken we vroegtijdig wat werkt (en wat niet) 💡.

Een paar tips om te voorkomen dat je in analyse blijft hangen:

1️⃣ Bouw al vroeg prototypes of (beter nog) een “minimum viable product”: Laat iets tastbaars te laten zien in plaats van alleen een wolk van mooie woorden. 📦

2️⃣ Werk iteratief: Bouw en test in korte cycli; en gebruik elke stap om feedback te verzamelen en te leren. ♻

3️⃣ Betrek de echte gebruikers: Schrijf geen ellenlange rapporten en bouw geen mockups, maar toon regelmatige demo’s van het echte product en voer inhoudelijke gesprekken over wat de gebruikers nodig hebben. 🎬

Eindresultaat? Een beter product, in minder tijd. Dus… waar wacht je nog op? Tijd om te bouwen! 🛠️

Open-source code gebruiken is verleidelijk makkelijk: even iets van GitHub plukken, en voilà! 🍄 Maar niet elke open-source licentie komt zonder verplichtingen. Sommige licenties zijn “besmettelijk” ☢️. Als je code met zo’n licentie in je project opneemt, kunnen “copyleft” licentie-eisen inhouden dat je mogelijk jouw eigen code openbaar moet maken.

De bekendste besmettelijke licenties zijn:

☢️ GNU General Public License (GPL)
☢️ Affero General Public License (AGPL)

Voeg je code met een van deze licenties toe aan je eigen project, dan kunnen de licentie voorwaarden zich uitbreiden naar jouw code. Niet ideaal als je werkt aan een commercieel product. 💣

Gelukkig valt veel open source code onder een van de populaire “permissieve” licenties 🌈, die veel minder eisen stellen:

🌈 MIT-licentie
🌈 Apache-licentie 2.0
🌈 BSD-licentie

Met deze licenties kun je de code (meestal) zonder zorgen gebruiken en aanpassen.

Tips om problemen te voorkomen: 🛟

1. Check altijd de licentie voordat je een library toevoegt of kopieert.
2. Twijfel je? Win dan juridisch advies van experts in.
3. Zoek alternatieven: Die zijn er meer dan je verwacht.
4. Gebruik tracking tools zoals FOSSA, Snyk of Black Duck geven je automatisch inzicht in de gebruikte licenties binnen je project.

Open source is een geweldige bron, maar kent zijn eigen regels. Voorkom verrassingen door licenties serieus te nemen. Zo blijf je een hoop werk en stress bespaard. 💣

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. 💰💰💰