Don’t believe the model, don’t ignore the model

Reduce, Reuse, Recycle

Een goede raad: don’t believe the model: de werkelijkheid is altijd anders, rijker, gedetailleerder, genuanceerder en veelkleuriger. Nog een goede raad: don’t ignore the model, want goede modellen doen uitspraken over een stukje van de werkelijkheid, uitspraken die in veel gevallen waar zijn.
Vooral de combinatie van deze adviezen is waardevol: zonder het eerste advies is de verleiding groot het tweede in te korten tot: ‘modellen doen uitspraken over de werkelijkheid die waar zijn’. Samen geven ze het evenwicht dat het mogelijk maakt beschikbare modellen te onderzoeken en ze zinvol toe te passen als de situatie zich daarvoor leent.

Zoals de IT haar eigen modellen kent zo kennen ook andere disciplines hun eigen modellen. Dat zijn modellen die uitspraken doen die we niet zonder meer mogen vertalen naar ons vakgebied. Als we echter rekening houden met het ‘don’t believe’, dan kunnen we er op een verantwoorde manier van profiteren.
In deze artikelenserie is het nu de beurt aan de kreet reduce, reuse, recycle!

Milieubelangen worden vaak geschetst als tegenstrijdig aan economische belangen. Maar waar draait het om in economische afwegingen? Om schaarse goederen — en dat is precies waar het bij de aandacht voor het milieu ook om draait. In de softwareontwikkeling zijn mensuren schaars. Wat valt er voor ons te leren als we parallellen trekken tussen milieubehoud en softwareontwikkeling? Reduce, reuse, recycle! Als er milieuarchitecten bestonden, zou dit hun lijfspreuk zijn. Laten we ze eens één voor één bekijken.

Reduce

In milieutermen kun je reduceren door niet te consumeren, maar je kunt ook kiezen voor een minder belastende vorm van consumeren: fietsend in plaats van met de auto naar het werk, geïmpregneerd Europees grenen in plaats van tropisch hardhout.
Ik las eens een stelling uit een proefschrift die zo ongeveer als volgt luidde: ‘veel vergadertijd zou worden bespaard indien zij die niets te zeggen hebben, dat zwijgend tot uitdrukking zouden brengen.’ Vertaald naar de softwareontwikkeling: ‘veel ontwikkeltijd zou worden bespaard indien functies die niet gebruikt worden, niet worden ontwikkeld.’ Ik ken helaas geen betrouwbare schattingen van functies die wel worden ontwikkeld maar nooit worden gebruikt. Tijdens een seminar heb ik eens 60 procent horen noemen. Dat lijkt me erg hoog, maar laat het eens 20 procent zijn. Snel verdiend, zeker als je in aanmerking neemt dat allerlei zaken ook nog eens een niet-lineair verloop hebben.

Er is geen eenvoudig recept dat leidt tot software die alle benodigde functies biedt en waarin geen enkele functie is opgenomen die niet wordt gebruikt. ‘Keep it simple’ is een zinvolle vuistregel. Echter dat je met productdifferentiatie een deel van de markt kunt pakken en een hogere prijs kunt vragen, is ook waar. Maar met een differentiatiestrategie en een goedkope ‘keep it simple’ IT-ondersteuning die deze strategie niet ondersteunt, red je het niet. Het is duidelijk dat een optimale situatie niet bereikt kan worden door de IT-discipline alleen. Hoeveel deze vorm van reduceren oplevert, is afhankelijk van de kwaliteit van de relatie en de communicatie tussen ontwikkelaar, gebruiker en opdrachtgever.

Dat geldt ook voor de tweede vorm van reduceren. De eerste vorm doet geen pijn — de opdrachtgever vindt het niet erg dat hij iets niet krijgt wat hij toch niet wil gebruiken, en de ontwikkelaar vindt het niet erg om dat niet te bouwen. De tweede vorm heeft iets met soberheid te maken. Software ‘zonder gouden randjes’: zonder de functies die minder opbrengen dan ze kosten. Voor de eerste vorm van reduceren is al geen simpel recept, hier ligt het nog moeilijker. Hoe leg je als ontwikkelaar uit dat je denkt dat een wens in de categorie ‘gouden randjes’ valt? Wat onderscheidt jou dan van de klantonvriendelijke niet-voor-rede-vatbare-vul-maar-in? In zo’n situatie is een goede relatie niet genoeg, er moet ook sprake zijn van wederzijds vertrouwen. Ontwikkelaars hebben vaak het gevoel dat je optimaal aan de wensen van de opdrachtgever voldoet als je alles doet wat wordt gevraagd (en soms ook dat wat niet wordt gevraagd, maar wat je er wel bij kunt denken). De werkelijkheid is waarschijnlijk dat een opdrachtgever liever een reëel beeld heeft van de kosten en de mogelijkheden, en op grond daarvan wil beslissen.

Reuse

We kennen nog een vorm van reductie: reductie van complexiteit. Het streven naar complexiteitreductie is al zo oud als de automatisering zelf. De machinetaal was er nog maar net, of iemand bedacht al dat het met mnemonics beter ging. Assembleertalen kenden al snel een grote verzameling macro’s, maar dat kon niet voorkomen dat het gebruik ervan, relatief gezien, snel terugliep door de komst van hogere programmeertalen zoals Fortran en Cobol, die later terrein moesten afstaan aan 4GL’s en programmageneratoren. De gegevenskant kent ook zo’n ontwikkeling, van flat files via hiërarchische naar relationele databases. Complexiteit verstoppen onder een slimme, eenvoudig aan te spreken buitenlaag. In de sfeer van methoden en technieken kun je daar bijvoorbeeld nog CASE-tools aan toevoegen, en zo kan het gebeuren dat een ontwikkelaar anno 2000 tien keer zo productief is als zijn collega van dertig jaar geleden.

Deze reductie van complexiteit is een vorm van ‘reuse’ die leidt tot betere hulpmiddelen voor ontwikkelaars. Ontwikkelaars worden productiever dankzij het hergebruik dat plaatsvindt door het hulpmiddel. Elke compute wordt door een bepaalde routine in de compiler vertaald in hele lijst assembleerinstructies. Maar de ontwikkelaar zelf doet niet aan hergebruik.

Reuse; hergebruik. Je laat toch niet je oude stoelen (ja, ze zijn eigenlijk nog best) overzetten in je nieuwe auto? Het grote probleem bij hergebruik, of het om nu tweedehands kleding of om softwarecomponenten gaat, is de psychologische drempel. Voor hergebruik van software zijn zoveel goede redenen te geven dat er rationeel geen probleem is. Dankzij het niet-materiële karakter van software zijn psychologische drempels die wel gelden voor tweedehands spulletjes, ook niet aan de orde. Maar software maken is mensenwerk. We hebben er altijd de mensen voor geselecteerd die graag en goed puzzelen, die een probleem als geen ander kunnen oplossen. Dat werkt dus zo: ‘jij en ik weten natuurlijk best dat hergebruik verstandig is en dat onze collega’s vakkundig zijn, maar zo goed als wij het doen, nee-nee, en dus doen we het maar zelf.’ En vervolgens rationaliseren we er nog even rustig op los om tot de conclusie te komen dat het echt veel verstandiger is om het maar weer zelf te doen, from scratch.

Problemen met hergebruik zijn er genoeg. Het laten slijten van de psychologische drempels kost tijd. Herbruikbare componenten zelf ontwikkelen kost veel tijd; het vier-tot tienvoudige van hun niet-herbruikbare varianten. Tijdens het ontwikkelproces gebruikte methoden en technieken moeten hergebruik actief een plaats geven. Testen verandert. Beheer en onderhoud stellen hun eigen eisen. De kost gaat voor de baat uit, en niet zomaar een paar maanden: hergebruik kost in eerste instantie geld, de opbrengsten komen later. De te behalen besparingen in te besteden ontwikkeltijd 25 procent lijkt zeker haalbaar — zijn hier de pot met goud aan het einde van de regenboog.
Om hergebruik ingebed te krijgen in het ontwikkelproces is sturing noodzakelijk. Realistische verwachtingen helpen. Dat voor bepaalde toepassingen volop herbruikbare componenten te koop zijn, helpt ook: je ziet dat het werkt.

Recycle

Je weet dat er in een vrachtwagen met huisvuil vele tientallen kilo’s metalen, kunststof en glas zitten, maar afvalscheiding is nog een heel probleem. Als ergens 30 procent ijzer inzit, of 1 procent goud, dan is er wel een proces in te richten om dat er op een economisch aantrekkelijke manier weer uit te halen. Maar met ons huisvuil gooien we veel waardevol materiaal weg als ware het afval. Op soortgelijke wijze gooien we hele systemen weg en vervangen we ze door nieuwe als er functioneel slechts een beperkt aantal procenten wijzigt. Het is met die functionaliteit net als met het glas in het afval: je krijgt het er niet uit.

In onze monolitische legacy-systemen zit voor een vermogen aan functionaliteit, maar we zijn nauwelijks — zeg maar: niet — in staat efficiënt re-engineeringprocessen in te richten om dat eruit te halen. Een uitzondering hierop wordt gevormd door de screen-scraping applicaties, maar om dat recycling te noemen is discutabel.
Als we in de toekomst functionaliteit willen recyclen zullen we daar bij de bouw rekening mee moeten houden. Gebruikmaken van de al genoemde herbruikbare componenten is een goede stap. Meer algemeen geformuleerd: we moeten geen monolieten meer bouwen, maar we moeten op basis van ‘minimale samenhang, maximale koppeling’ komen tot relatief los-gekoppelde, zelfstandige onderdelen. Geen gemakkelijke recepten. Niet voor reduce, niet voor reuse en ook niet voor recycle.

Een goed milieu…

Iedereen is het erover eens dat het milieu belangrijk is. Maar daar stopt de overeenstemming meestal. Gezamenlijk maatregelen formuleren blijkt razend moeilijk. Voor reduce, reuse en recycle in de softwareontwikkeling is het al niet anders. Natuurlijk is het belangrijk, natuurlijk moeten we het doen. Zonder goede programma’s, managementcommitment en voldoende budget redden we het niet, dat is ook waar. Maar als we ‘de auto blijven pakken om een pakje sigaretten te gaan kopen’ redden we het ook niet: een goed milieu begint bij jezelf!

oorspronkelijke publicatie: Wil Leeuwis, in: informatie, januari/februari 2000, p. 28-29. © 2000, informatie.