Niet als je mij de klus laat klaren! 🚀

In softwareontwikkeling is Inhuur per uur de norm. Maar dit maakt de ingehuurde hulp slechts “personeel”, en legt het risico volledig bij de opdrachtgever. Terwijl deze hulp eigenlijk bedoeld was om tijdelijk een waardevol probleem op te lossen.

Wanneer software geen eigen expertise is, dan is dit zelfs de meest gevaarlijke manier om software te ontwikkelen: De visie verwatert door nieuwe ideeën, en er is geen motivatie om efficiënter te worden of het werk zelfs maar af te ronden. Dit is geen incident; dit is wat ik in mijn carrière heel vaak heb gezien gebeuren.

💡Als echte freelancer ben ik geen tijdelijk personeel, maar een onafhankelijke aannemer die projecten tegen een vaste en realistische prijs aan durft te nemen.

Ook als je nog niet in detail weet hoe de oplossing er uit moet ziet, kan ik helpen om dit boven tafel te krijgen en/of een eerste minimale versie te realiseren. Naast mijn eigen brede kennis en ervaring, gebruik ik hiervoor mijn eigen netwerk en gereedschap. 🧰

Maar wat kost het als je te snel gaat? 💰💰💰

Snelheid is op dit moment de grote hype: We willen zonder investering zo veel mogelijk software produceren. En de hype rond AI belooft dat we ongekend productief kunnen zijn met minder specialistische kennis. Dat lijkt een eenvoudig sommetje. 🚀

Maar in de haast ontstaat er iets geks:

⚠️ Bugs duiken op in onverwachte plaatsen
⚠️ Nog meer features toevoegen wordt steeds moeizamer
⚠️ Niemand weet nog precies hoe de kern werkt

Dit geen mensenprobleem of beperking van de tools, maar een architectuur- en ervaringsprobleem.

💡 Of het nu gaat om een backend in Java of een multi-platform app in Flutter: Duurzame software begin bij de juiste keuzes op het juiste abstractieniveau. En dat is niet iets wat door AI (en zeker niet zonder ervaring) opgelost wordt.

Ik help al jaren teams om vanaf dag één een fundament te leggen dat:

✅ Schaalbaar is, zowel op technisch als organisatorisch niveau
✅ Begrijpelijk blijft, ook na 18 maanden
✅ Geen jungle wordt van hacks en “quick-wins”

En natuurlijk hoort daar de gezonde toepassing van AI gewoon bij.

Tijd om de mythe te ontkrachten 🔎

Ook ik heb me sinds een paar maanden dieper in de intensieve samenwerking met AI gestort dan de “autocomplete” waar we al aan gewend waren. En ik vind het een fascinerend leerzame ervaring.

Want Generatieve AI is echt geweldig:

✅ De demos zijn imposant en worden (nog steeds) indrukwekkender
✅ AI produceert in seconden de code waar ik zelf dagen over zou doen
✅ De parate kennis van “best practices”, APIs en architectuur is overweldigend

Maar aan de andere kant:

❌ Als ik zelf geen richting geef aan de software architectuur wordt het snel chaos
❌ AI heeft de neiging om functionaliteit kapot te maken door meer te wijzigen dan gevraagd
❌ Regelmatig ontstaan oplossingen die niet werken en/of niet werkend te krijgen zijn

De huidige AI lijkt hiermee op een “met lof” afgestudeerde schoolverlater die zijn eerste werkgever wil laten zien wat hij/zij kan door even “de oplossing voor alles” te bouwen. – Een project wat natuurlijk gedoemd is te falen.

💡 Omdat AI getraind is op kant-en-klare code zonder het proces te ervaren hoe deze is ontstaan, is het vrij logisch dat dit ook het gedrag van Generatieve AI is. Mijn hypothese is dat AI daarom voorlopig nog niet zonder gedetailleerde menselijke sturing kan om de enorme kennis en kunde van dit gereedschap in goede banen te leiden.

Zelf experimenteer ik inmiddels met deze aanpak om die sturing te geven:

1️⃣ Geef altijd goed doordachte en gedetailleerde prompts
2️⃣ Begin telkens met het laten maken van een leeg(!) raamwerk
3️⃣ Voeg daarna pas incrementeel de features en testen toe
4️⃣ Refactor op basis van de inzichten die de groeiende code brengt
5️⃣ Neem niet de volgende stap voor de vorige compleet is afgerond

Of oplossen van gebruikersproblemen? 💣

Wat er wel of niet door mag gaan voor “Agile” blijft een fascinerende discussie die telkens weer oplaait. Wanneer voldoe je werkelijk aan Scrum? Is het Agile Manifesto nog wel wel van deze tijd? Is SAFe wel zo’n een goed idee? Etcetera, etcetera … ⛈

➡️ Mijn observatie is dat het meestal gewoon gaat over een variant van de natuurlijke spanning tussen problemen van gebruikers versus planning voor het realiseren van een oplossing.

Dit is niet iets nieuws, want deze spanning bestaat al zo lang als ik me kan heugen. Ooit gingen we dit fixen door nog betere specificaties te schrijven (=probleem kant), en daarna gingen we massaal werken volgens Lean principes (=planning kant).

💡 De werkelijkheid is dat het ene niet zonder het andere kan, en beiden vooral met elkaar in balans moeten zijn. Dat is wat Agile werkelijk probeert te brengen: Het faciliteren van “flow” in de feedback lus tussen het probleem en de oplossing.

Bedenk dus de volgende keer dat er weer “Chinees” op het JIRA bord staat welke kant dit keer onrecht aan is gedaan, en werk aan het herstellen van die balans. 🚀

PS: Toevallig ben ik beschikbaar om uw team te versterken met deze en vele andere inzichten. Neem gerust contact op om te bekijken hoe ik uw team technisch en/of mentaal vooruit kan helpen. ☕️

#Agile #SoftwareDevelopment #FutureOfWork #Software101

Soms ligt een betere oplossing voor de hand

Niet zo lang geleden heb ik met een klein team een webapplicatie gebouwd waarin meerdere gebruikers in grote installatie-tekeningen tegelijk wijzigingen kunnen maken.

De naïeve oplossing was om bij het opslaan “gewoon” de data samen te voegen, of anders telkens voor één gebruiker wijzigingen toe te staan. Beiden zijn een gevolg van denken in een “desktop” paradigma in plaats van de mogelijkheden van het web.💩

🌈 Mijn alternatieve oplossing was om CQRS te combineren met een Black Board repository in de cloud. Hierdoor hoeft elke editor alleen de relevante subset van de data te downloaden, waren validaties volautomatisch in de cloud te realiseren, en werd het beheren van varianten van de tekeningen kinderspel.

Dit werkte technisch zo goed, dat de Product Owner moeite had om te beseffen welke “onmogelijke” wensen van gebruikers hierdoor werden ontsloten. 🚀

💡Moderne software bestaat niet meer uit het toepassen van oude patronen. Gebruikers verwachten steeds meer, en de kunst is om oplossingen te vinden voor de werkelijke behoeften van gebruikers.