The mythical man month is een absolute all-time klassieker op het gebied van software management. Het boek stamt uit 1986 maar een groot deel is zo actueel als het maar kan. En het boek begint met een Neerlandsch gezegde: ?¢‚Ǩ?ìEen schip op het strand is een baken in zee.?¢‚Ǩ¬ù (?)
Brooks valt meteen met de deur in huis door een statement te maken dat wij allen projectleiders, teamleiders etcetera al lang vermoeden, maar moeilijk uit kunnen leggen, al helemaal aan onze opdrachtgevers. Het gaat ongeveer als volgt:
– je hebt een software programma; dat is wat een beetje programmeur best handig in elkaar kan knutselen
– je hebt een software product; dat is een programma, met handleidingen, documentatie, getest en al, klaar om te distribueren, met readme’s, disclaimers en wat dies meer zij
– je hebt een software systeem bestaande uit allerlei componenten die met elkaar moeten praten, samen moeten werken, onder een architectuur moeten fungeren etcetera
Een software product kost drie keer zoveel tijd en geld als een softwareprogramma. Een softwaresysteem kost drie keer zoveel tijd en geld als een softwareprogramma. Een softwaresysteem dat als gereed product moet fungeren kost negen keer zoveel tijd en geld als een softwareprogramma. Wat fijn om dat eens te kunnen uitleggen iedere keer als iemand roept: ?¢‚Ǩ?ìdat kun je toch zo wel even programmeren??¢‚Ǩ¬ù
Brooks stapelt de ene na de andere waarheid op. Zo doet hij de volgende magische uitspraken:
– I will contend that conceptual integrity is the most important consideration in system design.
– Adding more manpower to a late software project makes it later (dus niet: ?¢‚Ǩ?ìdan zetten we toch wat mannetjes erbij??¢‚Ǩ¬ù)
– En: de verdeling van de bouw van software is ongeveer: 1/3 ontwerp, 1/6 programmeren, 1/4 component testen, 1/4 systeemtesten. Waarom zie ik altijd in offertes staan 1/6 ontwerp, 2/3 bouw, 1/6 testen?
Brooks is zelfs manager geweest van softwaretrajecten bij IBM. Dat was een aardige leerschool en hij is ook zeker niet te beroerd om zijn eigen fouten toe te geven. In plaats van een genuanceerd beeld, lukt het Brooks toch om heel scherp te blijven. Het boek staat (bewust) vol met boude uitspraken en alhoewel je af en toe wel eens denk ?¢‚Ǩ?ìnou, dat valt toch wel mee?¢‚Ǩ¬ù, is het verfrissend om te lezen (let wel: 1986).
Brooks heeft zo zijn beelden over welke documentatie er moet zijn in een project, de salari?ɬ´ring en carrieremogelijkheden van techneuten ten opzichte van managers en nog veel meer zaken. Hij is bekend geworden door nog wat statements:
– Question: how does a project get to be one year late? Answer: one day at a time. Tijdens een project komt het continu voor dat een vergadering niet doorgaat, dat iemand ziek is, dat iets een dagje te laat is etc. etc. Het is door dit soort dingen dat projecten gigantisch uit kunnen lopen en niet altijd door grote ontwerpfouten of misvattingen. Met andere woorden: die dag vertraging is wel belangrijk en je moet er dus op letten dat dat niet gebeurt!
– plan to throw one away: als je een systeem gaat bouwen, ga ervan uit dat je een versie moet weggooien. Te vaak zie ik dat een zogeheten proof of concept ineens een productiesysteem moet worden met alle rampen van dien.
In 1986 verscheen ook het essay ?¢‚Ǩ?ìNo Silver Bullet?¢‚Ǩ¬ù waar hij zich de woede van menig softwaregoeroe mee op de hals haalde. De nogal suggestieve titel leidt naar het statement dat er in de komende tien jaar tijd geen wonderen verwacht hoeven te worden op het gebied van productiviteit bij softwarebouw. Brooks stelt dat de meeste efficiencyslagen op het gebied van de bouw zelf wel geweest zijn (3gl programmeertalen, hardwareverbeteringen, ontwikkelmethodieken) en dat de enige echte winst nog te halen is in de conceptuele en ontwerpfase. Waarna vervolgens jaren lang allerlei types kwamen met een bewering waarom hun methodiek, programmeertaal, tool, architectuur e.d. wel tot een vertienvoudiging van de productiviteit zou leiden.
In mijn editie van het boek uit 1995 kijkt Brooks nog eens terug, wat er van zijn aloude beweringen uit ?¢‚Ǩ?ìno silver bullet?¢‚Ǩ¬ù en ?¢‚Ǩ?ìthe mythical man-month?¢‚Ǩ¬ù overblijft. Veel. Een deel van de hoofdstukken uit the mythical man-month gaan over echt technische dingen. Zo is er het statement dat je bij het ontwerp van een systeem van te voren targets moet stellen voor het geheugengebruik van de verschillende componenten. Dat is.. laten we zeggen.. wat verouderd.
Veel managementbeweringen echter zijn volgens mijn onverminderd van kracht en Brooks komt ook wel ongeveer tot die conclusie, maar is nog wat kritischer naar zichzelf.. Een punt is dat er veel meer gebruik wordt gemaakt van pakketsoftware dan midden jaren 80. Dit zou je als een enorme productiviteitsverbetering kunnen zien.
En net als je denkt dat je klaar bent volgt er nog een prachtige verhandeling over programmeerteams en wat er voor nodig is om die goed te laten werken.. ik heb gesmuld..