In de goeie oude tijd kon je software nog lekker in elkaar rommelen. Letterlijk. Software was buggie (vol met fouten), crashte regelmatig (herinnert u zich het vastlopen van Windows) en onveilig (ik noem hackers die creditcardgegevens zomaar op straat gooien). De software-industrie is zich tegenwoordig bewust van de verantwoordelijkheid die zij heeft. De lat ligt hoog, kwalitatief goede software is de norm.

Veel van de problemen met ‘slechte’ software ontstonden vanuit gebrekkige planningen. Klanten staan te dringen om nieuwe functionaliteit per direct beschikbaar te hebben, tegen de laagst mogelijke kosten. Ontwikkelaars voelden de hete adem in de nek en onder druk van deze en gene gaven ze onrealistische planningen af. Als slagroom op de taart volgende vaak ook nog eens onderhandelingen of de planning niet toch nog een stukje strakker kan. Ondertussen weten we beter.

De snelste manier naar een goede planning, is te vertrouwen op inschattingen van ontwikkelaars. Over het algemeen zijn dit loyale mannen die echt wel hun best doen om iets goed neer te zetten. Historisch gezien kunnen we stellen dat schattingen eerder te optimistisch zijn, dan te conservatief. Onderhandelen met ontwikkelaars is tegenwoordig uit den boze. Hierdoor hebben ontwikkelaars meer ruimte gekregen om hun werk in één keer goed te doen en tools in gebruik te nemen die helpen bij het bewaken van de kwaliteit.

De eisen die de gemiddelde ontwikkelaar stelt aan geschreven code zijn hoog. Even snel iets in elkaar flansen gaat echt niet meer. Softwarebouwers realiseren zich dat het ontwikkelen van goede software tijd kost. Men onderhandelt niet met de klant. Sterker, de balans is doorgeslagen. De opdrachtgever wordt geacht met duidelijke specificaties te komen. Er wordt geen code geschreven voordat duidelijk is wat de bedoeling is. De ontwikkelaar heeft tegenwoordig simpelweg geen zin meer om iets te bouwen wat later niet de bedoeling blijkt te zijn.

In zekere zin heeft de R&D afdeling een bastion voor zichzelf gebouwd en legt zij de verantwoordelijkheid bij haar klant. Echter, er wordt ook kritisch naar de eigen prestatie gekeken. Aanpassing en toevoegingen van functionaliteit moeten passen binnen de softwarearchitectuur. Nieuwe programmacode wordt getoetst door een hele batterij geautomatiseerde testscenario’s. Die dienen bij iedere wijziging opnieuw groen licht te geven. En dit zijn slechts enkele voorbeelden. Het gebruik van allerlei gespecialiseerde tools is gemeengoed. Denk aan moderne ontwikkelstraten met buildservers die en-passant diverse kengetallen meten, van code coverage tot cyclomatic complexity.

Mocht de software in kwestie een product zijn dat door velen gebruikt wordt, dan zijn de eisen nog hoger. Niet alleen moeten de specificaties duidelijk zijn. De nieuwe wensen moet functioneel passen in het product. En het moet door veel mensen makkelijk te leren en eenvoudig in gebruik zijn. Tot slot is het fijn als de documentatie en trainingsmateriaal wordt bijgewerkt, en alle gebruikers op de hoogte worden gesteld. Je kunt gerust stellen dat functies die in de jaren negentig in de ban gingen, zoals functioneel ontwerper en documentatieschrijver, nu hip en retro zijn.

Dit alles betekend dat softwareontwikkeling robuuster, en ook minder flexibel is geworden. Paradoxaal genoeg zijn de kosten gedaald. Dit komt doordat er minder fouten optreden en ontwikkelaars minder tijd besteden aan het oplossen van problemen – één van de duurste onderdelen van softwareontwikkeling. Softwaregebruikers zijn daardoor in de loop der tijd meer tevreden geworden over software. Software is beter en goedkoper. Maar inderdaad: nieuwe functionaliteit kost wel meer moeite. Ach, je moet iets te klagen houden.