Generiek |
maandag, 3 mei 2004 |
Programmeurs hebben een hekel aan programmeren.
Dat lijkt wat tegenstrijdig, maar toch is het zo.
- Programmeurs zijn dol op korte code.
Ze kunnen hun lol niet op als ze een stel {} weg kunnen laten.
- Programmeurs houden namen van variabelen, methods, tabellen en kolommen het liefst tot één letter beperkt.
Dat levert seconden winst op bij het ontwikkelen maar kost uren aan extra inspanning in de onderhoudsfase.
Dat is niet erg, want programmeurs puzzelen graag.
Liever een uurtje puzzelen dan een paar seconden typen.
Gefeliciteerd.
Dezelfde puzzel-type tegenstelling zie je terug in het groot.
Een programmeur die 2x een soortgelijk statement moet intypen gaat onmiddellijk een uurtje puzzelen.
Stel je eens voor dat je een paar seconden zou verspillen om een derde soortgelijk statement te typen!
Dat kan natuurlijk niet.
De oplossing is maar al te vaak iets generieks.
- Dat is prima als het een herbruikbare
method
is, of een prettige superclasse met grote kans op
inheritance.
- Echter...
de droom van programmeurs is om
helemaal niet meer
te hoeven programmeren.
- En jawel, daar komt de generieke oplossing!
De generieke oplossing
De generieke oplossing is meestal iets met parameters in een bestandje of database tabel.
Het is best ingewikkeld om zoiets generieks te bouwen.
Het is een heerlijke puzzel dus programmeurs zijn er dol op.
Aan de projectleider verkopen ze het met als argument:
Het gaat ons in de toekomst veel tijd besparen
.
Niemand rekent uit hoeveel seconden typwerk het werkelijk bespaart, dat zou alle puzzelpret maar bederven.
Het enthousiasme is groot, de generieke oplossing komt.
Schuiven
Oeps, iemand moet het bestandje of de tabel gaan vullen.
Helaas blijkt dat vervelend typewerk te zijn, wat weer seconden kost.
De oplossing is eenvoudig: We schuiven dat typewerk naar een beheerder.
Die beheerder krijgt de generieke oplossing wat koud op zijn dak.
Tien tegen één dat de oplossing slechts geschikt blijkt voor programmeurs.
Er moet een korte opleiding bij en iemand moet een gebruiksaanwijzig schrijven.
He bah, weer vervelend typewerk.
In productie
Uiteindelijk, met veel pijn en moeite gaat de generieke oplossing werken.
Het is een heel gedoe, want de testinspanning blijkt meer dan verdubbeld:
- Zit een bug in de parameters?
- Of toch in de generieke software?
Uiteindelijk gaat de boel in productie.
Niemand rekent na hoeveel tijd er besteed is aan de generieke oplossing.
Over de oorspronkelijke seconden typewerk hoor je helemaal niemand meer.
De praktijk
De praktijk blijkt weerbarstiger dan gedacht.
Er komen allerlei uitzonderingen boven die de generieke oplossing steeds minder generiek maken.
De set van parameters gaat steeds meer op een aparte programmertaal lijken.
De oorspronkelijke programmeurs hebben inmiddels plaats gemaakt voor nieuwe.
Voor hen is de generieke oplossing alleen maar lastig,
een YAPL (Yet Another Programming Language):
- Iets extra's om te doorgronden.
- Iets extra's om aan te passen bij wijzigingen.
- Iets extra's om te testen.
- Iets extra's om in productie te brengen.
- Kortom iets extra's wat mis kan gaan.
De cyclus
Na een jaar of 3 is de hele ontwikkelomgeving en programmeertaal verouderd.
De toekomst bleek korter dan gedacht.
De hele boel gaat het ronde archief in, maakt plaats voor iets nieuws.
De besparingen zijn nooit gehaald.
Niemand weet zich nog het oorspronkelijke argument van tijdsbesparing te herinneren.
En dat is misschien maar beter ook...
De programmeurs werken met hun nieuwe omgeving.
En... merken dat ze telkens hetzelfde zitten te typen.
Hmm, zou dat niet generiek opgelost kunnen worden?
Advies
Wil een programmeur een generieke oplossing?
- Vraag hoeveel seconden tijdsbesparing het op gaat leveren in de komende 3 jaar.
Is het minder dan zeshonderdduizend?
Niet doen, gewoon blijven typen!
- Vraag hoeveel dagen die generieke oplossing gaat kosten aan documentatie, overleg met beheerders, opleiding van nieuwe programmeurs en opvangen van toekomstige uitzonderingen.
Is het in seconden meer dan de besparing op typewerk?
Niet doen, gewoon blijven typen!
Tot
de volgende, handgetypte noot,
Henk Jan Nootenboom
