Na 25 jaar intensief betrokken te zijn geweest bij het mooie vak van Software ontwikkeling leek het me wel eens handig om op papier te zetten waarom het zo’n moeilijk vak is. Heel vaak, eigenlijk bijna altijd, krijg je de vraag van een klant hoe het toch komt dat je nooit een project op kunt leveren zonder bugs en binnen de tijd en het budget. Er zijn een paar artikelen hierover op het Internet, en ze komen altijd op hetzelfde neer. In deze post zal ik proberen, via een 6-tal punten, aan te geven waarom dit is.
In de dagelijkse praktijk gebruik ik deze analogie continu. Je moet ook wel, want het vak software ontwikkeling is doorspekt met jargon. Als je een huis gaat bouwen dan is het eerste wat je doet, kijken hoeveel het ongeveer mag kosten. Je hebt een globaal budget, en diep in je hart heb je er al 10% bovenop gezet, omdat je weet dat er zaken zijn waar je niet zeker van bent. Wil je een luxe keuken? Hoe belangrijk is een ligbad in alle badkamers, Een mooie tuin kost ook geld, etc. Met dit budget ga je naar een architect. Samen met de architect ga je op papier zetten wat je wensen en eisen zijn. Niet alleen betreffende te gebruiken materialen, maar je gaat ook nadenken over het toekomstige gebruik. Komen er meer kinderen? Zorg ik er voor dat ik tot op late leeftijd in het huis kan wonen? Kortom, je definieert samen met de architect een heel pakket van eisen. De architect gaat aan de slag, en tekent een eerste schets. We weten op dat moment al dat we moeten betalen voor de architect. De architect weet het budget al, en via standaard tabellen kan hij al een indicatie geven van de kosten. Doordat je tekeningen hebt, en tegenwoordig zelfs 3D modellen, is het voor de opdrachtgever heel gemakkelijk om zich een voorstelling te maken over wat hij gaat krijgen. Als de opdrachtgever en architect in overeenstemming zijn, dan maakt de architect een zogenaamd bestek, waarin alle werkzaamheden zijn uitgeschreven, vierkante meters tegels, muren, dakpannen, hoeveelheid kozijnen, soort glas, waterleiding plan, elektriciteit plan, kortom, een groot boekwerk met alle details van alle werkzaamheden. De opdrachtgever kan deze ook lezen, en begrijpen, want het is iets wat hij kent.
De opdrachtgever weet ook, dat als hij later dingen wil veranderen, hem dat geld gaat kosten, immers, hij weet wat hij eerst heeft gevraagd, en hij snapt dat als het anders moet, dat dit vaak meer werk is. Het is voor een aannemer ook vaak gemakkelijk uit te leggen, en de aannemer zorgt er ook voor dat dit in het contract staat wat hij met de opdrachtgever afsluit.
Iedereen snapt bovenstaand verhaal, maar op het moment dat je dezelfde methodiek voor software wilt hanteren, geeft een opdrachtgever niet thuis. Hij weet gewoon niet hoe hij moet beschrijven wat hij wil, hij kan niet aangeven waarmee het gebouwd moet worden, hij kan zich geen voorstelling maken van het eindresultaat, anders dan de 10% die zichtbaar is voor een eindgebruiker. In het beginstadium van een project worden er dus al totaal verkeerde aannames gedaan, men begint liever direct met bouwen, want dan spaar je de kosten uit voor een gedegen ontwerp en bestek, wat toch niet wordt begrepen door de opdrachtgever.
Elk nieuw maatwerk project bestaat uit unieke regels code. In de software industrie bestaan wel zogenaamde “Frameworks”, zeg maar legodozen met standaard componenten, maar deze moeten altijd nog aan elkaar worden geprogrammeerd. Als je 10.000 regels code hebt, dan heb je ook direct 10.000 “points of failure”. Verder werken groepen regels samen met andere regels, waardoor de complexiteit, met name van het testen, exponentieel toeneemt. Om dit allemaal goed te testen heb je eigenlijk een goed testteam nodig van professionele testers, een gedegen testplan, en grote sets van test scenario’s. Hier is eigenlijk nooit budget voor, behalve dan voor de zeer kritische software systemen. We vertrouwen dus maar op de “gebruikers” om de code te testen, en we lossen pas problemen op als ze ontdekt worden door gebruikers.
Heel veel software systemen worden bedacht door speciale consultants, aangestuurd door het management. Zij hebben de specificaties geschreven, hebben hiervoor budget gekregen, en begeleiden vaak de bouw. We zien helaas maar al te vaak dat deze consultants het jargon van software development goed beheersen, maar dat ze veel te weinig kennis hebben van de dagelijkse gang van zaken rondom de bedrijfsprocessen waarvoor de software wordt gemaakt. Heel vaak zien eindgebruikers de software als een bedreiging voor hun eigen werk, en nog vaker zullen zij ervaren dat heel erg veel uitzonderingen, die voor een eindgebruiker evident zijn, totaal niet zijn meegenomen in het ontwerp. Hierdoor ontstaat er een (terechte) aversie vanuit de eindgebruikers, waardoor implementatie en testen moeilijk en tijdrovend wordt.
I know it when I see it
Zoals al bij punt 1 aangegeven, is het voor een gebruiker heel erg moeilijk zich een voorstelling te maken hoe het nieuwe system hem gaat helpen bij zijn werk. Pas als hij het daadwerkelijk ziet, en er daadwerkelijk mee aan de slag gaat, wordt dit duidelijk. Pas dan gaat een gebruiker echt nadenken over wat het systeem eigenlijk zou moeten doen om een goed stuk gereedschap voor die gebruiker te worden. Er volgen wijzigingsvoorstellen, die vaak voor een gebruiker zeer logisch zijn, maar voor een software ontwikkelaar een nachtmerrie blijken te zijn. Een op het oog kleine wijziging kan een zeer grote verbouwing van de software betekenen. Zie het maar als die opdrachtgever van dat huis, die, als de aannemer met het dak bezig is, er achter komt dat hij toch wel heel graag een wijnkelder wil in het huis, het is toch maar een kleine ruimte? Iedereen snapt direct dat om dit te realiseren er zeer grote kosten gemaakt moeten worden. Voor software is dit vaak niet evident voor de klant.
In elk vakgebied heb je vaklui en talenten. Omdat programmeren een combinatie is van beiden, zijn er zeer grote verschillen tussen programmeurs. Allereerst kennen we de 10.000 uur regel. Deze regel is gebaseerd op wetenschappelijk onderzoek, waarin wordt betoogd dat als je goed wil worden in een vak, je minimaal 10.000 uur moet investeren in dit vak. Dit komt neer op bijna 6,5 jaar. Daarnaast moet je talent hebben. Volgens mij betekent talent voor een belangrijk deel dat je zoveel van een vak houdt dat je bereid bent jezelf daar aan te wijden, op een bijna obsessieve manier. Niet iedereen kan, en wil dit opbrengen. De productiviteit tussen programmeurs kan daarom erg verschillen, soms wel met een factor 20! De oplossing zou dus simpel moeten zijn, huur alleen maar hele goede programmeurs. Dit is helaas niet gemakkelijk, ze zijn dun gezaaid, en als ze al werk hebben waar ze hun talenten kunnen botvieren, zijn ze niet snel geneigd om over te stappen naar een onzeker nieuw project.
Het is zo goed als onmogelijk om alle invloeden van externe factoren goed in te schatten. Stel je moet een complexe portal bouwen die benaderbaar moet zijn via een webbrowser. Er zijn nog steeds bedrijven die met Internet Explorer 6 werken! We hebben zeker 4 versies van Internet Explorer, meerdere versies van Firefox, Chrome en Safari, we hebben Opera, en nog een dozijn andere exotische browsers. We hebben Browsers voor telefoons, voor tablets, voor phablets, voor PC’s voor laptops, etc. Verder worden de browsers regelmatig voorzien van nieuwe functies en updates, om dit allemaal in de gaten te houden heb je alleen al een team nodig. Je hoopt altijd dat de ontwikkelaars van al deze browsers en systemen rekening houden met oudere software die moet werken binnen hun browsers, dat ze zich aan standaarden houden, maar dit is bijna nooit het geval, waardoor het risico dat de software die je aan het bouwen bent, of net hebt geleverd, plots niet meer werkt. Jouw software heeft dan ineens “bugs”, terwijl het eigenlijk de browsers of systemen zijn die niet “backwards compatible” zijn.
Als je begint aan een nieuw project wil je 9 van de 10 keer ook de nieuwste software en de nieuwste technieken gebruiken. Je moet ook wel, want het systeem waarop je software komt te draaien is vaak nieuw, de apparaten waarmee je software wordt benaderd zijn tegenwoordig altijd automatisch up-to-date, en er is geen klant ter wereld die zal zeggen, gebruik maar Cobol, want dat is “proven technology”.
Juist omdat je dus te maken krijgt met de nieuwste tools, en de nieuwste omgevingen, is het zeer moeilijk, zo niet onmogelijk, om een accurate schatting van de tijd en de kosten af te geven. Het is dan geen wetenschap meer, maar een kunstvorm. Alleen als je al tientallen projecten hebt gedaan, je het ontwikkelteam door en door kent, is het mogelijk om een “best educated guess” af te geven. Mijn ervaring is dat je dan eigenlijk vaak nog tussen de 15 en 45% marge nodig hebt. Kom daar maar eens om bij het bouwen van een huis!
Het bouwen van software is nog steeds een ambacht dat in de kinderschoenen staat. We bouwen al duizenden jaren huizen, maar pas 25 jaar software op grote schaal. De ontwikkelingen gaan zo razendsnel en de complexiteit neemt zo sterk toe, dat het goed begroten van een project eigenlijk ondoenlijk is. Ook al gebruik je technieken als “Agile” en “Scrum”, je moet er vanuit gaan dat de kans dat een project binnen tijd, binnen specificaties en binnen budget wordt opgeleverd ongeveer 4% is. De enige manier om de kosten en de tijd in de hand te houden is voor de ontwikkelaar om volledige transparantie te betrachten gedurende het hele bouwproces, en continu aan te geven waarom er vertraging optreedt. Voor de klant is het essentieel om samen met de ontwikkelaars intensief op te trekken. De klant zal, of hij het wil of niet, mee moeten in de complexiteit van het ontwikkeltraject, en zal continu keuzes moeten maken die zowel de prijs als de opleverdatum zullen beïnvloeden. Pas als je als een team samenwerkt met de klant, oog en oor hebt voor elkaars doelstellingen en uitdagingen, dan pas zijn de juiste voorwaarden geschapen voor een succesvol software project.
