(warning Dutch content ahead)
Voor de verandering weer eens een technisch artikel op mijn geliefde blog, maar wel in het Nederlandsch. In een tweet maakte Nils_R mij attent op een artikel genaamd Liever geen Inversion of Control waarin Ralf Wolter zegt:
Ik ben tegen de Spring manier van ontwikkelen! Ik heb een hekel aan het zogenaamde ‘inversion of control’ (IoC)!.
Ik ken Ralf redelijk en hij werkt bij Sogyo, ook al niet de minste van de Nederlandse IT dienstverleners. Ik hou van mensen met een uitgesproken mening (daar zijn er sowieso veel te weinig van), vandaar dat ik het artikel dat Ralf oktober afgelopen jaar schreef wel kan waarderen. Ik had er tot nu toe eigenlijk nog nooit op gereageerd en nu Nils_R me erop wees en ik op het fantastisch mooie vliegveld van Tel Aviv toch niks anders te doen had, dacht ik dat het er tijd voor was. Dus Nils_R (en voor overige geïnteresseerden) hierbij mijn reactie 
.
Ford met z’n Model T auto
Maar… eerst een verhaaltje: bijna 100 jaar geleden (September 1908 om precies te zijn) bracht Henry Ford zijn eerste Ford Model T (ook wel Tin Lizzie genoemd) op de markt. Zoals waarschijnlijk wel bekend, werd de Model T de eerste op zeer grote schaal geproduceerde auto. De vraag naar auto’s steeg tijdens de begindagen van de Model T enorm. Auto’s werden voor meer mensen dan alleen de elite bereikbaar.
Henry Ford had moeite om aan de vraag te voldoen. In de eerste maanden dat de Model T werd geproduceerd werden er slechts 11 auto’s per maand geproduceerd. Dit alles gebeurde in de fabriek van Ford op Piquette Avenue in Detroit. In 1910 waren er ’slechts’ 12.000 Model T Ford auto’s geproduceerd en dat was het moment dat Henry Ford de productie verplaatste naar het Highland Park Complex, waar tot op de dag van vandaag de archivering plaatsvindt voor Ford.
In het Highland Park Complex werd de assemblagelijn ontwikkeld. Henry Ford deed dit niet zelf, het was een van zijn medewerkers die in een fabriek in Chicage een straat gezien had die kippen deassembleerde. De deassemblage (klinkt mooi, niet waar?) van de kip gebeurde in deze fabriek op een gecontroleerde manier, stapje voor stapje en volledig automatisch. Ik moest zelf toen ik dit las denken aan een vriend van mijn ouders, die zelf jarenlang erg succesvol in kippen handelde en de meest gruwelijke verhalen kan vertellen over hoe kippen middels uitbeenmachines, ontbeenmachines en nog veel meer machines met gruwelijke namen uit elkaar gehaald worden. Met meesterlijke efficiëntie worden miljoenen kippen (gok ik zo) per dag ge-deassembleerd. Okay, genoeg off-topic. De persoon die de deassemblagelijn zag dacht: als we dat nou in omgekeerde volgorde doen (assemblage in plaats van deassemblage) maar dan voor autos… Het was dus niet Henry Ford zelf die de assemblagelijn introduceerde, maar goed, hij was wel degene die de gok durfde te nemen deze revolutionaire manier van produceren uit te proberen.
Fast forward naar 1914. Dit was het jaar dat er elke 93 minuten een Model T Ford van de band rolde. Een paar jaar eerder waren dit er slechts 11 per maand geweest. Als je ervan uitgaat dat men 8 uur per dag en 5 dagen per week assembleert betekent dit dat Ford meer dan 10 keer zoveel auto’s kon produceren per maand (als je meeneemt dat er gemiddeld 21 werkdagen in een maand gaan). De assemblagelijn had z’n succes bewezen! Natuurlijk was niet alleen de assemblagelijn de grote reden dat er elke 93 minuten een Model T Ford van de band rolde. Ook de introductie van de 5 daagse werkweek en het vaste loon, onafhankelijk van de ‘productie’ van medewerker waren belangrijke factoren die meehielpen bij een snelle productie van de Model T Ford. Die Henry Ford was een visionaire man!!
Even iets dieper inzoomend op de assemblagelijn. Deze lijn klikt verschillende onderdelen aan elkaar, om uiteindelijk een auto te fabriceren. De onderdelen zelf zijn op een ander tijdstip gemaakt en zijn zo gemaakt dat ze op andere onderdelen aansluiten (boutjes, moertjes, schroefjes, pasvormen). Zo zal een kogelvrije voorruit voor een Model T Ford (zouden ze die toen al gehad hebben?) dezelfde vorm gehad hebben als een voorruit waarmee de gewone man het moest doen. Ditzelfde geldt voor de wielen. Winterbanden (nee, die hadden ze toen zeer nog niet, gok ik) zul je op ongeveer dezelfde manier op de Model T Ford gezet hebben als normale banden.
Als eerste kunnen we observeren dat de assemblage van de verschillende componenten waaruit de auto bestaat volledig en voor 100% losgekoppeld is van het het daadwerkelijk functioneren van deze componenten. Dit is logisch lijkt me. Een cake bakt zichzelf niet, daar heb je een recept voor nodig en iemand die de eieren, bloem, suiker en dergelijke voor door de mixer haalt en in de oven zet. Een huis bouwt zichzelf niet, daar heb je architecten voor nodig die een bouwtekening maken, metselaars en timmermannen en bouwopzichters. Een auto bouwt zichzelf niet, die wordt geassembleerd.
Een interessante vraag is waarom die assemblagelijn nou eigenlijk zo succesvol is? De algemene consensus hierover is dat specialisatie efficientie bevorderd. Als je je als persoon ergens in specialiseert wordt je er beter in. Dat kunnen we ook over machines zeggen. Als je een machine bouwt die specifiek moertjes op boutjes draait, zal het gemakkelijk zijn deze machine hierop te specialiseren.
De algemene consensus binnen de productiewereld is naar mijn weten ook, dat het zich specialiseren ingeval van mensen ook nadelen heeft. Overspecialisatie kan leiden tot mensen die hun werk saai gaan vinden, specifieke blessures krijgen door zich te vaak repeterend werk (RSI, anyone). Vandaar dat later eilandproductie werd uitgevonden en roulatie werd ingevoerd van activiteiten die mensen in een productieproces uitvoeren. Dit is tenminste wat ik me kan herinneren van de lesjes productieprocesleer die ik in een ver verleden gehad heb. Overspecialisatie is echter een volledig andere discussies.
Separation of Concerns
Laten we bij nog even bij assemblagelijn blijven. Het onderliggende principe van de assemblagelijn is dus specialisatie. Vrijvertaald zou je die specialisatie ook een goed voorbeeld kunnen noemen van het “Separation of Concerns” principe (voor de ingewijden: denk nou niet meteen aan AOP, daar gaat dit artikel niet over). Dit principe werd al in 1975 belicht door onze vriend Edsger Dijkstra, nog steeds een van de belangrijkste en invloedrijkste computer scientist ooit. In zijn paper On the Role of Scientific Thought beschrijft Dijkstra dit concept als volgt:
“Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained –on the contrary!– by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns”, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts, that I know of. This is what I mean by “focussing one’s attention upon some aspect”: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
Met andere woorden; het zich richten op één deelprobleem tegelijkertijd zorgt voor een efficienter en gemakkelijker manier van het oplossen van een groter probleem.
Dit is exact wat er in de assemblagelijn ook gebeurt. Door verschillende delen van de assemblagelijn zo in te richten dat ze elk één klein deel probleem oplossen (het op de auto schroeven van de banden, het plaatsen van het motorblok) en de assemblage in z’n geheel los te koppelen van de eigenlijke functie van de auto, wordt het mogelijk om:
- Elke individuele stap in de assemblage te optimaliseren
- Elke individuele stap in de assemblage te beschrijven en herhaalbaar te maken zodat bij het inrichten van een nieuwe assemblagelijn er slecht een copy-paste actie uitgevoerd hoeft te worden
- De individuele stap te observeren ten einde kwaliteitstestjes in te voeren die specifiek gericht zijn om deze stap in het proces te controleren (is deze schroef wel goed vastgedraaid)
- Ten einde het hele proces van het in elkaar zetten van een auto (bijna) oneindig veel te optimaliseren en controleren
Applicatieassemblage
Okay, terug naar de IT, want al die auto’s, dat is wel leuk, maar daar waren we hier niet voor, toch Nils? Ik ben een groot voorstander van de mensen die roepen dat softwareontwikkelaar een art is… een vak wat je tot op zekere hoogte kan leren, maar mits goed uitgevoerd kunstig mooie creaties op kan leveren. Ik kan de term softwarecreatie dan ook veel meer waarderen dan de term softwarebouw. Nou is de vraag waar in de creatie van de software dit creatieve zich nou precies afspeelt. Het creatieve en tegelijkertijd het complexe speelt zich af in de plaatsen waar de software daadwerkelijk iets doet, in de onderdelen die de eisen en wensen van de klant implementeren. We hebben allemaal geleerd dat object-orientatie een goede manier is om een model te bouwen waarmee we de problemen van de klant kunnen oplossen (lees hiervoor verder over de definitie van modellen). Wat voor model? Een model dat de echte wereld (de wereld waarin het probleem van de klant zich afspeelt) weerspiegelt.
Laten we nog even kijken naar de auto: die bestaat uit een (zeer grote) verzameling onderdelen die allemaal een belangrijke rol spelen in het laten rijden van de auto. De auto dient geassembleerd te worden. We zouden middels object-orientatie ook de auto kunnen modelleren (public class Wiel {}, public class Engine{}, public class Car{}) , maar als we dat doen, dan moeten we nog wel iemand hebben die voor ons die auto (de applicatie) assembleert.
Als je assemblage als centrale analogie neemt voor het creeëren/bouwen van een auto als je het hebt over het creeëren/bouwen van software, kun je wat mij betreft geen andere conclusie trekken dan dat diezelfde assemblage, maar dan die van een applicatie uit verschillende onderdelen (instanties van types) een absolute must is in plaats van die verantwoordelijkheid bij de applicatie zelf te leggen (kortom: een auto assembleert zichzelf ook niet). Dit is wat mij een goed argument om de discussie rondom Dependency Injection mee te concluderen.
Welk probleem wordt er nou eigenlijk opgelost?
Ralf Wolter zegt ergens halverwege z’n artikel het volgende: “De complexiteit van de applicatiekern is echter niet signifikant kleiner. Nog steeds verhoogt elk component de complexiteit van onze kern. In het plaatje hierboven brobeer ik dit weer te geven. Het gearceerde gedeelte is nauwelijks kleiner dan in het vorige plaatje [Ralf gebruikt plaatjes om de complexiteit van een applicatie weer te geven]. Dit is mijn belangrijkste bezwaar met IoC. Het lost het verkeerde probleem op.”
Ironisch genoeg denk ik dat Ralf de spijker op z’n kop ramt hier! Ralf vindt dat IoC het verkeerde probleem oplost. De rest van het artikel gaat Ralf volgens mij in op de manier waarop componenten in een applicatie met elkaar praten. Het lijkt erop alsof hij in de rest van zijn artikel praat over event-driven applicaties. Ik kan niks anders dan concluderen dat Ralf denk dat Inversion of Control het probleem van de communicatie tussen verschillende componenten probeert op te lossen. Als dat inderdaad zo is, dan ben het volledig met hem eens: Inversion of Control verlaagt de inherente complexiteit van logica in applicaties niet. Deze logica was complex, is complex en zal altijd complex blijven. Lees alsjeblieft Fred Brooks’ Mythical Man Month alvorens te proberen hierover een discussie aan te gaan… hell, als je Mythical Man Month nog niet gelezen hebt en je hebt ook maar een klein beetje te maken met software ontwikkeling, stop nu met het lezen van deze blog entry, ga naar de dichtbijzijnde Amazon.com winkel, haal deze klassieker op en lezen maar! Het lijkt mij volledig logisch dat je de creatie van complexere logica in de vorm van componenten loskoppelt van de meer mundaine taken als het assembleren van deze creatieve onderdelen tot één applicatie. Maar daar bovenop, stelt het ons in staat die assemblage op een efficientere en productievere manier te doen, in plaats van hier kostbare ontwikkeltijd aan te besteden. Het blijft natuurlijk de verantwoordelijkheid van de applicatieontwikkelaar zelf (of in geval de analogie de bouwer van de voorruit of die nou kogelvrij is of niet) om te zorgen voor de constructoren, setter methods (de vorm van de voorruit) die het mogelijk maken om het component (de voorruit) in de assemblage te gebruiken om uiteindeijk tot een applicatie te komen.
Dependency Injection lost het probleem op van de assemblage van een applicatie, niet van de gedrag van deze componenten zelf waaruit deze applicatie bestaat, of de communicatie tussen deze componenten. Separation of Concerns is een goed principe en ik zou bijna zo arrogant willen zijn door te zeggen dat niemand zou meer een applicatie moeten willen bouwen zonder zich op één deelprobleem tegelijkertijd zou moeten focusen en de individuele componentjes die deze deelproblemen oplossen te assembleren door middel van Dependency Injection.
Ik bedenk me nu ineens dat Arjen zich vast nu over z’n kin wrijft en denkt : “Waar ga je heen jongen, toch niet richting de eeuwige belofte van de component-assembler?” Nee Arjen, maak je geen zorgen, hier geloof ik nog steeds niet in. Maar dat ter zijde.
Een paar opmerkingen voordat ik ‘dag’ ga zeggen. Ik begon dit artikel te schrijven toen ik op het Ben Gurion vliegveld van Tel Aviv zat. Inmiddels zit in het vliegtuig en we hebben heldere uitzichten ingewisseld voor een dik wolkendek. Gelukkig vlieg ik daar nu nog boven, dus zonnig is het (nu) nog wel. Ik kom er net achter dat in dit artikel niet één keer Spring heb vermeld. Het is dan ook een artikel dat zich niet richt op het nut van Spring. Het is een artikel wat zich richt op het nut van Dependency Injection, of je dat nou doet met Spring, PicoContainer, Google Guice, Plexus of custom configuratie code. Zo lang je assemblage maar als een apart traject beschouwt ben je goed af! Of je het nou in XML doet of Java, met Properties-files of met een scripting language, dat maakt niet uit! Of anders gezegd: dat is niet het onderwerp van deze discussie.
Hoe je die assemblage dan precies vormgeeft is natuurlijk vraag twee. Als je gelooft in de kracht van een analogie zou je nu al kunnen concluderen dat een wereldwijd geaccepteerd manier van het assembleren van autos (waarin er misschien slechts 10 varianten bekend zijn voor elke autofabrikant eentje) beter is dan het met-het-handje assembleren van de applicatie. Ten slotte ‘deed’ Ford zonder assemblagelijn 11 Model T Fordjes per maand en deed hij er één per 93 minuten toen de assemblagelijn algemeen geaccepteerd en doorgevoerd was.
Ondertussen, Nils_R: bedankt voor de aanzet tot deze rebuttal. Lezers: hou Nils_R in de gaten (op www.nilsr.net ofzo)! Hij gaat leuke dingen doen! Z’n bedrijfsnaam (WaterCooler Topics) is in ieder geval al cool!
En nu met z’n allen weer lekker Spring XML typen!! 
… totdat JavaConfig uitkomt natuurlijk!
