Vijf mythes over softwareontwikkeling ontkracht
Door Joost Landgraf
CTO bij CoolProfs
Ondanks dat het niet bepaald een mysterieus vak is, bestaan er toch een aantal hardnekkige misvattingen over softwareontwikkeling.
Ergens is dat niet vreemd, gezien wat de IT-industrie allemaal heeft bereikt in de afgelopen decennia. Het lijkt haast bovennatuurlijk vergeleken met andere beroepsgroepen.
Maar we moeten onszelf niet gek maken, de dagelijkse praktijk van softwareontwikkeling is niet zo wonderbaarlijk als het soms lijkt. We nemen vijf development-mythes onder de loep.
1. En ze leefden nog lang en gelukkig
Het is mens eigen om het leven te zien als een reeks verhalen met een begin, een midden en een einde. Dat geldt ook voor softwareprojecten. Mensen die erbij betrokken zijn, hebben de neiging te denken dat hun softwareontwikkelingsproject op een dag zal eindigen. Dat ze een soort eindstreep zullen bereiken, een medaille ontvangen en zonder omkijken verder gaan met hun leven. Als je dit gelooft, kun je net zo goed geloven in sprookjes.
In een enkel geval zal het misschien kloppen, maar het overgrote deel van de softwareontwikkelingstrajecten blijft eindeloos evolueren en veranderen. Dit is niet iets slechts; het is gewoon natuurlijk. Logisch zelfs.
Ga maar na: niets is perfect. Er zullen altijd elementen zijn in software die verbeterd of veranderd moeten worden omdat ze niet naar je zin zijn, omdat het niet helemaal werkt zoals je had bedacht, of gewoon omdat omstandigheden zijn veranderd.
Omstandigheden zullen altijd veranderen omdat de wereld dat ook doet. IT-systemen die niet mee-veranderen worden gebrekkig, ontoereikend en uiteindelijk overbodig.
Vergelijk een IT-project eens met een tuin. Elk jaar moet je zaailingen planten, dode of zieke struiken verwijderen, bomen snoeien, verse aarde toevoegen, en af en toe het ontwerp aanpassen omdat je een zitgedeelte wilt of omdat je meer zonlicht wilt binnenlaten. Je hóeft al deze dingen niet te doen. Je kunt de natuur ook op zijn beloop laten. Maar als je dat doet, zul je over een paar jaar in plaats van een nette, gezellige tuin een ondoordringbare jungle hebben.
Mensen denken vaak aan software als iets levenloos. Dat is het eigenlijk niet. Het feit dat software voortdurend door mensen wordt gebruikt en aangepast maakt het juist tot iets levends.
2. De vloek van legacy code
Het is de schrik van de IT-afdeling: verouderde code die vernieuwing afremt of tegenhoudt. Weer zo’n mythe. In feite is geen enkele code verouderd, of alle code is verouderd. ‘Legacy’ is gewoon een naam die we hebben verzonnen voor verwaarloosde code die niet goed is onderhouden. In die zin is deze mythe nauw verwant aan de eerste mythe.
Het is belangrijk om in gedachten te houden dat de zogenaamde legacy code op zichzelf niet slecht is. Zie het als de piramides. Ze zijn verouderd en niet meer van nut voor ons, maar ze zijn nog steeds mooi en een bewijs van hun tijd. Ze zijn ontworpen en gebouwd volgens de kennis en technieken van eeuwen geleden. Je kunt ernaar kijken door een 21e-eeuwse bril, maar het enige dat je daarmee doet, is de huidige wijsheid op het verleden projecteren. Hetzelfde geldt voor software. Code is geschreven volgens de kennis en gewoonten van zijn tijd. Software wordt niet gebouwd om eeuwig mee te gaan. Ontwikkelaars uit het verleden konden niet voorspellen wat de software-eisen van deze tijd zouden zijn, net zoals wij geen software kunnen ontwikkelen voor over tien jaar.
3. Het technical debt verschijnsel
Laten we het even hebben over ‘technical debt’. Gekke naam, toch? Als je überhaupt een term voor dit fenomeen nodig hebt, zou het niet ‘technische schuld’ maar ‘technische verwaarlozing’ moeten zijn. Het wordt namelijk veroorzaakt door gebrek aan tijd of budget, of gewoon door simpele luiheid. Maar als je iets kunt creëren, dan kun je het toch ook oplossen? Het is dus geen schuld. Als je niet bereid bent om op dit moment een probleem op te lossen, waarom zou je dat dan later wel doen?
We kennen allemaal de laatste kleine klusjes die gedaan moeten worden na een verhuizing. Die ene lamp die je nog moet ophangen in de schuur, plinten die je moet vastzetten in de logeerkamer, dat soort dingen. Deze klussen kun je meteen doen of in de toekomst, maar het wordt pas een probleem als de situatie onwerkbaar wordt. Bijvoorbeeld als je door het gebrek aan licht in de schuur een fietsband niet kunt repareren. Zou je dit technische schuld noemen? Of gewoon nalatigheid? Hoe dan ook, je kunt er altijd voor kiezen om het op te lossen.
4. De kristallen bol van prognoses
We denken allemaal dat we prognoses kunnen maken, maar dat kunnen we niet. Keer op keer proberen mensen in te schatten hoe lang een IT-project zal duren en ze zitten er altijd naast. Gelukkig zijn er methoden om risico’s te beperken. Een van de redenen waarom Agile überhaupt bestaat, is om eerder in het proces te weten te komen of een project nog op koers ligt.
Software is eigenlijk het tegenovergestelde van het gezegde ‘één beeld zegt meer dan duizend woorden’. In software kan één woord duizend nieuwe problemen, variaties of complexiteiten introduceren. In theorie is één Boolean eenvoudig, maar voor software vertaalt dit zich in exponentieel complexere code en meer testcases. Om de correctheid van één Boolean te bewijzen, heb je twee testcases nodig, voor twee Booleans heb je vier testcases nodig en voor drie Booleans heb je er al acht nodig. Het testen van de juistheid van één eenvoudige functionaliteit groeit net zo had als het beroemde verhaal over de rijst op het schaakbord.
5. Low-code en no-code zijn de held of de schurk
Het blijft me verbazen hoe mensen de neiging hebben om low-code en no-code vanuit een beter/slechter dan-perspectief te bekijken. Naar mijn mening is het gewoon de volgende abstractie, zoals assembly voor bits was, en high-code voor assembly. Het is gewoon de volgende stap in softwareontwikkeling. Het beantwoordt de huidige vraag om het bouwproces te versnellen, onnodig handwerk te elimineren en alles minder abstract en zichtbaarder te maken.
Low-code/no-code heeft softwareontwikkeling veranderd van een mysterieuze ambacht voor experts naar een democratisch proces, precies wat nodig is in deze tijd van snelle en wijdverbreide digitalisering.
Mythes ontkracht?
Laten we allemaal dit soort dwaze mythes rond softwareontwikkeling loslaten en verandering omarmen. Dat betekent niet dat we de redenen waarom deze mythes bestaan uit het oog mogen verliezen. Net zoals sprookjes zijn ze gebaseerd op de realiteit en kunnen we er belangrijke lessen uit trekken.
Software blijft altijd door ontwikkelen. Als we het niet goed onderhouden, wordt het onbeheersbaar. Wij moeten er actief voor zorgen. De wereld verandert iedere dag sneller. Waarom zouden we software en softwareontwikkeling dan niet mee laten evolueren? Juist omdat software, in tegenstelling tot hardware, gemaakt is voor verandering en flexibiliteit.
Het voelt misschien niet zo, maar wat betreft evolutie bevinden wij ons nog in de beginfase van softwareontwikkeling. We hebben nog veel te ontdekken, wat ik persoonlijk beschouw als een van de beste aspecten van ontwikkelaar zijn. Omarm de verandering, omarm de toekomst.
Dit is trouwens door mij zelf geschreven. Niet door een of andere bot.
