Per Erik Strandberg /cv /kurser /blog

http://www.pererikstrandberg.se/blog/the-mythical-man-month.jpg

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:

  1. The Tar Pit
  2. The Mythical Man-Month
  3. The surgical Team
  4. Aristocracy, Democracy and System Design
  5. The Second-System Effect
  6. Passing the Word
  7. Why Did the Tower of Babel Fail?
  8. Calling the Shot
  9. Ten Pounds in a Five-Pound Sack
  10. The Documentary Hypothesis
  11. Plan to Throw One Away
  12. Sharp Tools
  13. The Whole and the Parts
  14. Hatching a Catastrophe
  15. The Other Face
  16. No Silver Bullet - Essence and Accident
  17. "No Silver Bullet" Refired
  18. Propositions of the Mythical Man-Month: True or False?
  19. 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

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