Myyttinen miestyökuukausi luettu.

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 101

14: 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.

Painonhallintaa ja liikuntaa

Puntari, hyödyllinen kapistus.

Vaikka suositellaan että paino pitäisi mitata tiettynä aikana päivästä - yleensä puhutaan aamupainosta - ei se paino itsestään päivän aikana nouse. Joten:

Kun seuraa omaa painoa säännöllisesti päivän aikana, voi asettaa rajan, "Jos paino on yli X, niin en syö." Vaikka kaikenlaiset asiat vaikuttavat kulutukseen, paino on paino, lopulta. Binääriset testit muutenkin ovat hyödyllisiä kaikenlaisissa asioissa.

Olen juoksennellut sellaista reilun neljän kilometrin lenkkiä joka toinen päivä, mutta vaikka olenkin jättänyt päivän väliin polville lepotaukoa, silti ne tuntuvat olevan vähän kovilla. Jos tilanne ei parane, pitää pidentää lepoväliä, kaiketi.

Ylös, alas, vähän kerrallaan.

Juhannus toi kivasti painoa lisää. Moisesta inspiroituneena päätin olla kokeeksi yhden päivän syömättä.

Noin niinkuin oman kantin testaamiseksi ja huvin vuoksi, niin sanotusti. Täysi syömättömyys oli yllättävän helppoa, kyseessä kun on yhden sortin binäärinen operaatio, ja seuraavana aamuna ei ollut edes nälkä.
Ruuatta n. 34 tuntia tarkoitti että painoa lähti n. 2.5 kiloa, josta edes kaikki ei ollut nestettä, sillä join aika paljon vettä nälän tunteen rajoittamiseksi.
Verrokkina sanottakoon, että on paljon vaikeampaa yrittää syödä vain yksinkertaisesti vähemmän, sillä sitten ei enää olla binäärioperaatioissa. Hm.