een nieuw perspectief voor kwaliteit
Pieter Wisse
Alweer enkele decennia ontwikkelen mensen computerprogrammatuur. Omdat daarbij veel misgaat, komt vanuit de praktijk en academische wereld ook alweer tientallen jaren een stroom goedbedoelde aanwijzingen voor verbetering van kwaliteit. Maar waarom zijn over het algemeen resultaten nog steeds zo bedroevend? Ter illustratie, waarom begint bijna elke toelichting op de zoveelste ontwikkelmethode altijd nog met een verhaal over zoiets als de software crisis? Blijkbaar, alle claims ten spijt, leidt toepassing van zulke methoden met hun bouwregels niet tot wezenlijke kwaliteitsverbetering. Wat ontbreekt is een adequate rolverdeling, die complexiteit van informatievoorziening weerspiegelt.
Mijn uitgangspunt luidt dat bouwregels weliswaar nodig, maar nooit voldoende zijn. Dergelijke regels, noem ze ook maar bouwvoorschriften of constructieprincipes, zijn pas werkzaam in een omvattend, architectonisch kader. Dat is de zgn informatiearchitectuur. En daarvoor moet, als het tenminste om een complexe opgave gaat, een aparte informatiearchitect1 verantwoordelijk zijn. Netzoals geldt voor de gebouwde omgeving, is het voor complexe organisatorische informatievoorziening de architect die ontwerpt en de aannemer die bouwt. Kortom, de informatiearchitect en de programmatuuraannemer hebben elk hun eigen vak. Dat biedt een nieuw perspectief voor software engineering.
Overigens lagen ontwerp en ontwikkeling lang in één hand, was er helemaal geen rolverdeling. Dat leert de geschiedenis van bouwregels voor computerprogrammatuur. In artikelen die hij tussen 1965 en 1972 publiceerde, toont E.W. Dijkstra zich letterlijk een schoolvoorbeeld van deze vroege stroming. Daarom concentreer ik me hier op zijn werk. Het recente onderscheid tussen informatiearchitect en programmatuuraannemer gebruik ik enerzijds om de actualiteit van veel van zijn regels en overige aanwijzingen voor programmatuurbouw te bepleiten. Dat is mijn erkenning van zijn bijdragen aan software engineering; die hebben internationaal een traditie helpen vestigen. Anderzijds lever ik kritiek. Want als pioneer van software engineering noteerde Dijkstra mi valse verwachtingen over een revolutie in het programmeren. Die is er inderdaad niet gekomen, waarschijnlijk omdat de wens de vader van de gedachte was, en niets meer, toen hij tot zijn veronderstellingen kwam. Maar ze bieden vervolgens aanknopingspunten om aparte aandacht voor informatiearchitectuur te benadrukken. Van Dijkstra naar informatiearchitect, dus.
Aan het werk van Dijkstra heb ik Engelstalige citaten ontleend. Dat is immers de taal waarin hij zijn artikelen oorspronkelijk publiceerde en onvertaald komt zijn bedoeling uiteraard het scherpst over. Allereerst wijd ik echter enkele algemene, inleidende opmerkingen aan bouwregels voor computerprogrammatuur.
Een computerprogramma wordt gemáákt. Het is, met andere woorden, een bouwsel. Ter bevordering van kwaliteit kunnen regels gelden. En wanneer een bouwregel onvoorwaardelijk toepassing verdient, is er zelfs sprake van een (bouw- of constructie)principe. Een principe beschouw ik dus als een bijzonder geval van een regel. Daarom schrijf ik in het algemeen over regels.
Het is handig bouwregels in twee categorieën te verdelen, te weten positieve en negatieve. Een positieve regel gebiedt de ontwikkelaar iets te doen. Dat is een gebod. Daarentegen moet de ontwikkelaar volgens een negatieve regel juist iets in de constructie nálaten. Een verbod, dus.
Het onderscheid tussen positieve en negatieve bouwregels werpt onder meer licht op de positie van een vak in zijn historische ontwikkeling. Want de eerste regels ontstaan steevast naar aanleiding van falende bouwsels. Als onderzoek een (vermeende) oorzaak laat zien, komen er één of meer regels om diezelfde oorzaak in de toekomst te vermijden. Met andere woorden, vroege regels komen re-actief tot stand. En zij hebben een — neutraal bedoeld — negatief karakter, dat wil zeggen dat zo´n regel iets vèrbiedt. Het vak, gezien als conglomeraat van beroepsbeoefenaren, heeft blijkbaar door een catastrofe geleerd hoe het nièt moet. Nota bene, daarmee is nog niet eenduidig bekend hoe het bouwen wèl moet, laat staan dat er positieve regels zijn waarvan toepassing de kwaliteit van het resultaat wáárborgt. Een vak moet vaak een langdurige ontwikkeling doormaken om het stadium van louter negatieve bouwregels te verlaten.2
Een levensvatbaar vak kent gaandeweg meer en meer positieve bouwregels. Die gaan een hecht stelsel vormen, zodat aanvullende regels soms zelfs pro-actief afgeleid kunnen worden. Dat is het stadium waarin theorievorming omtrent het vak wetenschappelijke status verkrijgt. Overigens is een vak met louter positieve bouwregels geen vak voor mensen meer; dan zijn alle mogelijke beslissingen immers gedetermineerd en kan een automaat het werk overnemen.
Een, zeg maar, rijp vak voor menselijke specialisten omvat altijd een mix van positieve en negatieve bouwregels. Dat mengsel is ook nogeens dynamisch, wanneer omstandigheden voor het vak veranderen (en het vak dergelijke veranderingen mede veroorzaakt). Zulke dynamiek is een reden temeer dat mensen zich ermee moeten blijven bemoeien.
Als ook software engineering een vak is, hoe staat het daar dan met bouwregels en -voorschriften? Voor een redelijk antwoord voeg ik nog een onderscheid toe. Dat is tussen serieuze beroepsbeoefenaren en beunhazen.
Over beunhazen valt met weinig woorden toch veel te zeggen. Zij proberen hun klanten ervan te overtuigen dat zij een methode volgen met een compleet stelsel positieve bouwregels. De suggestie luidt dat de opdrachtgever geen enkel risico loopt. "Succes verzekerd!" is hun slogan. "Alles onder controle!" Er heerst vaak extra gevaar met beunhazen, indien zij zichzelf serieus nemen en daardoor overtuigender acteren. In zijn verlangen naar zekerheid betrekt zo menig opdrachtgever precies de verkeerde interne en/of externe medewerkers bij kritieke veranderingen.
Serieuze beroepsuitoefening leidt daarentegen onontkoombaar tot het inzicht dat software engineering zich in een pril stadium bevindt, met alle onzekerheid van dien. Het is domweg een jeugdig vak, nog altijd. Want er zijn bijna uitsluitend nog maar negatieve constructieprincipes. Daarvan zijn er trouwens enkele allang bekend. Een mooi voorbeeld is het gebruik van goto-statements. Dijkstra was weliswaar niet de eerste die op verbod ervan aandrong, maar slaagde er wèl als eerste in ruime aandacht te trekken. Wie zijn artikelen3 'Programming Considered as a Human Activity' en 'Go To Statement Considered Harmful' nogeens leest, proeft ongetwijfeld dat Dijkstra met zijn verbod wil vermijden dat programma's chaotisch worden. Voor het omgekeerde, dat wil zeggen voor overzichtelijke programma's, komt hij weliswaar met enkele aanwijzingen, maar niet met zoiets onvoorwaardelijks als positieve constructieprincipes. Nogmaals, gelet op het ontwikkelstadium van het vak is dat ontbreken van enig positieve regel of zelfs principe volstrekt begrijpelijk. Let wel, genoemde artikelen stammen uit 1965, respectievelijk 1968. En nog altijd is het vak software engineering 'principieel' nauwelijks gevorderd.
In het tijdsbestek van enkele decennia is natuurlijk wel het accent voor ontwikkelaars verschoven. Tot ver in de zestiger jaren waren zij vooral met aparte programma's bezig. Onderling kenden die programma's geen of nauwelijks relaties. Dat veranderde met zgn informatiesystemen. De omvang van zo´n systeem maakte implementatie met één enkel programma praktisch onhaalbaar. Dus moesten de diverse programma's samenhang vertonen. Met het onderscheid tussen proces (programma's als verzamelingen toepassingsinstructies) en data (grondstoffen en/of resultaten van verwerking door zulke programma's) nam de splitsing van een totaal informatiesysteem in samenstellende delen verder toe.
Met zijn kritiek op goto-statements beschouwt Dijkstra het aparte programma nog duidelijk als primair onderwerp van ontwikkelinspanningen. Er is bijvoorbeeld nog geen sprake van een omvattender informatiesysteem, laat staan van integrale informatievoorziening voor een gehele organisatie of overkoepelende processen. Dit is althans mijn interpretatie van het volgende citaat uit 'Programming Considered as a Human Activity:' "[T]he convincing power of the results is greatly dependent on the clarity of the program, on the degree in which it reflects the structure of the process to be performed." Het programma is dus nog het verwerkingsequivalent van het proces. En daarvoor moet dat programma zonodig uit aparte onderdelen bestaan ipv dat het programma zo´n onderdeel van iets omvattenders is. Dat Dijkstra aan de andere kant toch een programma al zag, zoals later voor een — groter — systeem is gaan gelden, blijkt eerder in hetzelfde artikel: "[T]he correct working of the whole can be established by taking, of the parts, into account their exterior specification only, and not the particulars of their interior construction." Wie dit leest, moet beseffen dat Dijkstra dit dus in 1965 schreef. Het is welhaast onvermijdelijk dat zijn concrete onderwerp nog het ene programma was. Maar wie programma overal door systeem vervangt, kan Dijkstra lezen als het allerlaatste op het gebied van bijvoorbeeld objectgerichte informatievoorziening. De zgn information hiding is exact hetzelfde als wat Dijkstra definieert als afhankelijkheid van externe specificaties.4
Voor de lijn van mijn verhaal blijf ik Dijkstra als gids volgen. Dankzij de verdere ontwikkeling van het vak, kunnen informatiekundigen het probleem, dat voor Dijkstra toen nog de verhouding tussen "whole" and "parts" binnen één programma was, tegenwoordig veel ruimer opvatten. Complexiteit noodzaakt altijd tot keuze van elementen binnen het totale systeem. Dat is enerzijds een oplossing, want de complexiteit van elk element is sterk gereduceerd vergeleken met die van het totale systeem. Anderzijds is er door de opsplitsing een probleem bijgekomen. De gecreëerde elementen moeten immers samenhang vertonen om als één systeem te werken. Zo roepen elementen onmiddellijk hun onderlinge relaties op. De opgave daarbij is dat het middel niet erger dan de kwaal mag zijn. Per saldo moet de grotere beheersbaarheid van de aparte elementen opwegen tegen eventuele ònbeheersbaarheid van of, beter gezegd, beheersinspanningen voor hun onderlinge relaties. De pioniers van software engineering geven, ondanks hun noodzakelijke pre-occupatie met het programma-als-systeem, blijk van diepgaand inzicht in de problematiek van verdeel-en-heers. Dijkstra zegt erover, opnieuw in 'Programming Considered as a Human Activity' dat "elegance, accuracy, clarity and a thorough understanding of the problem at hand are prerequisite. [... T]he whole dissection technique relies on something less outspoken, viz., on what I should like to call 'The principle of non-interference'." Wat Dijkstra ongetwijfeld bedoelt, is dat elementen van een systeem niet lukraak invloed op elkaar mogen uitoefenen. Onderlinge relaties zijn echter nodig. Anders is er immers geen sprake van "parts" in een "whole." Overigens is het belangwekkend dat Dijkstra reeds het woord "principle" gebruikt. In mijn optiek is zijn uitspraak een poging om een negatief constructieprincipe te formuleren. Dat is niet gelukt, omdat "non-interference" te absoluut gesteld is. Letterlijk genomen sluit non-interference alle relaties tussen elementen uit.5 Dat is natuurlijk onzin. Het gaat om optimale beheersbaarheid van dergelijke relaties.
In 1969 heeft Dijkstra zijn oriëntatie op een afzonderlijk computerprogramma nog niet helemaal verlaten. Maar in het artikel 'Structured Programming' staat aan het begin expliciet: "My concern is with intrinsically large programs." Hij schuift dus onmiskenbaar op in de richting van wat later het etiket informatiesysteem kreeg. Daardoor vraagt hij nadrukkelijker dan voorheen aandacht voor beheersbaarheid van programmatuur gedurende de totale levenscyclus. "Any large program will exist during its life-time in a multitude of different versions[.]" Zo ontstaat helaas een dubbele betekenis van de term programma want hij zegt "that in composing a large program we are not so much concerned with a single program, but with a whole family of related programs[.]" Het is jammer dat Dijkstra toen niet meteen een gescheiden terminologie voorstelde voor dat onderscheid. Met zijn onmiskenbare invloed op het internationale podium had hij systeembenadering veel eerder ingang kunnen laten vinden in het vak software engineering. Wat blijft zijn prachtige uitspraken die na alweer zoveel jaren echter enige verduidelijking van hun context eisen: "Any program [....] should be conceived and understood as a member of a family[.]" Verderop komt Dijkstra met de nogal ongelukkige vergelijking van een "large program" met een parelketting: "The top pearl describes the program in its most abstract form, in all lower pearls one or more concepts used above are explained (refined) in terms of concepts to be explained (refined) in pearls below it, while the bottom pearl eventually explains what still has to be explained in terms of a standard interface (= machine). The pearl seems to be a natural program module." De beeldspraak gaat snel mank omdat een parelketting geen hiërarchie vertegenwoordigt in de zin dat een grote parel diverse kleinere parels ìn zich bergt. Desondanks is Dijkstra visionair. Want in een notedop formuleert hij al in 1969 de essentie van wat nu als objecttechnologie in de mode is. "The combinatorial freedom [of such program modules] seems to be the only way in which we can make a program [module] as part of a family. [...] The family becomes the set of those selections from a given collection of pearls that can be strung into a fitting necklace." Nogmaals, het was allemaal duidelijker geweest als Dijkstra van meet af het begrip systeem gehanteerd had. Dat impliceert immers de hiërarchische herhaling (recursiviteit) waarvoor hij nu de kromme vergelijking met de parelketting opvoert. Met de systeembenadering als grondslag was zo´n analogie zelfs overbodig geweest; zijn presentatie had ermee zowel aan praktische bruikbaarheid, als aan wetenschappelijkheid gewonnen.
Het ontbreken van enige vermelding van het woord systeem in 'Structured Programming' is des te merkwaardiger, omdat Dijkstra een jaar eerder, in 1968, het artikel 'The Structure of the 'THE'-Multiprogramming System' publiceerde. THE is een acroniem voor Technische Hogeschool Eindhoven. En, zoals de titel verder aangeeft, is het onderwerp van dat artikel een besturingssysteem, geen toepassingsprogrammatuur. Maar toen waren zgn toepassingen betrekkelijk eenvoudig als gevolg van stapelgewijze informatieverwerking. Programma en verwerkingsproces waren feitelijk synoniem. Complexer, en daarom interessanter voor een pionier, was overkoepelende besturing van dergelijke verwerkingsprocessen teneinde de (destijds) dure apparatuur beter te benutten. Met die complexiteit van procescoördinatie moet Dijkstra zich vertrouwd gevoeld hebben, want voor zijn programmatuur dáárvoor gebruikt hij op natuurlijke wijze wèl het woord systeem. Hij beschrijft het THE-besturingssysteem vervolgens in termen van de belangrijkste ontwerpbeslissingen. Wie ze leest, kan niet anders dan getroffen raken door hun vanzelfsprekendheid. Het is zeer elegant. Kwaliteit door ontwerp. En daarvoor woog hij, bijvoorbeeld, de geringe beschikbaarheid van zijn medewerkers om het te realiseren mee. Zo niet voor het resultaat, maar dan toch al voor de aanpak herkende Dijkstra het belang van zoiets als organisatiecultuur. Ik zou zeggen, dat is informatiearchitectuur avant la lettre.
Maar Dijkstra zag zichzelf kennelijk vooral als programmeur. Hij wilde programmeren op wetenschappelijk peil brengen. Dat is mijn verklaring dat hij de systeembenadering in de richting van integratie van informatievoorziening in omvattende organisatorische processen niet vervolgde. In plaats daarvan keerde hij terug naar het programma als zijn favoriete object. Daardoor heeft hijzelf de ontwikkeling naar expliciete informatiearchitectuur gemist. Ik zie dat als bevestiging dat een informatiearchitect en een programmatuuraannemer (lees ook: ontwikkelaar) elk hun eigen vak hebben.
In 1972 publiceerde Dijkstra het artikel 'The Humble Programmer.' Ook dat zou tot in lengte van dagen verplichte lectuur moeten zijn voor iedereen die iets te maken heeft/krijgt met het ontwerp en/of de bouw vanaf een apart computerprogramma tot en met integrale informatievoorziening in organisaties en processen. Het is fascinerend te lezen dat Dijkstra zich in zijn veronderstellingen inmiddels allesbehalve bescheiden toont. Hij predikt revolutie in software engineering. Daarvoor poneert hij in zijn ongeduld positieve bouwregels die het volgens mij echter helemaal niet zijn. In dat artikel zegt hij zèlf dat ontwikkelaars van fouten moeten leren. Welnu, ik pak hier de fouten op die Dijkstra mi in zijn analyse van voorwaarden voor zijn revolutie maakte. Overigens waak ik ervoor Dijkstra daarover een groot verwijt te maken. Hij is en blijft de pionier die door zijn bijdragen beroepsbeoefenaren ná hem kan blijven inspireren.
Allereerst roep ik de voornaamste redenen in herinnering die Dijkstra aanvoerde voor de groeiende software crisis. Hij begint ermee te noemen dat de werking van computers steeds ingewikkelder wordt. Maar veel belangrijker is, zegt hij, dat hun verwerkingskracht spectaculair toeneemt. Dat aanbod leidt op zijn beurt naar alsmaar meer vraag naar steeds complexere toepassingen. Omdat zowel de machines, als de programmeertalen niet uit zichzelf tot ontwikkeling van beheersbare programmatuur uitnodigen, is het resultaat per saldo steeds meer ònbeheersbare programmatuur.
Dan zegt Dijkstra: "So much for the past. But there is no point in making mistakes unless thereafter we are able to learn from them." En dit komt er meteen achteraan: "As a matter of fact, I think that we have learned so much that within a few years programming can be an activity vastly different from what it has been up till now, so different that we had better prepare ourselves for a shock. [...] The vision is that, well before the seventies have run to completion, we shall be able to design and implement the kinds of systems that are now straining our programming ability at the expense of only a few percent in man-years of what they cost us now, and that besides that, these systems will be virtually free of bugs. [...] Such a drastic change in such a short period of time would be a revolution[.]"
Dat is krachtige taal, maar zijn voorspelling is niet uitgekomen. In deze passage gebruikt Dijkstra trouwens plotseling het woord "systems," maar verbindt daar geen grensverruimende gevolgen in conceptuele zin aan. Maar laat ik verder aantonen waarom, achteraf gezien, Dijkstra te optimistisch was. Dat is gemakkelijk genoeg door zijn veronderstelde voorwaarden na te gaan.
In de eerste plaats, aldus Dijkstra, moet "[t]he world at large" de noodzaak van de verandering inzien. Daarin zag hij geen enkel probleem meer. Had eindelijk niet iedereen de mond vol van de software crisis? Waren niet alle functionarissen die verwantwoordelijk zijn voor realisatie van een "large sophisticated system" bezorgd om betrouwbaarheid van programmatuur?
Met de tweede voorwaarde zat het volgens Dijkstra ook wel goed. Omdat met de bestaande praktijk programmatuur domweg te duur zou worden, was er een economische noodzaak voor de radicale verandering: "You cannot expect society to accept this [clumsy and expensive process of software development.]"
Met de eerste twee voorwaarden schetste Dijkstra, zeg maar, de vraag naar de revolutie. Maar er moest uiteraard passend aanbod zijn. Voor zijn derde voorwaarde stelde hij zichzelf de vraag: "[I]s it technically feasible?" Voor zijn bevestigende antwoord gaf hij zes argumenten. Als eerste geldt dat de revolutie haalbaar is, mits de programmeur zich beperkt tot programma's die verstandelijk beheersbaar zijn (en dus blijven). Geruststellend zegt Dijkstra erover dat "the class of intellectually manageable programs is still sufficiently rich to contain many very realistic programs for any problem capable of algorithmic solution." Het eerste argument voor wat Dijkstra technische haalbaarheid noemt, leidt tot het tweede. Dat is dat er een sterk verkleinde oplossingenruimte overblijft.
Vervolgens komt Dijkstra terug op zijn idee over "program correctness." Het uitgangspunt moet niet zomaar een programma zijn, maar het vertrouwen dat een bepaalde bewijsvoering in de uitkomst ervan wettigt. Dus, juist in omgekeerde richting uitgaande van zo´n bewijsvoering, "then these correctness concerns turn out to be a very effective heuristic guidance" voor de constructie van een programma.
Dit derde argument (voor zijn derde voorwaarde) van Dijkstra verdient extra aandacht. Ik meen er, ondanks mijn kritiek op zijn ongewettigd optimisme, zijn blijvende betekenis in samengevat te zien. Hij legt daarmee immers de grondslag voor positieve bouwregels en -principes in het vlak van informatievoorziening. Dat hij ondanks zijn grondslag besefte nog niet verder te zijn dan negatieve principes — hoewel hij die terminologie niet gebruikte — blijkt uit een eerdere zin uit nog steeds 'The Humble Programmer:' "A number of rules have been discovered, violation of which will either seriously impair or totally destroy the intellectual manageability of the program." Dus, wie zulke regels volgt, heeft nog geen waarborg voor succes. Maar wie ze negeert, koerst geheid op een mislukking af. De eerlijkheid gebiedt me te zeggen dat tegenwoordige informatiekundigen hiermee dus nauwelijks verder gevorderd zijn dan Dijkstra. Het blikveld is verbreed van programma naar totale informatievoorziening, maar eigenlijk niet verdiept.
Als vierde argument om de revolutie te doen slagen noemt Dijkstra — de noodzaak van — abstractie. Werkelijk prachtig, vind ik, geeft hij de waarde van abstractie weer, zij het dat hij dat dus in de context van — het ontwerpen en bouwen van — een programma doet: "We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad of cases is called 'abstraction' [... T]he purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise."
Zijn vijfde argument leidt hij in met een beschouwing over de relatie tussen enerzijds de manier waarop een mens denkt, anderzijds de gereedschappen waarover hij beschikt. De conclusie is dat slechts gereedschappen in aanmerking komen die elegante denkconstructies — en vervolgens elegante programmatuur — bevorderen. Een programmeertaal "should invite us to reflect in the structure of what we write down all abstractions needed to cope conceptually with the complexity of what we are designing."
Onder de noemer van technische haalbaarheid vermeldt Dijkstra als zesde en laatste argument de noodzaak om elk geheel consequent in onderdelen te ontleden (factoring). Met de ruime toepasbaarheid van hiërarchische ontleding is ook hieraan volgens hem voldaan.
Waarom is de programmatuurrevolutie van Dijkstra uitgebleven? Ik begin met iets over de technische haalbaarheid te zeggen.
Hoewel, techniek? Bij nader inzien is techniek nauwelijks aan de orde in de zes onderliggende argumenten. Dijkstra beschrijft daarentegen vooral zijn ideale programmeur. Het zou me trouwens niet verbazen wanneer hij er dus een zelfportret mee heeft proberen te schilderen. Want hij verlangt nogal wat van een programmeur. De nadruk ligt bijna volledig op persoonlijke discipline (argumenten 1 t/m 3) en conceptueel vermogen (argumenten 4 t/m 6). Wie daarover in de mate beschikt, die Dijkstra aangeeft, is volgens mij per definitie leider6 van zo´n revolutie. Maar elke revolutie heeft pas kans van slagen met zgn voetvolk. Of dacht Dijkstra dat zijn revolutie zo krachtig was, dat een handvol overblijvende programmeurs voldoende zou zijn?
De oproep van Dijkstra mist doel, omdat hij slechts voor een elite begrijpelijk is. Hij is aan de meeste beroepsbeoefenaren niet besteed, sterker nog, die hebben er ongetwijfeld nooit van gehoord. Dijkstra geeft zichzelf danook teveel eer wanneer hij zegt dat "it will provoke violent opposition and one can ask oneself where to expect the conservative forces trying to counteract such a development." Wat deze passage vooral toont, is vooringenomenheid met het eigen standpunt. Ik denk dat de werkelijke ontwikkeling volstrekt banaal verliep. Er was helemaal geen oppositie. Dat veronderstelt immers dat het standpunt van Dijkstra bekend was èn serieus werd genomen. Zolang aan die voorwaarden niet voldaan is, is er geen sprake van tégenactie. De rest — bijna iedereen behalve Dijkstra dus — ging en gaat gewoon dóór met wat en hoe ze altijd deden. Zo is het helaas. Wie dat wil veranderen, moet niet vanaf de academische zijlijn met argumenten komen, maar vooral direct invloed op machtsverhoudingen uitoefenen.
Netzo onrealistisch toont Dijkstra zich met zijn algemene en zijn economische voorwaarden. Volgens hem werd de noodzaak van betrouwbare programmatuur algemeen erkend. Dat moet een aanval van wishful thinking geweest zijn. Een structurele verklaring kan opnieuw zijn dat Dijkstra in academische kringen verkeerde. Dat was toen natuurlijk ook al een aanbod dat vraag probeerde te creëren. Zeker liggen er veel mensen vaak wakker van onbetrouwbare programmatuur. Maar het is de vraag of dat de mensen zijn, juist met voldoende invloed om het klimaat waarin programmatuur geconstrueerd wordt te veranderen. Mijn antwoord luidt ontkennend, met als bewijs uit het ongerijmde dat ze anders niet wakker zouden liggen. Wat Dijkstra over zijn eerste voorwaarde vermeldt, is dus stellig goed bedoeld, maar niet steekhoudend.
Hetzelfde oordeel geef ik over zijn argumentatie voor de tweede voorwaarde, te weten de economische noodzaak van verbetering. Opnieuw verduistert Dijkstra zijn oproep door een generalisatie. De 'maatschappij' zou de verspilling onacceptabel vinden. Maar juist economisch gezien, maakt het een kapitalistische samenleving met ruimte voor groei niets uit. Sterker nog, per (financieel) saldo neemt het bruto nationaal produkt toe met omvangrijke schakels in de waardenketting. Dat oogt op dat niveau van aggregatie allemaal gezond. De eenheid van analyse moet dus niet de totale maatschappij zijn, maar de ene organisatie waarvan het voortbestaan eventueel bedreigd wordt door verspilling. Daarvoor kan de produktiewijze van programmatuur beslist een risico vormen. Opnieuw geldt echter dat zo´n risico allereerst herkend moet zijn. Dan is het vaak nog een ànder verhaal er serieuze aandacht voor te krijgen, om van koerswijziging — let wel, ikzelf vermijd het woord revolutie nadrukkelijk — voorlopig maar niet te spreken. In plaats van de maatschappij in het algemeen gaat het dus om een persoon in een organisatie, allebei heel concreet. Wie is het, die het risico met programmatuur moet begrijpen teneinde — ruimte voor — verbeteringen te creëren? Zo concreet gesteld, ligt het antwoord voor de hand. Dat is de vrouw of de man, of de groep mensen, die de macht in zo'n organisatie heeft. In relatie tot ingrijpende veranderingen bestaat voor zo´n persoon een aparte term: opdrachtgever.
Dijkstra publiceerde het artikel 'The Humble Programmer' in 1972. Ik stel nu de vraag: Begrepen alle bestaande en potentiële opdrachtgevers van grote ontwikkelprojecten voor programmatuur inderdaad dat er een ernstig probleem met betrouwbaarheid was? En begrepen zij dat kosten van ontwikkeling zover konden oplopen dat continuïteit van hun organisaties gevaar liep? Ik zou die vragen hier niet stellen, als ze niet retorisch waren. Natuurlijk waren er nauwelijks opdrachtgevers met dat inzicht in geautomatiseerde informatievoorziening. En zovele jaren later, is dat niet wezenlijk veranderd.
Mijn analyse laat zien dat Dijkstra´s revolutie geen kans van slagen had. De zwakte van zijn manifest is trouwens niet zozeer dat hij geen gelijk heeft over kwaliteit van programmatuur. Integendeel, wat hij daarover allemaal gezegd heeft, is actueler dan ooit. Ik deel daarom de frustratie van Dijkstra volkomen. Maar daardoor laat ik me niet tot het waanidee van een revolutie in software engineering verleiden. Zijn blinde vlek betreft de verhoudingen in het maatschappelijk verkeer. Dijkstra had geen politiek 'programma' om gelijk te krijgen. Het probleem van gebrekkige programmatuurkwaliteit vergt vooral een politieke, sociologische ipv een strikt technologische oplossing.
Met talloze stellingen van Dijkstra ben ik het, nogmaals, hartgrondig eens. Als er niets met programmatuur verbetert,7 zijn rampen inderdaad onvermijdelijk. Het wezenlijke probleem is echter dat de twee groepen, die van oudsher betrokken zijn bij ontwikkeling van informatiesystemen, geen van beide bereikbaar zijn met argumentatie over programmatuurkwaliteit. Zoals eerder gezegd, begrijpen de allermeeste opdrachtgevers dat niet. En de programmatuuraannemers luisteren niet. Want zij beschouwen radicale veranderingen niet in hun belang. Zij zijn immers aannemers. Als zodanig krijgen zij doorgaans beloond op basis van bestede uren en materialen. Zolang de marges positief zijn, komen meer uren en meer materiaal altijd neer op hogere inkomsten. Wie verandert zolang het commercieel goed gaat? En wat zou voor een bedrijf een andere maatstaf zijn dan winst? Dus — opnieuw een retorische vraag — wat is de prikkel om aan een revolutie mee te doen die het eigen belang — althans zoals een marktpartij dat zelf ziet — bedreigt? Het pathologisch evenwicht — en Dijkstra is het hier stellig eens met mijn analogie met een ziekelijke toestand — blijft dus gehandhaafd. Het heeft ook geen zin om de boodschap luider te herhalen.
Wat slechts kan helpen is een gewijzigde verhouding tussen partijen in het maatschappelijk verkeer. Dat is Realpolitik. De sociologische oplossing is er één van de zgn checks and balances van een evenwichtiger rolverdeling.
Het is mogelijk tot verkeerde aanbevelingen voor het maatschappelijk verkeer te komen, wanneer het gegroeide verschil verborgen blijft tussen Dijkstra´s programmeur en wat ik een programmatuuraannemer noem. Hetzelfde geldt voor de eveneens gegroeide overeenkomst van Dijkstra´s programmeur met de informatiearchitect.
De huidige programmatuuraannemer beschouw ik als een persoon of bedrijf die/dat, het woord zegt het al, programmatuur bouwt. Het ontwerp moet deze ontwikkelaar volgens mijn opvatting niet maken, tenminste niet het ontwerp voor het gehele systeem, noch dat voor de onderdelen in hun samenhang. Daarvoor is apart een ontwerper nodig. Dat is dan de informatiearchitect. Wat de professionele programmatuuraannemer uitstekend doet, is de produktie van de constructie, het bouwen. En dan moet de aannemer zich mi beperken tot de programmatuurelementen van het systeem; voor realisatie van andere elementen van het totale systeem dat de informatiearchitect ontwerpt, moeten zonodig daarin gespecialiseerde aannemers ingeschakeld worden. Zo is ontwikkeling van, bijvoorbeeld, cursusmateriaal een vak apart.
Voor elke aannemer is doelmatigheid het sleutelwoord en daarom ook voor programmatuuraannemers. De beheersing van het bouwproces zorgt voor winstgevendheid. Onzekerheid omtrent ontwerp vormt een dreiging. Vandaar dat ontwerpende programmatuuraannemers in zo'n geval allerlei meetpunten, mijlpalen en dergelijke opwerpen om hun marge veilig te stellen. Daarmee is de opdrachtgever echter onherroepelijk duurder èn slechter uit. De uitvoerder kan immers niet goed ontwerpen (netzomin als de ontwerper goed kan uitvoeren). De ontwerper waarborgt doeltreffendheid van de constructie. Zoals gezegd, ontwerpt hij daarvoor méér dan de programmatuur in enge zin. Zonder doeltreffendheid is doelmatigheid loos.
Nu blijkt de programmeur, zoals Dijkstra haar/hem portretteert, niet alleen een programmatuuraannemer. Zie daarvoor alleen al de zes argumenten voor zijn derde voorwaarde, te weten de voorwaarde van technische haalbaarheid van de revolutie in software engineering, die ik hierboven de revue liet passeren. Kortom, een programmeur à la Dijkstra is tevens een ontwerper ofwel een ... informatiearchitect, zij het zonder veel aandacht voor de organisatiecultuur van gebruik en beheer van informatievoorziening. Ik merkte dat eerder reeds op. Het verschil met de moderne opvatting is, dat de informatiearchitect veel minder een ontwerper van programmatuur is dan van de integratie van informatievoorziening in totale bedrijfsvoering. Daarom is de moderne informatiearchitect meer een organisatieontwikkelaar. Voor programmatuurbouw als specialisme is er de aparte aannemer die voor zijn werk het overkoepelend ontwerp van een informatiearchitect moet volgen.
Door zijn (her)oriëntatie op programmatuur ipv systeem was Dijkstra niet in staat te voorspellen dat grootschaligheid, complexiteit ed zouden leiden tot de noodzaak van onderscheid tussen enerzijds ontwerp, anderzijds bouw. Hij miste de trend, dat ontwerp tegenwoordig zoveel meer aspecten moet omvatten, bijvoorbeeld tot en met motivatie van medewerkers voor wie het vaak om niets meer of minder dan gereedschap voor hun dagelijks werk gaat.
Naar mijn overtuiging houdt de software crisis aan, zolang in de moderne praktijk het onderscheid tussen ontwerp en ontwikkeling onvertaald blijft naar verschillende rollen voor de informatiearchitect, respectievelijk programmatuuraannemer. Merkwaardig genoeg kan juist Dijkstra door zijn (her)oriëntatie op programmatuur een obstakel voor die verandering vormen. Dat komt door zijn idealisme, waarin hij heil verwacht van een revolutie in software engineering en waarin programmeurs de dragers van die revolutie zijn. Oppervlakkig gelezen, verleidt zo´n boodschap moderne programmatuuraannemers niet bepaald tot bescheidenheid omtrent hun bijdragen aan informatievoorziening. In zijn wereld herkende Dijkstra blijkbaar onvoldoende dat aannemers vooral geld willen verdienen. Waarom zij dat willen? Het zijn immers ondernemers en die streven naar maximale omzet en winst. Wat er dus helaas is gebeurd, is dat aannemers ontwerp en uitvoering (lees voor uitvoering ook: bouw van programmatuur) gebundeld zijn blijven aanbieden. Dat is precies zoals de oorspronkelijke, individuele programmeurs dat in één hand hadden. En dat is ook precies wat er moet veranderen, misschien niet eens in theorie, maar dan tenminste in de praktijk van informatievoorziening voor bedrijven en overheidsinstellingen. Zolang het om simpele opgaven gaat, kan het nog geen kwaad wanneer programmatuuraannemers zich als enige opvolgers van Dijkstra´s programmeur beschouwen. In complexe situaties schieten ze echter tekort. De behoefte aan een aparte informatiearchitect tekent het verschil.
Niet met zijn veronderstellingen en conclusies, maar wèl door zijn argumentatie met accenten op persoonlijke discipline en conceptueel vermogen, maakt Dijkstra duidelijk dat eisen voor ontwerpers en uitvoerders zijn gaan divergeren. Dat moet bredere erkenning vinden, opdat bouwregels effectief zijn en uiteindelijk kwaliteit van informatievoorziening daadwerkelijk verbetert. Naast opdrachtgevers en programmatuuraannemers verdienen daarom informatiearchitecten een aparte plaats. Wie Dijkstra niet alleen oppervlakkig, maar ook intensief leest, herkent zowel architecten, als aannemers als twee verschillende opvolgers van 'zijn' ene programmeur.
Het probleem met communicatie over de rol en positie van informatiearchitecten klinkt vertrouwd. Opdrachtgevers missen vaak opleiding en ervaring voor begrip. En de programmatuuraannemers luisteren meestal niet, omdat zij hun belang geschaad achten.8 Waarom zouden zij hun bemoeienis met ontwerp opgeven, en zodoende omzet en winst, zolang zij daarvoor opdrachten verkrijgen?
Voor verandering van verhoudingen is in dit geval een sleutelwoord: langzaamaan. Een ander sleutelwoord is: normaal, dus vooral niet elitair. En er is beslist geen sprake van een revolutie. Zo sorteert ook Dijkstra die een stap in de evolutie vertegenwoordigt, méér effect dan Dijkstra die met een radicale oproep faalt.
Ondanks de obstakels vormen de (potentiële) opdrachtgevers toch de primaire doelgroep voor communicatie. Wat als boodschap het beste werkt, is geslaagde informatievoorziening met toegevoegde waarde voor de gehele organisatie. Dat houdt aandacht in voor de totale levenscyclus ipv optimalisatie van de realisatie ten koste van later beheer. Zo ervaart de opdrachtgever direct dat een extra partij in het maatschappelijk verkeer rondom informatievoorziening voordelig is. De informatiearchitect is die partij, netzoals de bouwkundige architect dat al eeuwenlang is als het om gebouwen en/of stedebouwkundige planning gaat.
Een secundaire doelgroep voor communicatie over rolverdeling zijn toch de programmatuuraannemers. Want er bestaan wellicht verlichte bouwers. Als zij de veranderingen zien aankomen, kiezen zij wellicht voor continuïteit op langere termijn in tegenstelling tot hoge omzet en winst op de korte. Zij kunnen bij hun opdrachtgevers initiatief nemen om een informatiearchitect bij een project te betrekken. Dat zal aanvankelijk niet vaak gebeuren, maar wie weet. Alles op weg naar betere kwaliteit is meegenomen.
Wederom primair voor communicatie zijn verwante beroepsbeoefenaren, dat wil zeggen andere informatiearchitecten. De langzame ontwikkeling van een adequaat beeld bij (potentiële) opdrachtgevers gaat alweer wat sneller als consequent dezelfde voorstelling verschijnt. Want de cruciale vraag is hoe opdrachtgevers van de toegevoegde waarde van de aparte 'rol' overtuigd raken. Dat kan met het 'merk' informatiearchitect lukken. In menig opzicht bedoel ik daarmee dus de opvolgers van de ontwerpende programmeur zoals Dijkstra haar of hem zag.
noten
1. Zie het boek De Informatiearchitect (Kluwer Bedrijfswetenschappen, 1995) dat ik samen met J.R. van Rees schreef. Daarin ontwikkelden wij het onderscheid tussen de informatiearchitect en de systeemaannemer. In plaats van systeemaannemer geef ik in dit artikel de voorkeur aan programmatuuraannemer. Overigens is in genoemd boek tevens een serie concrete constructieprincipes van Jaap van Rees opgenomen.
2. Langs een tweede dimensie is onderscheid mogelijk tussen bijvoorbeeld universele, situationele en materiaalgerichte bouwregels. Die kunnen dus op hun beurt negatief, respectievelijk positief zijn. Van materiaalgerichte regels zijn naar verhouding de meeste positief. Universele bouwregels zijn — en blijven dat ongeacht het ontwikkelstadium van het vak — juist overwegend negatief.
3. Ik verwijs naar en vermeld citaten uit vijf artikelen van E.W. Dijkstra. Als mijn bron gelden de bundels Classics in Software Engineering (Yourdon Press, 1979) en Writings of the Revolution (Yourdon Press, 1982), allebei samengesteld door E.N. Yourdon. In het laatstgenoemde boek is Dijkstra's artikel over het THE-besturingssysteem opgenomen. Zijn vier andere artikelen staan in Classics of Software Engineering. Beide boeken zijn helaas niet meer verkrijgbaar.
4. Een andere pionier in het vlak van software engineering is D.L. Parnas. Daarvan is vooral bekend het artikel 'On the Criteria to be Used in Decomposing Systems into Modules' uit 1972. Zie hiervoor eveneens de eerstgenoemde bundel in noot 3. De lessen van Parnas zijn slechts vruchtbaar voor wie begrijpt dat zijn decompositie tot een kwalitatief nieuwe opsplitsing kon leiden. Want "[t]he modules no longer correspond to steps in the processing[...] Every module is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings." Er staat bijna letterlijk information hiding verklaard. Parnas liep eveneens vooruit op de recente stroming die de werking van een (informatie)object in termen van een contract specificeert. Hij definieert een module immers als volgt: "[A] "module" is considered to be a responsibility assignment rather than a subprogram."
5. Om Dijkstra niet ten onrechte te bekritiseren sluit ik niet uit dat hij met interferentie 'slechts' het natuurkundig verschijnsel bedoelde van onbepaalde wisselwerking, van lukrake wederzijdse invloed. Dan vertegenwoordigt zijn uitspraak wèl een negatief principe, maar vind ik zijn algemene en daardoor bijna tegengesteld interpreteerbare woordkeuze verwarrend.
6. In dit licht krijgt de titel 'The Humble Programmer' een stellig onbedoelde betekenis. Wie zoveel in zijn mars heeft, moet inderdaad zeer bescheiden zijn om zich aan de discipline van Dijkstra´s argumenten te houden. Dit onthult een superioriteitsgevoel dat juist ònbescheiden is.
7. En natuurlijk maakt programmatuurbouw een eigen, professionele ontwikkeling door waardoor kwaliteit verbetert. Dat gaat mi echter lang niet ver genoeg en verloopt, erger nog, in de verkeerde richting. Er is inderdaad een kwaliteitssprong nodig. Wie daarvoor campagne voert, verliest weleens een nuance uit het oog. Daarvoor bij voorbaat mijn excuus.
8. Wie meent dat ook informatiearchitecten voor hun eigen belang opkomen, heeft volstrekt gelijk. Dit pleidooi voor erkenning van de aparte rol van de informatiearchitect moet echter vooral beoordeeld worden, en als het lukt graag zo rationeel mogelijk, als bijdrage aan kwaliteit van informatievoorziening.
© 1996, webeditie 2002.
Eerder verschenen in: Informatie ,jaargang 40,
november 1998 en Informatiekundige ontwerpleer
(Ten Hagen Stam, 1999).