💡 Wat als ik alleen nog testen schrijf, en rest over laat aan AI?

Ik probeer al jaren netjes volgens TDD te werken: Ik schrijf eerst een (falende) test, schrijf daarna slechts voldoende code om de test te laten slagen, en optimaliseer regelmatig de resulterende code. Zo codeer ik richting het langzaam evoluerende ontwerp dat ik voor ogen heb. Mechanisch, saai, maar wel erg effectief. 🎯

Het (voor mij) fascinerende van deze manier van werken is dat de wijzigingen in resulterende code doorlopend geïmpliceerd worden door mijn testen. En telkens als ik iets “onhandig” optimaliseer, geven mijn testen aan dat ik iets over het hoofd heb gezien. 😇

Maar eigenlijk is het waanzin dat ik dit nog steeds met de hand aan het doen ben, terwijl er in mijn IDE een “slimme” code assistent zit. 🤔

Want stel je deze alternatieve workflow eens voor:

1. Ik schrijf (met hulp van AI) een falende test om het verwachte gedrag en randgevallen te beschrijven, en geef daarna de beurt expliciet aan de AI.
2. De AI implementeert de benodigde minimale code om mijn test te laten slagen.
3. Zodra ik het idee heb dat het daar tijd voor is, laat ik de AI de code helemaal zelfstandig refactoren. (Dit zorgt dat ik als mens kan blijven volgen hoe de implementatie evolueert.)
4. De AI draait doorlopend de bestaande testsuite om te bevestigen dat er ondertussen door de wijzigingen niets stuk is gegaan.

Dit zou wel eens een hoop mentale ruimte kunnen vrijmaken. Want minder schakelen betekent dat ik me meer kan richten op het grotere strategische plaatje en de samenhang van het project. 🌴☀️

Bestaat er al een code assistent die die dit kan? En zou dit de productiviteit merkbaar vergroten?

Veel ontwikkelaars denken bij Free Open Source Software nog steeds aan iets wat je gratis kunt gebruiken. Maar “Free” gaat in deze context niet over de prijs, maar over vrijheid. Vrijheid om de software aan te passen, te delen en te verbeteren. En hoewel Open Source Software vaak zonder kosten beschikbaar is, betekent dat niet dat er geen kosten aan verbonden zijn.

Open source projecten vereisen voortdurend onderhoud en ontwikkeling. Dat is waar een groeiende verantwoordelijkheid ligt voor degenen die van deze software profiteren. Als gebruikers en bedrijven die open source omarmen geen steun bieden, kunnen de gevolgen op termijn groot zijn:

• Veiligheidsrisico’s: Niet-onderhouden software kan kwetsbaarheden bevatten die hackers kunnen misbruiken. (Hackers bieden nu al op het overnemen van onderhoud op populaire code.)
• Langzamere innovatie: Zonder voldoende middelen stopt de ontwikkeling en blijft de software achter. Er zijn immers grenzen aan hoeveel avonduren de auteur(s) beschikbaar hebben.
• Uitval van kritieke systemen: Veel infrastructuur en services draaien op open source projecten; als deze stagneren, kan dat grote verstoringen veroorzaken.

De vraag is dus: Hoe kunnen we de open source gemeenschap beter steunen? Denk aan financiële bijdragen aan projecten, of door zelf tijd te besteden aan het verbeteren van Open Source Software.

Krijgen ze nog de kans om ervaring op te doen?

In de afgelopen decennia is de vraag naar software gigantisch gestegen. Dit heeft geleid tot een steeds schevere verhouding tussen het aantal nieuwe en de inmiddels heel kleine groep (zeer) ervaren softwareontwikkelaars.

Nu komt AI om de hoek kijken: Tools zoals GitHub Copilot en Cursor AI nemen steeds meer routinetaken over, waardoor junior developers minder de kans krijgen om door ervaring te leren. Het risico? Een hele generatie ontwikkelaars die wel snel productief is, maar niet genoeg diepgang opbouwt om op eigen kracht senior te worden.

Wat kunnen we doen?

1. AI slim inzetten, niet als vervanging maar als leerhulp.
2. Senior developers beter waarderen en meer betrekken bij het opleiden van de volgende generatie.

Zonder het beheersen van deze balans dreigt de techsector een tekort aan écht ervaren talent te krijgen. Laten we ervoor zorgen dat de toekomst van softwareontwikkeling duurzaam blijft!

In softwareontwikkeling kan het verleidelijk zijn om te wachten tot een product “perfect” is voordat je het lanceert. Maar in plaats van te streven naar één grote lancering, kan het uitbrengen van kleinere, iteratieve en incrementele updates veel voordelen opleveren.

Hier zijn drie redenen waarom kleine releases de betere aanpak zijn:

1️⃣ Snellere feedback: Door vroeg te releasen, kun je direct feedback van gebruikers ontvangen. Dit stelt je in staat om snel te reageren op problemen, verbeteringen door te voeren en je product te finetunen op basis van echte gebruikerservaringen.

2️⃣ Lagere risico’s: Bij grote releases kunnen onverwachte problemen zich opstapelen. Kleine releases beperken de impact van mogelijke fouten, waardoor ze sneller en makkelijker op te lossen zijn. Dit vermindert de risico’s van grote bugs of crashes.

3️⃣ Continue waarde voor gebruikers: In plaats van lang te wachten op nieuwe functies, krijgen gebruikers continu waardevolle updates. Dit houdt hen betrokken en vergroot de kans dat ze loyaal blijven aan je product.

🎯 Iteratie boven perfectie! Door in kleine stapjes te releasen, bouw je sneller, leer je sneller en lever je consistente waarde. Het is niet alleen goed voor de ontwikkeling, maar ook voor het vertrouwen van gebruikers.

Waarom het afsnijden van bochten bij ontwikkeling van software geen verstandige keuze is.

In de wereld van softwareontwikkeling blijft het verleidelijk om snelle oplossingen te kiezen of stappen over te slaan om tijd te besparen. Maar, hoe verleidelijk het ook kan zijn om bochten af te snijden, deze efficiëntie brengt vaak meer schade dan voordeel met zich mee.

Hier zijn drie redenen waarom het niet slim is om shortcuts te nemen in het ontwikkelproces:

1️⃣ Kwaliteit gaat verloren: Door stappen over te slaan, zoals testen of documentatie, introduceer je verborgen risico’s en fouten in de code. Dit kan leiden tot bugs die achteraf moeilijker op te lossen zijn dan wanneer er vanaf het begin meer tijd was genomen voor zorgvuldigheid.

2️⃣ Kosten op lange termijn: Een binnendoor weg kan er nu efficiënt uitzien, maar fouten die ontstaan door “slimme” oplossingen zorgen later vaak voor dure reparaties. Het achteraf herstellen van “technical debt” kost in praktijk veel meer dan het investeren in een solide basis.

3️⃣ Minder vertrouwen en samenwerking: Een cultuur waarin shortcuts worden gepromoot, kan teams demotiveren. Iedereen wil trots zijn op zijn werk. Bochten afsnijden kan leiden tot onduidelijke code en frustratie, wat het vertrouwen in het team ondermijnt.

🚀 Bouw met visie voor de lange termijn! Verkies kwaliteit en robuustheid in kleine stappen boven snelheid in het gehaast naar buiten duwen van een grote stap. Goede software ontwikkeling is meer een marathon dan een sprint. 🏃‍♂️