Dragonflight

Anne McCaffrey, Dragonflight. Corgi Books, London, UK, 1981. Alunperin julkaistu 1968.

Anne McCaffrey on yhdysvaltalainen fantasiakirjailija, joka on voittanut sekä Hugo- että Nebula-palkinnon. McCaffrey lienee tunnettu nimenomaan Perniin sijoittuvista tarinoista, joista Dragonflight on ensimmäinen -- tarkemmin ottaen se punoo yhteen kaksi aikaisempaa novellia ollen ensimmäinen Pern-romaani.

Pern on esiteollinen fantasiamaailma, jota kiertää punainen tähti. Aika ajoin punainen tähti sylkee maailmaan ikäviä sieni-itiöitä. Ainoa tehokas ase näitä vastaan ovat lohikäärmeet ratsastajineen. Ongelma on, että vaikka itiöitä sataa säännöllisesti, tapaus on niin harvinainen, että ihmiset ovat haluttomia ylläpitämään lohikäärmeitä ja niiden ratsastajia. Jokainen maailma tuottaa siis omat reaganinsa.

Kovin fantastisista aineksista kehkeytyy piristävän eheä teos. Päähenkilöitä on kaksi: viimeinen Ruathan aatelissuvun jäsen Lessa ja lohikäärmeritari F'lar. McCaffreyn tarina välittää kuvan maailmasta, jossa yhteiskuntaluokat, sosiaaliset instituutiot ja perinteet vaikuttavat ihmisten kanssakäymiseen. Silti korkealentoinen fantasia etäännytti maallikon tekstistä siinä määrin, ettei tarina oikein pitänyt otteessaan.

Beyond Software Architecture

Luke Hohmann, Beyond Software Architecture : Creating and Sustaining Winning Solutions. Addison-Wesley, Boston, MA, USA, 2003.

Luke Hohmann on yhdysvaltalainen ohjelmistoalan konkari, joka on urallaan ollut tekemässä monenlaisia juttuja. Nuorempana hän oli junioripariluistelun kansallista kärkeä Yhdysvalloissa. Hohnmann on muiden asioiden ohella myös agile-menetelmien kannattaja.

Ohjelmistoarkkitehtuuri on ohjelmiston keskeisten osien ja niiden välisten suhteiden kuvaus. Kuvaukseen käytetään tyypillisesti yläkäsitteitä, ja niitä piirrellään laatikkoina, nuolina jne. Nimensä mukaisesti Beyond Software Architecture menee softa-arkkitehtuuria pidemmälle ja tarkastelee, millä tavoin liiketoiminnan ja teknologian välinen suhde toimii -- tai miten sen tulisi toimia. Ideaalitapauksessahan ohjelma tai ohjelmisto tarjoaa jonkinlaista hyötyä käyttäjälleen. Usein kuitenkin ohjelmistot tuottavat kärsimystä joko käyttäjille, tekijöille tai molemmille. Kirja on periaatteessa käytännön läheinen opas kärsimyksen vähentämiseen softa ohjelmistoyrityksen sisällä.

Hohmann aloittaa ohjelmistoarkkitehtuurista käyden läpi peruskäsitteitä. Jos tarkoitus on toistuvasti voittaa tarjouskilpailuja tai kilpailijoita, arkkitehtuuriin on voitava tuoda uusia toiminnallisuuksia ilman, että sen vakaus tai eheys suuresti kärsii. Parhaassa tapauksessa fiksu arkkitehtuuri voi tarjota kilpailuedun.  Hohmann käsittelee tuotehallintaa, jonka tehtävä on suunnitella ja ylläpitää tuotetta, so. toiminnallisuuksia ja ominainaisuuksia, jotka muodostavat tuotteen (tai ratkaisun). Tuotehallinta kytkeytyy läheisesti yrityksen liiketoimintasuunnitelmaan: tuotteeseen, hinnoitteluun, jakeluun ja markkinointiin. Niinpä Hohmannin mukaan softa-arkkitehteja tulisi olla kahdenlaisia: teknisiä arkkitehtejä ja markkoinnillisia arkkitehtejä, joka kaiketi kääntyy tuotepäälliköksi.

Liiketoimintasuunnitelma kertoo, miten yrityksen on tarkoitus saada rahaa. Ohjelmistoalalla, joka on monella tapaa poikkeava perinteisistä aloista, keskeistä on lisensointi: miten ja millä ehdoin yrityksen  ohjelmistoa tarjotaan käytettäväksi. Hohmann käy läpi lisensointimalli- ja toimitusvaihtoehtoja. Tuotteen (ja katteen) kannalta keskeisiä asioita ovat myös asennus-, päivitystavat. Paljon käsityötä vaativat asennukset saattavat olla kalliita myös toimittajalle kaikkine mahdollisine ongelmineen (se "ai niin joo" -vaihe). Päivitykset ovat joissain tapauksissa siinä mielessä pahempia, että ne eivät ole riippumattomia päivitettävästä versiosta. Lopuksi Hohmann keskustelee tuotejulkistuksista (release), konfiguroinneista, lokeista, tietoturvasta.

Kirjassa on tiivistelmät kunkin luvun lopussa. Teksti on helppolukuista, ja joissain tapauksissa se tuntuu tekevän tikusta asiaa. Monin paikoin on otsikoituja alilukuja, joissa on vain yksi kappale. Jotenkin uutta asiaa tuntui olevan vähän; monet asiat ovat tulleet selviksi työelämän kautta.  Ehkä kirja palvelee jonkinlaisena johdatuksena softaliiketoimintaan teknisille tyypeille ja softa-arkkitehtuureihin liiketoimintatyypeille, en tiedä.

Risto Ryti: Elämä isänmaan puolesta

Martti Turtola, Risto Ryti: Elämä isänmaan puolesta. Otava, Keuruu, 2009 (1994).

Maanpuolustuskorkeakoulun sotahistorian dosentti Martti Turtola on kirjoittanut liudan elämäkertoja Talvi- ja Jatkosodan upseereista sekä sotaa edeltäneistä ja sen aikaisista ilmiöistä.  Risto Rytin elämäkerta on tässä mielessä poikkeama: hänhän ei kummankaan presidenttikautensa aikana ollut edes puolustusvoimien ylipäällikkö!

Risto Ryti (1889-1956) oli kotoisin Huittisista, eli Satakunnasta kuten monet suomenkielisen eliitin jäsenet viime vuosisadan alussa.  Ryti oli ilmeisen lahjakas, ja jaloilleen nouseva nuori valtio tarjosi mahdollisuuksia fiksuille suomenkielisille miehille. Ryti ehti toimia kansanedustajana, valtiovarainministerinä, Suomen Pankin pääjohtajana, pääministerinä ja lopulta tasavallan presidenttinä. Ennen poliittista uraansa hän toimi mm. Suomen rikkaimman miehen, Adolf Kordelinin, lakimiehenä -- ja sattui vielä olemaan paikalla Mommilassa 1917, kun venäläiset matruusit surmasivat Kordelinin.

Kirjan perusteella Ryti oli paitsi älykäs myös epäkäytännöllinen ja asioinnissaan kuiva. Häntä pidettiin kylmänä päättäjänä, koska ei antanut juuri tunteidensa johtaa valintojaan. Niinpä sisällissodan jälkeen hän taipui punaisten armahduksiin vain puolueen painostuksesta. Toisaalta hän hallitsi hermonsa erinomaisesti, mistä oli etua vaikeina vuosina 1939-1944. Ryti oli myös idealisti, joka asetti ylevät arvot ja kokonaisuuden edun oman etunsa tai mukavuutensa edelle. Sotasyyllisyystuomio ja sitä seuranneet vuodet kuritushuoneella hän näytti hyväksyneen samaan tapaan kuin pääministeriyden ja presidenttiyden -- velvollisuutena. Ryti jopa suomii Mannerheimin epäröintiä vallanvaihdossa kesällä 1944: "Mannerheim ajattelee liiaksi omaa nekrologiaan ja sitä, missä valossa hän tulee esiintymään jälkimaailmalle".

Turtolan kirja on mielenkiintoinen silmäys viime vuosisadan alkupuoliskon politiikkaan. Sisäpolitiikka on itsenäisyyden ajan alkuvuosina kaikkea muuta kuin helppoa, ja kirjan kautta mustavalkokuviin alkaa tulla väriä.  Rytin lapsuudesta on jäljellä pääasiassa kaskuja, joita värittää myöhempi menestys, ja niinpä kirjan alkupuoli lyö hieman tyhjää. Ryti ei jättänyt jälkeensä muutamaa pontevaa puhetta lukuunottamatta valtiomieheksi erityisen paljoa kirjoituksia saati muistelmia, joten tutkijalle aihe ei ole ehkä helppo. Teksti on sidottu lähteisiin, johon kirjeenvaihdon ja pöytäkirjojen ohella kuuluu myös joitain Moskovan arkiston dokumentteja ja Iso-Britannian Keskuspankin muistioita. Turtola tunnistaa myös katvealueita, joita hän toivoo myöhemmän tutkimuksen aikanaan valaisevan.

Peopleware

Tom DeMarco jaTimothy Lister, Peopleware - Productive Projects and Teams. Second Edition. Dorset House Publishing Co., New York, NY, USA, 1999.

Tom DeMarco ja Timothy Lister ovat yhdysvaltalaisia ohjelmistoalan konsultteja -- siis sanan varsinaisessa merkityksessä. He konsultoivat eli keskustelevat asioista ja neuvovat asiakkaitaan ohjelmistojen kehittämiseen ja organisaatioiden rakentamiseen liittyvissä kysymyksissä. Peopleware on kokoelma esseitä heidän kokemuksistaan vuosikymmenten varrelta. Kirja on saavuttanut jonkinlaisen klassikon aseman - eikä suotta.

Tietojärjestelmäteknologian voidaan katsoa koostuvan kolmesta osasta: laitteista (hardware), ohjelmistoista (software) ja ohjelmiston tuottavasta organisaatiosta (peopleware). Peopleware käsittää niin työnjaon ja henkilöstöjohtamisen kuin projektihallinnan ja organisaatiokulttuurinkin. DeMarco ja Lister käyvät läpi näitä asioita nostaen esiin sudenkuoppia ja esittäen mahdollisia ratkaisuita.

Kirjan ensimmäinen osa käsittelee henkilöstöjohtamista ja sen vaikeutta. Kirjan ensimmäinen luku luo kivasti kirjan tunnelman otsikolla "Somewhere today, a Project is Failing". Tutkimusten mukaan projektit eivät epäonnistu teknisistä syistä vaan sosiaalisista tai organisatorisista. Ohjelmistotuotanto onnistuu tai epäonnistuu sen mukaan, miten ihmiset onnistuvat tekemään yhteistyötä ja kommunikoimaan. DeMarco ja Lister esittävät, että onnistumiselle on organisatorisia esteitä: Ohjelmiston tekijöitä kohdellaan vaihdettavina koneen osina. Projekteille asetetaan epärealistisia aikatauluja siinä pelossa, että ihmiset yrittäisivät vähemmän, jos projektilla olisi realistinen aikataulu. Näin laatuajattelu lentää ikkunasta ensimmäisenä. 

Kirjan toinen osa koostuu esseistä, jotka pureutuvat toimistoon. Juha Siltala kuvaili Sanomataloa teollisuuskanalaksi sillä erotuksella, että teollisuuskanala on tehokas. Aivotyö vaatii hiljaisuutta, mutta avokonttoreissa keskeytysten määrä kasvaa. Puhelinkeskustelut ovat piinaa vieressä istuville. DeMarco ja Lister esittelevät tutkimustuloksia, jotka osoittavat, että laadukas ja luova ongelmanratkaisu vaativat keskeytyksetöntä rauhaa. He pitävät amerikkalaista cubiclea -- siis puolentoista metrin korkuisin, siirrettävin seinämin muodostettavaa työtilaa -- erinomaisen huonona ratkaisuna. Se katkaisee sosiaalisen yhteyden ihmisten väliltä eristämällä, mutta matalat seinät eivät kuitenkaan suojaa erityksissä olevaa ympäröivältä hälyltä. Niinpä töitä saa usein tehtyä vain neuvotteluhuoneen, kahvilan tai iltamyöhän tuomassa rauhassa. DeMarco ja Lister ihmettelevät erilaisten sisustuspoliisien innokkuutta: Miksi työpisteet ja joissain tapauksissa pukeutuminen pitää olla yhdenmukaisia? Palveleeko se jotain etua, vai onko se vain vallankäyttöä? Tiedän kokemuksesta, että joissain työpaikoissa ei käännetä työpöytääkään ilman sisustusarkkitehdin hyväksyntää. Miksi?

Kolmas osa käsittelee ihmisiä, ohjelmistotyön ratkaisevaa osaa. Perinteisen organisaatioiden johtamisopin mukaan johtaja on strategi, jolla on pelilaudalla käytettävissään yhdenmukaisia nappuloita, joista yksinkertaisuuden vuoksi on poistettu kaikki henkilökohtaiset erityistaidot ja luonteet. Toimiva tiimi kuitenkin koostuu ihmisistä, ja satunnaisesti nappuloista kootut viiden tai kymmenen hengen ryhmät saavat aikaan hyvin erilaisia tuloksia. DeMarcon ja Listerin resepti on yksinkertainen: hanki tiimiin oikeat ihmiset, pidä heidät tyytyväisinä, jotta he eivät lähde pois, ja anna heille työrauha. Ohjelmistoalalla on tietenkin kaikenlaista viheltäjää, eivätkä kaikki projektit pääse nauttimaan parhaasta osaamisesta, mutta toimivassa porukassa tavallisistakin ihmisistä kasvaa osaavia ammattilaisia. Homma usein kuitenkin kaatuu huonoon johtamiseen. 

Neljännessä osassa kirjoittajat pohtivat tiimin toimintaa. Me-hengen ('jelled team') aikaan saaminen on vaikeaa, mutta on helpompaa luetella tapoja, joilla sen saa nitistettyä. Teamicide (tiimin tappaminen) onnistuu johdon osoittaman epäluottamuksen, byrokratian, tiedon siiloutumisen, laatutavoitteiden polkemisen, keinotekoisten aikatavoitteiden ja tiimien jatkuvuuden katkaisemisen avulla. Jos tekijät eivät koe softaa omakseen, he eivät siihen sitoudu.

Viides ja kirjan ensimmäisen laitoksen viimeinen osa esittelee tapoja viihtyvyyden lisäämiseksi ja ylläpitämiseksi. Kangistuneita kaavoja pitää rikkoa - kuinkas muuten kuin - leikin ja uusien ärsykkeiden avulla. Työntekijöille järjestetään ohjelmointikilpailuja, rooleja rikotaan brainstormauksessa, heitä koulutetaan tai käytetään konferesseissa tai jossain toimiston ulkopuolella. Nämä vaativat pieniltä organisaatioilta kekseliäisyyttä kustannusten vuoksi ja suurilta sosiaalista kekseliäisyyttä ja diplomatiaa organisatorisen jäykkyyden vuoksi.

Kirjan toinen laitos toi muassaan kuudennen osan, jossa kirjoittajat käyvät läpi edellisten lukujen asioita 12 vuotta ensimmäisen laitoksen ilmestymisen (1987) jälkeen. DeMarco ja Lister piiskaavat yritysten valheellisia motivointijulisteita, organisaatioiden lietsomaa sisäistä kilpailua ja vähäistä ymmärrystä osaavan työntekijän tuottamasta hyödystä ja vaihtuvuuden kustannuksista.  Työtunnit eivät ole yhteismitallisia, vaikka ne taseessa ehkä siltä näyttävätkin. Prosessin kehittyneisyyttä mittaava Capability Maturity Model saa kritiikkiä. Jos pärjääminen siinä asetetaan tavoitteeksi, päädytään tekemään asioita, jotka varmasti ylläpitävät saavutettua statusta, ja jätetään kaikki riskipitoiset ja muutosta sisältävät asiat tekemättä. Siitä seuraa kankeus, viihtyvyyden lasku ja kilpailukyvyn menetys. Niinpä pitäisi tarttua sellaisiin asioihin, jotka uhkaavat heikentää organisaation CMM-tasoa.

DeMarcon ja Listerin kuvailemat ongelmat eivät ole katoamassa. Jos mietitään, mihin perustuu suurten konsultti- eli alihankintafirmojen menestys, se ei ole laadukkaassa softassa vaan sopimusneuvotteluissa osaamattoman tilaajan jallittamisessa. Laadun pitäisi olla kilpailuetu, mutta näin ei ole ohjelmistoissa eikä monessa muussakaan asiassa (huonekalut, vaatteet, kodin elektroniikka).

Voi meitä.