Hjem / Anmeldelser, Edb/It / The Mythical Man-Month

The Mythical Man-Month

The Mythical Man-Month

Frederick P. Brooks, Jr., Addison-Wesley 1995

 

Vi fortsætter traditionen med at anmelde lidt gamle bøger her i firmaet, selv om jeg denne gang vil gå til yderligheder. Bogen, jeg vil anmelde, udkom nemlig i 1975. Der kom dog en opdatering i 1995, og det er så den, jeg nu har fået læst. Det drejer sig om The Mythical Man-Month, som er en samling ret uafhængige essays.

Hvis I ikke kende Brooks, så kender I i hvert fald Brooks' lov, der netop stammer fra denne bog: Adding manpower to a late software project makes it later. Om ikke andet, så kender I loven af erfaring.

F. P. Brooks er en ældre herre, 78 år (han havde fødselsdag i søndags), der har været med i edb-udviklingen næsten siden tidernes morgen. I skrivende stund lever han i bedste velgående og er stadig aktiv. Han var med i udviklingen af system/360 og ledede udviklingen af OS/360.

Bogen er interessant som historisk læsning – det er spændende at læse om udvikling og debugging på maskiner uden timesharing, dels er den på en del punkter stadig aktuel. Også selv om der er sket en del siden 1975/1995.

Jeg vil undlade et systematisk referat af bogen, læs den i stedet, og nøjes med at nævne nogle af de vigtigste kapitler. Brooks beskæftiger sig hovedsageligt med systemprogrammering; hvordan man skriver operativsystemer, men hans erfaringer er ofte generelle.

Det første kapitel er ”The Tar Pit” om hvorfor ting tager så lang tid at lave – men også om glæderne ved at programmere – om at skabe (noget nyttigt).

”The Mythical Man-Month”, der definerer Brooks' lov, skal også nævnes og læses. Loven er vel ikke absolut, som det bemærkes i et senere og nyere kapitel, men helt ved siden af er den ikke. For når man tilfører et projekt mere arbejdskraft (jeg kan altså ikke fordrage udtrykket ”ressourcer” - Brooks bruger det heller ikke), så skal der tages tid fra til at lære de nye folk op. Og tid fra til at koordinere mellem flere personer. Derfor går det galt.

Han har selvfølgelig også en del kapitler om systemudvikling, hvordan man organiserer det bedst. Bl.a. foreslår han til udvikling af større komplekse systemer en organisering som et kirurgisk hold, hvor én skærer, og de andre har støttefunktioner. Kommunikation mellem grupper og arkitekter er også et emne, der behandles. Der mangler her e-mail og web, men det kommer i 1995-tilføjelserne.

Kapitlet ”Ten Pounds in a Five-Pound Sack” er ikke blevet uinteressant i dag, selv om vi har betydeligt mere lager at brede os på. Det er også interessant, hvad udviklere kan gøre for at holde sig inden for pålagte lager-restriktioner – og hvilke græsselige konsekvenser det kan have mht. swapping. Programmer, der bruger for meget lager, er også i dag et problem, ved vi. Men stort lagerforbrug er ikke nødvendigvis problematisk, bare det går til det rigtige.

Mere tvivlsom er hans ide om altid at lave alting to gange og så smide første udkast væk. Det går han da også væk fra i sine 1995-kommentarer. Afsnittet om forekomsten af fejl i et produkt, siden det går i produktion, er nok stadig interessant. Det begynder nemlig at stige igen, efter at være startet med et fald, efterhånden som programmet ældes.

Kapitlet ”Hatching a Catastrophe” handler om, hvordan et softwareprojekt bliver forsinket. Nemlig én dag ad gangen. Og om hvordan ledelsen bør agere for at undgå at blive ført bag lyset af nervøse mellemledere.

Kapitlerne om dokumentation er heller ikke uinteressante, selv om noget er forældet teknologisk. Rutediagrammer kan han ikke lide. De bliver i øvrigt først lavet til sidst, hvis kunden kræver det. Og det gjorde det amerikanske militær dengang.

”No Silver Bullet – Essence and Accident in Software Engineering” (fra 1986) er en klassiker, der ofte henvises til i litteraturen. I det argumenterer han for, at uanset hvad man gør mht. nye metoder, værktøj og teknikker, så vil der ikke de næste ti år opnåes en ti-fold forbedring af udvikler­produktiviteten, modsat den udvikling man har set inden for hardware. Problemet er, at en stor del af indsatsen ligger på at definere programmerne, ikke på at implementere dem. Kun hvis mindst 9/10 af arbejdet ligger på implementeringen og kun hvis det kan bringes nær nul, kan man det. Og på det sidste område, er de nemme gevinster allerede taget. Nogle har set artiklen som uhørt pessimistisk og har argumenteret imod den. Andre har set den som realistisk. Men ingen har kunnet præstere den ønskede produktivitet. I et følgende og nyere afsnit vender han tilbage til artiklens påstande og den debat, den medførte. ”No Silver Bullet” er i sig selv værd at læse.

Hans kapitel om ”Tyve år efter” er også værd at se på. Her gennemgår han og opdaterer nogle af sine påstande fra dengang. Bl.a. havde han i 1975 argumenteret for, at udviklerne skulle have adgang til at vide alt, som de andre går og laver i projektet. Nu mener han, at de kun skal have adgang til interfacet til de andres moduler – information hiding. Og vandfaldsmodellen kasserer han nu til fordel for en inkrementel udviklingsmodel.