Riittävän mielenkiintoinen opus, toisin kuin
Antipatterns mikä toistaiseksi on syönyt ihan kiitettävästi hermoja. Siinäkin on ihan jännää asiaa, mutta se on kirjoitettu silleen, kaiketi voitaisi sanoa että vähän turhan tieteellisesti.
Pikainen katsaus tuohon MM-M opukseen, eli:
The Mythical Man-Month - Essays on Software Engineering Anniversary Edition
Kirjoittanut: Frederick P. Brooks, Jr.
Anniversary Edition, eli kirjassa on muutama uusi kappale, ja vähän katsausta siihen miten hyvin väittämät ovat kestäneet ajan saatossa.
Käyn läpi hieman artikkeleita:
1: The Tar Pit vertaa järjestelmäohjelmointia tervahautaan, ja käy pikaisesti läpi ohjelmoinnin iloja ja suruja. Tämä asia on tuttua kaikille vähänkin ohjelmoineille, ja käy lähinnä jonkinlaisesta esipuheesta myöhemmälle materiaalille.
2: The Mythical Man-Month, eli titteliartikkeli. Otsikko tietenkin viittaa miestyökuukauteen mittayksikkönä sille miten kauan jonkin asian tekemiseen menee, ja siihen että jos useampi ihminen tekee jotain, niin se saadaan tehtyä nopeammin. Mielenkiintoisena huomiona Brooks sanoo että ohjelmoijat tahtovat olla luonteeltaan optimisteja, mistä seuraa että arviot siitä kauanko jonkin tekemiseen menee ovat usein arvioita, kauanko menee ilman bugeja ja viivytyksiä.
Tämä kappale käy läpi paljon sellaista "Projektinhallinnan perusteet" tyylistä asiaa pintapuolisesti, ja tästä kappaleesta löytyy se legendaarinen Brooksin laki:
"Adding manpower to a late software project makes it later."3: The Surgical Team
kuvaa sen, kuinka pieni tiimi eliittikoodereita tuottaa tehokkaasti ja nopeasti koodia verrattuna keskivertokoodereihin. Välittömänä huomiona Brooks kommentoi että tämä ei toimi supermassiivisten projektien kanssa, sillä pienille tiimeille tulee absoluuttinen resurssiraja vastaan: Vaikka yksi eliitti tekisi satakertaisen työpanoksen, niin silti 4000 kooderia tuottaa, kenties huonompaa koodia, mutta 40x nopeampaa.
Sitten käydään läpi Harlan Millsin ehdotelma projektiorganisaation rakenteesta, ja vähän mietitään kuinka se mahtaa toimia.
4: Aristocracy, Democracy and System Design
Tässä asiana on "Mitä useampi kokki, sitä huonompi soppa", ja puhutaan siitä kuinka yksi arkkitehti yli kaiken pitää projektin tavoitteet koherentteina, ja näin syntyy aristokraattistyyppinen hierarkia, jolloin ylhäältä tulee komento ja
koodiapinat koodaa.
5: The Second-System Effect
Toinen järjestelmä mitä tiimi x työstää on se vaarallisin, ja kaikista luultaviten "epäonnistuu" tai myöhästyy. Toiseen järjestelmään yleensä tungetaan ne mitkä eivät mahtuneet ensimmäiseen, tai sitten siitä yritetään tehdä liian hieno ja kaunis. Sitten käydään läpi mitä tälle tilanteelle voidaan tehdä.
6: Passing the Word
Tässä kirjan ikä näkyy, sillä tässä ihastellaan sitä kuinka digitaalinen dokumentaatio on parempi kuin printattu. Hieman jo pohditaan sitäkin, tarvitseeko kaikilla olla kaikki tieto? Toisaalta useampi silmäpari aina auttaa, mutta toisaalta jos dokumentaatio rajataan vain siihen mitä kukin kehittäjä tarvitsee, niin se auttaa fokusoitumisessa.
7: Why Did the Tower of Babel Fail?
Tässä käydään läpi sitä kuinka ongelmalliseksi kommunikaatio voi mennä suurissa järjestelmissä, ja sitten tulee roolijakoa ja
Project Management 101 tyylistä asiaa.
8: Calling the Shot
Tässä käydään läpi tuottavuutta ja arviointia sille, kuinka kauan projektissa saattaa mennä.
9: Ten Pounds in a Five-Pound Sack
Taas näkyy kirjan ikä, kun puidaan sitä, sinällään validia puolta ohjelmistotuotannosta, kuinka hallitaan ohjelmiston tilan vientiä muistissa tai levyllä.
10: The Documentary Hypothesis
Dokumentaatio on tärkeää, mutta usein vain pieni osa dokumentaatiosta on kriittistä. Sitten kerrotaan minkälaista dokumentaatiota käytännön projekteissa näkyy, yleensä.
11: Plan to Throw One Away
Vanhaa asiaa, jota on puitu myöhemmin monessakin paikassa ja pitkään. Nykyään puhutaan prototypoinnista ja eri kehitysmalleista ja kaikkea.
12: Sharp Tools
Tässä on jonkin verran viehättävän vanhakantaista asiaa. Järjestelmäpuolelta mielenkiintoisin oli se että toimiva simulaattori on aikalailla kriittinen, ja käyttökelpoinen vaikka kohderaudassa pieniä muutoksia tapahtuisikin.
13: The Whole and the Parts
Testaa, suunnittele, testaa komponentit erikseen, rakenna tukirakenteita komponenttien testaamiseen, testaa uudet osat debugatuilla komponenteilla...
Debugging 10114: Hatching a Catastrophe
Miten projekti voi olla vuoden myöhässä aikataulusta? Aina päivän kerrallaan.
Miten, minne ja missä aikataulut luistaa ja mitä tehdä asialle on tämän artikkelin aihe.
15: The Other Face
Käyttäjät, miksi vuokaaviot ovat turhia, dokumentaatio osana koodia. En tiedä onko tämä ensimmäinen paikka missä esitetään että "Hei, josko dokumentoidaan funktiot jo koodissa, kun dokumentaatio olisi joka tapauksessa digitaalisessa muodossa in the first place?"
Vähän sellaisen kuvan voi saada.
16: No Silver Bullet-- Essence and Accident in Software Engineering
Softa on yksinkertaisesti niin monimutkaista, että yhtä yleispätevää "hei näin saadaan hyvää koodia" ratkaisua ei ole olemassa. Sitten käydään läpi niitä mistä voidaan väittää olevan hopealuodiksi. Yksi mielenkiintoinen ilmaisu artikkelissa on se, että ohjelmia ei niinkään
rakenneta (Build) vaan ne
kasvatetaan (Grow), minkä pitäisi olla järkeenkäypää kaikille pidempään samaa ohjelmaa työstäneille.
17: No Silver Bullet Refired on sitten uusintapainokseen uusi artikkeli. Tässä Brooks käy läpi sitä kuinka hän oli saanut vasta-argumentteja, ja oli tullut tulokseen että alkuperäinen artikkeli oli hieman liian monitulkintainen.
18: Propositions of
The Mythical Man-Month: True or false
Käydään läpi miten ovat artikkelit kestäneet ajan saatossa
19:
The Mythical Man-Month after 20 Years on sitten sellaiset loppusanat kirjalle, noin ajankulun näkökulmasta.
Kaikenkaikkiaan kirja on minusta erinomainen "Projektinhallinnan perusteet" opus vieläkin, ja se antaa paljon pohjaa ja historiallista viitekehystä sille, mitä nykyisin opetetaan projektinhallinnasta. Se ei ole vallan tylsästi kirjoitettukaan. +kiva.