Boken The Mythical Man Month
Introduktion
Jag läste just om The Mythical Man-Month - Essays on Software Engineering av Frederick P. Brooks från Addison-Wesley Educational Publishers Inc med ISBN 9780201835953. Den är ursprungligen från 1975, men detta är en nyutgåva från 1996. Den kostar just nu cirka 250 kr på Adlibris (se [1]), eller cirka 27 USD på Amazon (se [2])
Den har otroligt positiva recensioner på amazon: 4,5 av 5 stjärnor och av mer än 250 betyg så ger 70% den full pott. De positiva recensionerna den får handlar om igenkänning och att man kan lära sig hur man kan driva mjukvaruprojekt av att läsa den. De negativa menar att den inte är så tidlös som många anser. En av de som gett den minsta betyget kallar den "Outdated, sexist, unnecessarily religious, and often wrong."
Överblick
Boken är skriven av Fred Brooks som bossade över utvecklingen av ett operativsystem på 1960-talet. Framförallt handlar boken om vad som gick dåligt och det spekuleras en hel del i hur man borde göra för att mjukvaruprojekt ska gå bra. Boken är ursprungligen från 1975, med tillägg både på 1980-talet och 1990-talet.
En hel del så kallade anti-patterns är med i boken - av dessa är den mest kända Brooks lag: tillförs folk till ett försenat mjukvaruprojekt så blir det ännu mer försenat (adding manpower to a late software project makes it later).
För den som kanske jobbat en del i mjukvarubranschen kan man lista ut vad kapitlen handlar om av deras namn. Kapitlen är egentligen essäer, som undertiteln antyder Essays on Software Engineering. Essäerna äro:
- The Tar Pit
- The Mythical Man-Month
- The surgical Team
- Aristocracy, Democracy and System Design
- The Second-System Effect
- Passing the Word
- Why Did the Tower of Babel Fail?
- Calling the Shot
- Ten Pounds in a Five-Pound Sack
- The Documentary Hypothesis
- Plan to Throw One Away
- Sharp Tools
- The Whole and the Parts
- Hatching a Catastrophe
- The Other Face
- No Silver Bullet - Essence and Accident
- "No Silver Bullet" Refired
- Propositions of the Mythical Man-Month: True or False?
- The Mythical Man-Month after 20 years
Negativt
Boken har många bra lärdomar i sig. Men en del av dessa var felaktiga eller dåligt nyanserade i den ursprungliga texten från 1975. I tillägget 1995 ändrade han sig lite, vissa saker av det han tyckte 20 år tidigare håller han inte med om längre. Men. Det författaren då gjort är att lägga in rättningarna i ett kapitel sist i boken istället för att baka in det i kapitlen, eller kanske lägga det som ett appendix till varje essä. Lite klumpigt och drygt.
En annan sak är att man kräks och sväljer lite av uttryck som hyllar gud i förordet, eller att hans fru är en gåva till honom från gud. Ett till exempel är att ett bra team består av två personer där den ene är chef - precis så som gud ville ha det i äktenskapet. Vissa attityder har inte åldrats med värdighet.
En till sak som är lite tradig, men ibland kul som kuriosa, är hur han refererar till tekniska detaljer som hur många ord en viss dator hade som minne, eller att det är sååå jobbigt att Word 6.0 kräver 4 megabyte RAM.
Men det jag tycker är mest tradigt är att så mycket text går åt till att försöka visa att en förutsägelse från mitten av 1980-talet visade sig sann på 1990-talet. I stora drag var, och är, hans resonemang OK. Förutsägelsen är kärnan i kapitlet No Silver Bullet: "ingen enskild utveckling inom teknik eller ledarskap kommer under det kommande decenniet i sig självt att förbättra produktivitet, tillförlitlighet eller enkelhet med en faktor tio" (there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity).
Positivt
Det är väldigt mycket som är positivt med boken. För det första är den ett extremt intressant tidsdokument om hur stora mjukvaruprojekt kunde gå till på 1970-talet (och han nämner även lite om stora mjukvaruprojekt från 1950-talet). Man blir också ödmjuk inför att läsa om ett så stort projekt som sen inte fick ett bra resultat - operativsystemet som är som en ramberättelse i boken blev ingen succé, som jag förstår det blev det tvärt om ganska kasst. Det är en av de stora behållningarna av att läsa boken: att få reda på vad som kan gå dåligt. Men trots det upprepas deras misstag ofta och det är därför Boken The Mythical Man Month ofta kallas "The Bible of Software Engineering" därför att "everybody quotes it, some people read it, and a few people go by it".
Jag blir ofta glad när jag läser den, jag känner igen mig i situationer och ibland håller jag verkligen, verkligen med Brooks.
Vad tar jag med mig?
Några av de lärdomar som boken tar upp (jag översätter här i princip från Engelska Wikipedia, se [3]) är
- Konceptuell Integritet: Det som Fred Brooks trycker mest på är att ett system måste ha konceptuell integritet. Det får man bara om man särar på arkitektur och implementation. Helst ska man bara ha en arkitekt.
- The Mythical Man-Month: Kommunikation är svårt och det finns ett optimum över antal personer i ett projekt. Är man färre tar det lång kalendertid, blir man fler så äts effektiviteten upp av kommunikation. Ju fler individer i ett projekt - desto fler möjliga kommunikationskanaler finns.
- No Silver Bullet: Ingen ny teknik eller metod kommer ge en förbättring med en faktor tio. Trots det verkar många tro det, då, och nu. Jag tänker på övertro till olika tekniker, till exempel Scrum. I ett av appendixen där han diskuterar olika potentiella silverkulor så citerar han till min stora glädje Capers Jones: "No. Focus on quality, and productivity will follow." Tanken här är att dåligt kvalitet leder till förseningar, missförstånd och dålig underhållbarhet. Med bra kvalitet från början så kanske man sparar en faktor 10 på sikt. Capers Jones är för övrigt en av författarna till Boken The Economics Of Software Quality.
- The Second-system effect: Det andra systemet blir ofta bloatat eftersom man frestas att inkludera allt skräp som man inte hade tid för i första versionen.
- Hur kan ett mjukvaruprojekt bli ett år sent? Jo, en dag i taget. Man behöver små milstenar i projektet för att inte glida för mycket.
- Manualen: I ursprungstexten trycker han på att alla måste ha tillgång till all dokumentation i systemet. Han berättar att de underhåller manualer och trycker en hel massa papper till olika kontor. I appendixet ändrar han sig och talar istället för moduler med väl definierade interface. Jag tänker objekt-orienterad programmering och publika, privata och så vidare metoder. I en annan essä nämner han att mjukvarufolk ogärna dokumenterar sin implementation, för då kan man bli ifrågasatt.
I ett av appendixen talar han sig varm om iterativa utvecklingsmetoder, nattliga byggen, att känna till sina användare och kvantifiera vilka delar av mjukvaran de kommer använda mest.
Någonstans nämner han att kod kan vara självdokumenterande och visar lite fruktansvärd kod som luktar pre-C med sträck i marginalen för att illustrera vad olika goto's gör. Exemplet fick mig att associera till Python Doctest And Docstring som är lite åt samma håll. På samma tema nämner han även att kodmoduler borde komma med dokumentation och testfall som visar hur den funkar. Till min stora glädje har man tänkt på vanlig klassisk happy-day testing (positiva testfall), samt negativ testning (för att visa hur felhanteringen går till), och testfall för att undersöka var randen av tillåtna indata finns.
Sammanfattning
Boken The Mythical Man Month är en brutalt bra bok - en klassiker. Alla som på något sätt jobbar med mjukvara borde läsa den. Minst två gånger.
Tillhör Kategori Boktips