De zeven zonden van softwareontwikkeling
In zulke gevallen kan een audit worden uitgevoerd op de applicatie.
Bij een audit wordt de technische kwaliteit van softwaresystemen in kaart gebracht. Tijdens de auditwerkzaamheden blijkt steeds dat zowel ‘de business’ als de ontwikkelteams zondigen tegen een aantal voor de hand liggende managementprincipes. In dit artikel worden de zeven grootste zonden beschreven.
▪ Jaloezie: Het bouwen van eigenontwikkeltools
Het mooiste voor een softwareontwikkelaar is zijn eigen ontwikkeltools bouwen, jaloers als hij is op alomgebruikte, gebruiksvriendelijke tools van bedrijven als bijvoorbeeld Microsoft. Met zelfgebouwde tools kan de programmeur veelvoorkomende problemen op een generieke manier oplossen, waardoor hij zijn werk veel efficiënter kan uitvoeren.
Het zelf bouwen heeft echter nadelen. Ten eerste is het onwaarschijnlijk dat de ontwikkelaars een zodanig uniek en zich herhalend probleem hebben dat daar niet reeds andere tools voor op de markt zijn. Het zelf bouwen van zo’n tool resulteert daarmee in het oplossen van een standaardprobleem op een niet-standaardmanier. Nieuwe medewerkers moeten eerst op cursus om zich de niet-standaardmanier eigen te maken, en kunnen deze kennis nooit bij volgende werkgevers benutten.
Ten tweede kost het zelf bouwen van deze tools ontwikkel- en onderhoudskosten.
Moraal: het management dient te controleren of de gebruikte ontwikkeltools algemeen bekend zijn in de markt. Zelfgebouwde tools kunnen een verspilling van resources betekenen, ingegeven door jaloezie.
▪ Vraatzucht: Het bouwen van de moeder aller systemen
Een bedrijf heeft jaren geleden een softwaresysteem uit laten programmeren dat precies doet wat de business nodig heeft. Door de jaren heen zijn steeds wijzigingen en uitbreidingen doorgevoerd waardoor de architectuur deze wijzigingen steeds meer in de weg zit. Met pijn en moeite wordt de functionaliteit gerealiseerd die de business wenst. Daarom wordt besloten tot de bouw van een nieuw systeem, dat qua architectuur alle ruimte biedt om toekomstige uitbreidingen kosteneffectief door te voeren. Verder heeft ‘de business’ een wensenlijst opgesteld. Als er dan toch een nieuw systeem komt, dan kunnen deze wensen ook meteen worden ingebouwd, waarna het systeem met een big bang gelanceerd kan worden.
Twee jaar na de start blijkt het systeem maar niet af te komen. Omdat het oude en nieuwe systeem inmiddels naast elkaar draaien, heeft de business geleerd om nieuwe change requests toch maar door het ontwikkelteam van het oude systeem uit te laten voeren. Bij dit team weten ze tenminste zeker dat de verandering binnen twee weken is gerealiseerd.
De wensenlijst van de business is vergelijkbaar met een lopend buffet. Bij het opscheppen van gerechten wordt het bord uit vraatzucht helemaal volgeladen. Het probleem met een volgeladen bord is, in softwaretermen, dat het bouwen van anderhalf keer zoveel functionaliteit niet anderhalf keer zoveel werk is, maar eerder acht keer zoveel. Terwijl die extra functionaliteit hoogstwaarschijnlijk niet gebruikt gaat worden. Met andere woorden: uiteindelijk blijkt alleen de aardappelsalade lekker te zijn.
Moraal: begin bij herbouw van een systeem eerst met de bestaande functionaliteit te reproduceren in het nieuwe systeem, en ga daarna live. De stekker kan dan uit het oude systeem worden getrokken. Vervolgens dient de wensenlijst van de business stap voor stap in het nieuwe systeem te worden geïmplementeerd.
▪ Gemakzucht: Complexe functionaliteit complex uitprogrammeren
Met complexe functionaliteit wordt functionaliteit bedoeld die de ontwikkelaars niet helemaal snappen. Deze functionaliteit is meestal onderdeel van het huidige (deels geautomatiseerde) workflowproces binnen de business. Bijvoorbeeld een ingewikkelde spreadsheet om het offertetraject te begeleiden. Omdat binnen het ontwikkelteam niemand precies snapt wat de functionaliteit behelst, wordt uit gemakzucht besloten dat dit zo ingewikkeld is dat dit ook het ingewikkeld uitprogrammeren rechtvaardigt. Wat dan weer onbegrijpelijke code oplevert.
De moraal is dat de ontwikkelaars samen met de business tijd moeten reserveren om elkaar te begrijpen. De code kan worden onderverdeeld in veel kleinere, makkelijk te begrijpen onderdelen en bijbehorende abstractielagen. Deze onderdelen kunnen dan eenduidig door verschillende programmamodules worden aangeroepen. Hierbij dient echter wel te worden gewaakt voor de zonde der wellust (zie verder).
▪ Wellust: Overmodelleren
Moderne programmeertalen bieden de mogelijkheid van abstractie. Kunnen abstraheren is zinvol. Maar hoe wellustig kun je zijn met abstraheren? Héél erg, leert de praktijk.
Onderdeel A van de software wordt volledig geabstraheerd van onderdeel B. Deze mogen van elkaars bestaan niet afweten. Tussen de delen A en B wordt dan ook een abstractielaag gebouwd. Onderdeel C wordt aangestuurd door onderdelen A en B, waarbij onderdeel C niet mag weten of de opdrachten door A of B worden gegeven. Tussen C en de delen A en B wordt ook weer een abstractielaag gebouwd.
Tijdens audits blijkt de neiging tot abstractie nogal eens volledig te zijn doorgeslagen. Tussen het indrukken van de ‘save’-knop in de userinterface en het daadwerkelijk opslaan van de data in de database, roepen rustig vijftig verschillende softwarestukjes elkaar aan. Terwijl het minimumaantal misschien zo’n vier of vijf stukjes is.
Moraal: wellustige overmodellering zorgt ervoor dat systemen traag werken, dat er te veel broncode wordt geschreven en dat uiteindelijk geen enkele ontwikkelaar het systeem meer snapt.
▪ Hoogmoed: Geen geautomatiseerde ontwikkelstraat gebruiken
Moderne ontwikkeltools bieden de mogelijkheid om volledig geautomatiseerd de software vanuit een versiebeheersysteem te compileren, te builden, op codeerstandaarden te testen, op programmeerfouten te controleren enzovoort.
Indien zo’n omgeving eenmaal is opgezet, worden deze controles elke nacht uitgevoerd. Programmeurs ontvangen van het systeem dan ’s ochtends een e-mail, waarin staat of de wijzigingen die zij gisteren hebben doorgevoerd kloppen of niet. De kracht hiervan is dat problemen meteen de volgende dag zichtbaar worden. Teruggaan naar de situatie van gisteren is dan mogelijk, de wijziging in de code die het probleem veroorzaakte zit nog in het geheugen van de programmeur enzovoort.
De reden die steeds wordt aangevoerd om geen gebruik te maken van een geautomatiseerde ontwikkelstraat, is hoogmoed: de programmeurs denken nauwelijks programmeerfouten te maken en dat de tijd die nodig is om geautomatiseerde tests te schrijven meer kost dan hij oplevert. Het management dient hoogmoed te herkennen en zich te realiseren dat de tijd die wordt gespendeerd aan het opzetten van een geautomatiseerde ontwikkelstraat dubbel en dwars wordt terugverdiend.
▪ Toorn: Business de schuld geven voor onvolledige specificaties
Een softwaresysteem is nooit af. Er zal altijd aan gesleuteld moeten worden. Deze veranderingen worden continu ingebracht door de business. De ontwikkelaars worden dan ook makkelijk moe van alle change requests. De teneur bij hen is dat de business nooit precies weet wat ze wil, maar wel dat het niks mag kosten. En ook is er altijd haast bij om de aanpassingen door te voeren.
Het kan daardoor makkelijk voorkomen dat het ontwikkelteam of het beheerteam tegen gaat werken. Ze geloven er niet meer in, aangezien elke aanpassing wordt gevolgd door weer een aanpassing. Bij het uitlopen van het project wordt de schuld dan ook afgeschoven op de business: ze wisten immers niet van tevoren wat ze wilden hebben. Echter, men kan nooit exact uitstippelen wat de functionaliteit van een systeem is voordat het is gebouwd. De veranderbaarheid van software is daarom juist een voordeel.
Moraal: een ontwikkelteam dat boos is op de business dient erop te worden gewezen dat veranderingen een onderdeel zijn van softwareontwikkeling. Bovendien hebben zij hun salaris en pensioen aan de business te danken.
▪ Hebzucht: Een te grootontwikkelteam
Wat is er mooier voor een manager dan een team van honderden programmeurs onder zich te hebben om een nieuwe applicatie te ontwikkelen? Hoe meer personeel, hoe meer verantwoordelijkheid, hoe hoger zijn salaris. En nog mooier: het personeel over verschillende landen en werelddelen verspreiden om de kosten te drukken: een team in Azië, een in Oost-Europa en een in Nederland.
Het probleem hierbij is dat softwareontwikkelaars niet vaak uitblinken in communicatie. Het verspreiden van een ontwikkelteam over verschillende landen, of over verschillende gebouwen, of zelfs over verschillende verdiepingen, zorgt er effectief voor dat deze nooit meer met elkaar hoeven te praten. Terwijl het gesproken woord een veel effectievere manier is om kennis uit te wisselen dan bijvoorbeeld e-mail.
Moraal: ontwikkelteams voor één project dienen in één ruimte te passen. Als dat niet lukt, is het team te groot, communiceert het niet meer en wordt het risico op het falen van het project groot.
Dr. Harro Stokman (h.stokman@sig.nl) en dr. Per John (p.john@sig.nl) zijn beiden Senior Consultant bij de Software Improvement Group te Amsterdam.illustratie: getty images/amir bahadoriDr. Harro Stokman (h.stokman@sig.nl) endr. Per John (p.john@sig.nl) zijn beiden Senior Consultant bij de Software Improvement Group te Amsterdam.