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. 🏃‍♂️

En waarom planning en budget dan niet hetzelfde is.

In de software wereld blijft het traditie om te vragen naar nauwkeurige schattingen, terwijl we nog geen flauw idee hebben hoe we het gaan maken en dus hoeveel werk het zou kunnen zijn. 🤷

Hieruit ontstaat telkens weer het spelletje waarin om de hete brij heen wordt gedraaid tot er een getal is bedacht waar management gelukkig mee is, maar in werkelijkheid niemand achter staat. En dat is jammer, want dat getal wordt wel gebruikt om de organisatie te besturen en medewerkers op af te rekenen. Het is daarmee een garantie voor doorlopende teleurstelling. 😕

Maar stel je het alternatieve scenario voor: Er wordt een richting afgesproken, en er wordt dagelijks gewerkt aan wat direct zichtbare voortgang in de afgesproken richting brengt. Het management kan aan die richting vervolgens een harde doelstelling hangen in de vorm van een deadline op basis van business criteria, zoals een beurs of het beschikbare budget. 🎯

Als iedereen op basis hiervan beseft waar we heen willen en wat de beperkingen zijn, en vervolgens af wordt gerekend op de voortgang naar het gestelde doel, dan ontstaan er veel realistischere plannen en kan het management tijdig de verwachtingen bijsturen als de harde werkelijkheid niet met de wollige dromen overeen blijkt te stemmen. ⛅️

Mijn persoonlijke ervaring is dat deze manier van werken veel meer motiveert, en daardoor verrassend vaak extreem veel betere resultaten levert. Zo bouwden we met een klein team een slimme data backend in acht weken als vervanging van een gedrocht waar eerder negen maanden met een groot team aan was ontwikkeld, en bouwden we met zijn drieën in enkele maanden de volledige product roadmap van anderhalf jaar voor een ander bedrijf. 🏎️

Onmogelijk? Ik ben er van overtuigd dat niets onmogelijk is, wanneer de voorwaarden voor doorlopende communicatie en creativiteit maar worden gefaciliteerd.