Ondanks alle inspanningen om software-ontwikkeling te verbeteren met nieuwe methodologieën en tools, lopen projecten helaas nog vaak vertraging op door bureaucratie, nieuwe eisen en de aard van de code. Douglas Hofstadter, van oudsher computerprogrammeur en auteur van Gödel, Escher, Bach, vatte zijn ervaring in de computerloopgraven samen op CIO.com: het duurt altijd langer dan je verwacht, ook als je rekening houdt met de ‘Wet van Hofstadter’. In dit artikel leggen we je uit waarom jouw software project vertraging oploopt. 

Software projecten lopen eigenlijk altijd vertraging op, maar toch blijven organisaties, belanghebbenden en projectmanagers deadlines stellen. Zelfs de programmeurs zelf doen dit. Gaat de Wet van Hofstadter meer op voor programmeurs, die in eerste hand met de software te maken krijgen, of met projectmanagers die iedereen door het traject moeten loodsen? Projectmanagers vertrouwen erop dat een API zo’n twee maanden werk bespaart, maar het is de ontwikkelaar die erachter komt dat de API 129 opties heeft, behalve degene die het bedrijf nodig heeft.  Code bouwen is moeilijk, maar het managen van acht programmeurs die worstelen met bugs die de code verstoren is dat ook.

Van buitenaf trommelen de projectsponsors ongeduldig met hun vingers op de tafels van de vergaderzaal, terwijl directie en projectmanagers toekijken hoe programmeurs verwoed aan het peddelen zijn en nergens naartoe gaan. De programmeurs zien op hun beurt alleen maar taskmasters die niet begrijpen hoe sterk de stroming is.

Lang geleden probeerde iemand wetenschappelijk te zijn over het meten van productiviteit en het tellen van coderegels. Fredrick Brooks dreef die theorie uiteen in 1975 met The Mythical Man-Month, een boek dat duidelijk maakte dat al die wiskundige modellen en aannames van lineaire vooruitgang gewoon niet van toepassing zijn.

Sindsdien zijn de doornstruiken langs de weg naar projectrealisatie alleen maar dikker geworden. Slimme ideeën die tijdelijk werken aan een lokaal probleem, maar die alles uiteindelijk complexer en complexer maken zijn het probleem. Klanten, stakeholders en aandeelhouders vragen allemaal meer en meer, maar meer zal alleen maar langer duren.

Hier zijn 10 redenen waarom softwareprojecten langer duren dan verwacht, ondanks nieuwe tools en technieken die bedoeld zijn om de levering van software te versnellen. Deze redenen kunnen niet elke vertraging verklaren, maar ze kunnen managers wel helpen begrijpen waar alle coderingsinspanningen naartoe gaan.

1. Scope creep

Het softwareteam heeft maanden geleden een project gelanceerd, maar de omvang & output zijn zo veranderd dat je eigenlijk net zo goed de naam van het project kunt veranderen. Het overkoepelende doel blijft misschien hetzelfde, maar iemand heeft de architectuur zodanig veranderd dat alles opnieuw moet worden opgebouwd.

Misschien is het niet eerlijk om het te zien als een project dat langer duurt dan verwacht – maar meer dat het eerste project een tijdje terug “eindigde” en een compleet nieuw project is gelanceerd, onder dezelfde naam en zonder de gebruikelijke projectlanceringsfanfare. In feite kan er een paar andere projecten “afgerond” zijn geweest in de tussenliggende maanden, en dus zou een nauwkeurige boekhouding niet aangeven dat je ene project veel meer tijd heeft gekost dan oorspronkelijk gepland, maar dat je ontwikkelaars die tijd hebben besteed aan vele verschillende projecten met dezelfde naam.

2. Besprekingen

Software ontwikkelaars grijnzen nog wel eens over de open kantoren en het gebrek aan geïsoleerde werkkamertjes. Toch lijkt het of er te weinig uren in een dag zitten om alles te bespreken wat er nodig is in een software design. Zo lijkt het bijna alsof we het bespreken van de aanpak leuker vinden dan het werk ook echt afmaken.

Soms is het bijna lachwekkend hoeveel tijd we besteden aan meetings en besprekingen over hoe we het schema het beste kunnen structureren. De waarheid is echter dat voor de meest eenvoudige projecten software gebouwd moet worden die nog erg nieuw is. Coderen duurt nu eenmaal langer dan een weg aanleggen. De software moet telkens opnieuw geoptimaliseerd worden omdat dit nog niet veel vaker gedaan is – zeker niet met deze specificaties voor deze systemen en bedrijfsbehoeften.

3. Behendigheid heeft zo zijn beperkingen

Voor managers is het proces het belangrijkste. Om te zorgen dat een project tempo houdt zullen managers gebruik maken van kaders en methodologieën. Software project managers discussiëren graag over wat de beste manier van werken is, maar uiteindelijk heeft iedere methode zijn eigen beperkingen. Kaders zijn slechts richtlijnen. Ten slotte is het werk in theorie (bijna) altijd anders dan in de praktijk, wat ervoor zorgt dat we om moeten gaan met uitzonderingen terwijl de deadline steeds dichterbij komt.

Ontwikkelaars werken het liefst met vrijheid zodat zij zelf kunnen kiezen waar ze een bijdrage leveren. Deze vrijheid kan zonder leidinggevende wel resulteren in chaos. Programmeurs moeten zich niet al te druk maken over hun werk, wanneer er een code niet goed werkt kan deze altijd gefixt worden door een nieuwe code. Zo krijgen programmeurs vaak ook weer extra waardering omdat het lijkt alsof ze extra werk verricht hebben.

4. Niemand kan alles voorzien

Ontwikkelaars moeten systemen maken die tot wel honderden gemeenschappen samen laten komen. Daarbij is het haast onmogelijk om ieders belangen te onthouden en verwerken. Dus gokken programmeurs vaak op een abstracte basis, proberen ze details te creëren en gebruik te maken van herhalingen in codes om te hopen op de beste uitkomst. Alles weer op orde brengen zal altijd tijd kosten, omdat er zoveel details zijn om rekening mee te houden.

5. Stakeholders kunnen zich bedenken

Je zou denken dat software ontwikkelaars hun eigen tempo beheren, maar vaak werken ze met verschuivende deadlines. Het is daarom ook niet eerlijk om de programmeurs de schuld te geven van veranderingen die gevraagd worden door klanten en belanghebbenden in het project. Deze laatste hebben telkens nieuwe verzoeken met betrekking tot verandering en verbetering van het project.

6. Data structuren zijn stug

Een van de grootste uitdagingen van een programmeur is het maken van data modellen en zorgen dat de databases de informatie volledig en accuraat opslaan. Aan de ene kant willen we dat data modellen strikt zijn, zo houden we bijvoorbeeld logica in onze postcodes: vier cijfers en twee letters. Aan de andere kant willen we dat deze modellen flexibel zijn zodat we ook postcodes kunnen registreren die alleen uit cijfers bestaan of een andere combinatie van cijfers en letters dan die van onszelf. Het aanpassing van deze modellen zal tijd kosten.

We hebben structuur nodig om deze modellen te laten werken, maar veranderingen in de structuur kunnen er ook voor zorgen dat de structuur ongeldig wordt. Het is een steeds terugkerend dilemma.

7. Onwaarheden bestaan

Sommige programmeurs verzamelen simpele statements die waar lijken tot je ze in een code verwerkt. Een voorbeeld hiervan is het statement dat “een dag bestaat uit 24 uur”. Op het eerste opzicht is dit inderdaad waar, echter hebben we twee keer per jaar te maken met het verzetten van de klok. Dit betekent dat er een dag in de zomer is die maar 23 uur duurt, terwijl in de winter een dag  is die 25 uur duurt.

In ieder project kom je enkele van deze onwaarheden tegen. Je kunt dan alleen maar hopen dat ze niet te moeilijk zijn op te lossen en dat gebruikers niet te ontdaan raken door deze inconsistenties.

 8. Complexiteit is zelden goed

Programmeurs willen hun systemen graag gestroomlijnd hebben. Stakeholders en gebruikers willen juist graag “verbetering” van de systemen door extra functies toe te voegen die de bedrijfswaarden na streven. Extra functies zijn leuk, maar extra functies betekenen ook dat er extra logica en vaak complexiteit bij komt kijken.

Natuurlijk zijn sommige functies redelijk makkelijk toe te voegen, maar andere functies kunnen er weer voor zorgen dat en onbedoelde gevolgen ontstaan waar je op moet anticiperen terwijl je dit vooraf waarschijnlijk niet gepland had. Dus wees voorzichtig met het toevoegen van extra codes of extra kolommen in je database. Voor je het weet wordt je project nog complexer en ben je nog verder van de deadline dan je had geacht.

 9. Beoordelingen van het ontwerpen zorgen voor functie creep

Het beoordelen van het design is erg belangrijk in het ontwerp proces. Iedereen wil namelijk dat zijn of haar software programma meer kan doen en zal daarom meer functies toevoegen in de hoop een betere beoordeling te krijgen. Soms is het mogelijk om verzoeken af te wijzen van beoordelaars die niets te maken hebben met de strekking van het project. Helaas zijn er veel verzoeken die onschadelijk overkomen, maar een grote mate van hercodering vergen. Het kan soms wel een paar uur duren om uit te vinden of dit verzoek een makkelijke or een lastige is.

Beoordelingen van projecten door stakeholders zullen echter blijven bestaan, het is een belangrijk onderdeel van een goed ontwikkelproces. Dus sullen programmeurs bezig blijven met het uitvinden wat er van hun codes beter bij versie 2.0 of misschien wel 5.0 past.

10. Langzamer is beter

Een langzame vooruitgang van een project kan zorgen voor veel ergernissen. Een project haastig afmaken is toch ook geen goed idee. Je zult gegarandeerd gebreken en defecten tegenkomen wanneer je dit wel doet. Wanneer je als programmeur je tijd neemt om het project op te zetten dan is de kans veel groter dat het logisch en goed in elkaar zit. De tussentijdse beoordeling zal waarschijnlijk nog beter zijn ook! Zeuren over het tempo van programmeurs heeft dus geen enkele zin, het zal alleen maar afleiden van het werk waardoor het project er vaak slechter uitkomt. Dus: laat je software ontwikkelaar gewoon zijn ding doen!