Matikkatuhoaseet

Cathy O'Neil, Matikkatuhoaseet: Miten suuraineisto lisää eriarvoisuutta ja uhkaa demokratiaa. Englanninkielisestä alkuteoksesta Weapons of Math Destruction (2016) suomentanut Kimmo Pietiläinen. Terra Cognita, Helsinki, 2017.

Jotkut puhuvat kuhnilaisesta paradigmamuutoksesta, joka on käynnissä tieteissä. Digitaalinen taltiointi mahdollistaa suurien aineistojen kokoamisen ja yhdistelyn. Niinpä tilastollinen päättely on hiipimässä työkalujen joukkoon aloille, kuten tulkintatieteisiin, joissa on perinteisesti käytetty pääasiassa muita menetelmiä. 

Tietoja myös kerätään aikaisempaa aggressiivisemmin asiakkaista, työntekijöistä, kuluttajista ja kansalaisista. Esimerkiksi terveystietojen keskittämistä ja yhdistämistä perustellaan hoidon tehostamisella. Lainsäädäntö näiden osalta on liikkunut verkkaisesti; kesällä astuu voimaan EU:n uusi tietosuoja-asetus, jonka pitäisi parantaa kansalaisten asemaa suhteessa rekistereiden pitäjiin niin, että esimerkiksi päättäjien tai virkamiesten horjahdus ei (välttämättä) johda kaikkien tietojen päätymiseen yksityisiin käsiin (automaattisesti). Kun tiedon arvo nousee, kiusaus sen myymiseen kasvaa.

Yhdysvaltalainen matemaatikko Cathy O'Neil tarkastelee kirjassaan Matikkatuhoaseet (2017) tapoja, joilla suuraineistot (engl. big data) haittaavat ihmisten elämää ja heikentävät heidän välistään tasaveroisuutta. Hän on itse kehittynyt yliopistotutkijasta hedge-rahaston hoitajaksi ja edelleen suuraineiston vaaroista luennoivaksi maallikkosaarnaajaksi ja aktivistiksi.

Kaikki mallintaminen ei tietenkään ole pahasta, mutta jos mallinnuksen kohteet eivät tiedä, mihin kerättyä dataa käytetään, jos mallintamista käytetään sen kohteen etujen vastaisesti ja jos mallintaminen skaalautuu kattamaan laajoja joukkoja, puhutaan ”matikkatuhoaseista”. Se on kömpelö suomennos ontuvasta englanninkielisestä ilmaisusta ”weapon of math destruction”, joka on joukkotuhoaseeseen nojaava sanaleikki (”weapon of mass destruction”). Aseet suunnitellaan tiettyä tarkoitusta, tuhoamista, varten, mutta O'Neilin matikkatuhoaseissa tuho on toissijainen seuraus. Kirjan sinänsä tärkeä sanoma kompastelee huonosti valitun sanaleikin vuoksi.

Vallitsevan ideologian mukaan kaikki kilpailu on aina hyvästä. Kun 1980-luvun alkupuolella yhdysvaltalainen sanomalehti U.S. News julkaisi yliopistojen paremmuusjärjestyksen, se tuli samalla laukaisseeksi yliopistojen välisen kilpailun parhaista opettajista, parhaista oppilaista ja rahoituksesta. Lehden käyttämä mitta oli toimittajien hihasta vetämä, ja vaikka sitä on sittemmin muutettu, on se pakottanut yliopistot keskittymään niihin asioihin, joita mitataan.

Yliopistoja ei kuitenkaan pisteytetä suhteessa kustannuksiin niin, että halpa (x dollaria per piste) yliopisto voisi kiilata kärkisijoille. Lukukausimaksut ovat nousseet kilpailun seurauksena rajusti (viisinkertaistuneet välillä 1983-2013), koska opiskelijoille pitää rakentaa upeita asuntoloita ja kiipeilykeskuksia viihtyisyyden parantamiseksi. Pisteytys ohjaa O'Neilin mukaan keskittymään epäoleellisiin asioihin. Nousevat kustannukset kasvattavat opiskelijoiden velkataakkaa. 

Samanlainen pisteytys on käytössä joillain työpaikoilla. Esimerkiksi opettajien tehokkuutta mitataan oppimistuloksien kautta: oppilailla on jatkuvasti kokeita, ja heikosti pärjäävät opettajat potkitaan pihalle, mutta huoli heikkenevistä koulutuloksista perustuu vuonna 1983 julkaistun raportin tilastolliseen päättelyvirheeseen. Oppilaiden oppimista pisteytetään heistä tehtyä ennustetta vasten, ja tulokset heittelevät rajusti lukukaudesta toiseen. Yliopistojen tapaan opettajatkaan eivät voi valittaa pisteytyksestä. Yrityksissä on kokemuksia, että myyjien keskenäinen kilpailu katkaisee tiedonvaihdon. Sitä pelataan, mitä mitataan.

Kilpailun ohella korvikemuuttujien käyttäminen tuottaa epäreiluja ja sekä yksilön että kokonaisuuden kannalta ikäviä seurauksia. Esimerkiksi parempien tietojen puutteessa työnhakijoita arvioidaan luottotietojen tai asuinpaikan perusteella, mikä vahvistaa syrjäytymistä ja onnettomuuksien vaikutusta. Ihmisellä on näin heikommat mahdollisuudet parantaa asemaansa. Yhdysvalloissa autovakuutuksen hinnoittelua ohjaavat luottotiedot enemmän kuin onnettomuushistoria. Kun poliisit keskittävät voimiaan sinne, missä tilastollisesti häiriköidään eniten, eli köyhemmille alueille, he synnyttävät takaisinkytkennän, jossa heikoimmassa asemassa olevat saavat merkintöjä rekisteriin mitättömistä rikkeistä. Luulen, että jotkin verkkopalvelut kyselevät postinumeroa juuri tästä syystä: yhdistämällä sen asuntojen hintatietoihin voidaan arvioida käyttäjän varallisuutta ja tehdä siten kohdennettua markkinointia — tai myydä tiedot eteenpäin.

Jos internetissä oleva palvelu on ilmainen, käyttäjät ovat tuote. Yhteisösivustojen erilaisten pelien ja kyselyiden (esim. ”Mikä Star Wars -hahmo olet?") tarkoitus on kerätä yhteys- ja profiilitietoja niiden eteenpäin myymikseksi. The Guardian kertoi jokin aika sitten, etteivät internet-firmojen johtajat käytä itse omia palveluitaan. Palvelut on lisäksi suunniteltu addiktoiviksi eli tästä syystä pelkoa ja vihaa lietsoviksi ympäristöiksi. Niiden sisäinen päätöksenteko, esim. mitä viestejä tai mainoksia näytetään milloinkin, on niin monimutkaista, ettei edes jälkikäteen pystytä sanomaan, miksi mitäkin tapahtui. Sivustot, kuten Facebook, voivat polarisoida äänestäjät ja heiluttaa vaalien tulosta, kuten on nähty.

(Sivumennen sanoen, hieman samaan aiheeseen liittyy Yliopisto-lehdessä (1/2018) julkaistu juttu kirjallisuudentutkija Maria Mäkelän johtamasta Kertomuksen vaarat -hankkeesta. Se tutkii, miten käsityksemme todellisuudesta kehittyy kokemuspuheen ja kertomuksellistamisen kautta. Uudenlainen ansaintalogiikka ohjaa uutisoinnissakin tietynlaisiin kertomuksiin esimerkiksi hyvinvointivaltiosta:  kertomukseen nojaavassa uutisessa yksilön kokemus (”Kela pilasi ylioppilasjuhlat”) nousee kuvaamaan pääsääntöisesti hyvin toimivaa järjestelmää ja mahdollisesti rapauttaa luottamusta siihen.)

Byrokratia etäännyttää ihmisen muita koskevista päätöksistä. Algoritmi on tunteeton ja kohtelee kaikkia sisäisen ohjeistuksensa mukaisesti, joten se on lahjomaton, väsymätön ja ainakin periaatteessa halpa. O'Neil toteaa, että päätöksentekijänä ihminen kuitenkin korjaa käytöstään saadessaan uutta tietoa. Ihmiseltä voi vaatia perusteluita. Algoritmit voivat olla mustia laatikoita, joita harva, jos kukaan, ymmärtää. Niiden päätöksistä on vaikea valittaa, ja niitä on vaikea muuttaa.

O'Neilin esimerkit ovat Yhdysvalloista. Niiden menetelmät ovat kovin karkeita, enkä ole kuullut aivan vastaavista tapauksista ainakaan Suomessa. Toki päättäjiltä, järjestelmien tekijöiltä, tilaajilta ja käyttäjiltä vaaditaan erityistä moraalista valppautta. Hyvän liiketoiminnan tielle on joissain tapauksissa hyvä kasata esteitä, jos tuo moraalinen valppaus on sattunut jäämään taka-alalle.

Suomentaja Kimmo Pietiläinen pitää suomennettua tietokirjallisuutta ajattelun edellytyksenä. Vaikka asia ei ole aivan yksioikoinen, ajankohtaisten tietokirjojen suomentaminen on kulttuuriteko, johon muut kustantamot ovat tarttuneet hieman hitaammin. Suomennos toimii kuitenkin jossain määrin ylevää tarkoitustaan vastaan, kun sen alta paistavat alkukieliset ilmaukset ja lauserakenteet kuin pohjamaali kevyesti maalatusta seinästä. Joissain kohdin sanavalinnat ovat huolimattomia (esim. ”säätely” ”sääntelyn” sijaan), toisissa huonoa suomea (”kohtuuttoman rivoja summia”). Toistuvina nämä alkavat häiritä lukukokemusta (ja näin sanoessani yksilön kokemukset alkavat vaikuttaa käsityksiin suomennoksista).

PostgreSQL 9.0 High Performance

Gregory Smith, PostgreSQL 9.0 High Performance. Packt Publishing, Birmingham, UK, 2010.

Packt Publishing -kirjat ovat olleet laadultaan epätasaisia niiltä osin, kuin olen niihin perehtynyt, vaikka kirjat käyvät läpi jonkinlaisen vertaisarvioinnin. Tietokanta-asiantuntijan Gregory Smith Postgres-tietokannan suorituskykyyn pureutuva PostgreSQL 9.0 High Performance (2010) on kuitenkin kustantamon niitä parempia teoksia. Teos on tosin jo hieman vanhentunut, sillä Postgresin, eli ammattikielellä "Possun", betaversio 9.5 julkaistiin viime lokakuussa. Suorituskyvyn mittaamisesta ei tämän avoimen lähdekoodin tietokannasta ole tuoreempaa teosta, mutta toisaalta perusasiat eivät muutu kovin nopeasti.

Smithin kirja on käytännön opas suorituskyvyn mittaamiseen, ja teoriaa siinä on hyvin vähän. Tietokannan ylläpito edellyttää jatkuvaa seurantaa ja säännöllisiä testejä, joissa trendit sitten paljastavat erilaisia skaalautuvuuteen tai kuormaan liittyviä ongelmia. Ne tarjoavat myös pohjan, jonka varassa tietokannan asetuksiin on mahdollista tehdä muutoksia. Siinä se.

Laite- eli "rautatasolla" suorituskyky koostuu prosessorien, muistin (eli väliaikaismuistin) ja levyjen (eli pysyväismuistin) tehokkuudesta. Toki laitteilla on välimuisteja, väylänopeuksia jne., mutta Smith aloittaa näiden kolmen eri komponentin kuormitustesteillä. Levypintojen tai -hakuvarsien lukumäärää ei tarvitse kaivaa esiin, mutta levyn pyörimisnopeus on edelleen käypä muuttuja (tiedoksi niille jotka levyn hakunopeuksia ovat joskus laskeneet). Smith kuvailee eri tiedostojärjestelmien ja levyteknologioiden vaikutuksia tietokannan toimintaan. Esimerkiksi ilman patterivarmennettua kirjoituspuskuria muuten nopeisiin ja muuten erinomaisiin SSD-levyjen varmennukseen jää katve, jonka aikana sattuva järjestelmähäiriö voi kadottaa tietoa.

Tietokannan vasteajat riippuvat paitsi laiteresursseista myös kuormasta (eli muusta samanaikaisesta käytöstä) ja tavasta, jolla data on organisoitu tietokantaan. Smith tarjoilee joitain hyviä nyrkkisääntöjä tietokannan muistiasetuksiin; perusasetukset ovat alakanttiin. Sitäkin hyödyllisempää on tietokantasivun tai levylohkon elinkaaren esittely: rinnakkaisten kirjoitus- ja lukuoperaatioiden nopeuttamiseksi Postgres versioi tietokantarivejä, jotka sitten näkyvät eri transaktioille niiden tunnisteiden (so. juokseva järjestysnumero) mukaan. Aikanaan versiot tietysti vanhentuvat, joten ne pitää siivota pois. Vaikka automaattinen siivousoperaatio näin tekeekin, se ei vapauta levytilaa, vaan taulun lisäys- ja poisto-operaatiot aikaa myöten fragmentoivat taulun hallitseman levyalueen, jolloin laajat kyselyt johtavat yhä useamman levylohkon hakemiseen levyltä (mikä tarkoittaa pitkiä vasteaikoja). Sama koskee indeksejä: ne fragmentoituvat ja voivat siten muuttua jopa käyttökelvottomiksi. Niinpä aikaa myöten Postgresin suorituskyky heikkenee. Ongelma on tottakai ratkaistavissa, mutta se vaatii varsinkin suuremmissa tietokannoissa on monen tunnin huoltoikkunan. 

Tietokannan testaamiseen on lukuisia työkaluja, joista jotkin ovat vanhentuneet suhteessa nykyisiin datamääriin. Niillä saa kuitenkin säännöllisesti käytettynä luotettavia mittaustuloksia, jotka ehkä arvioivat kirjoitus- ja lukunopeuksia yläkanttiin, mutta joissa esiintyvien trendien muutokset kertovat mahdollisista ongelmista pellin alla. Sitten tietokannan lokeista voi koota joukon ongelmakyselyitä, joiden säännöllinen testaaminen tuottaa hyvää mittausdataa. Smith pureutuu myös kyselyiden optimointiin, indeksien käyttöön ja analyysidatan tulkitsemiseen. Edellytys suorituskyvyn parantamiseen on, kuten tuli ilmi, säännöllinen monitorointi ja huolto.

Smithin kirjassa on paljon hyvää. Selostukset erilaisista laitteista ja työkaluista on kirjoitettu samaan tapaan huolellisesti kuin kirjan keskeinen asia. Samat tiedot olisi koottavissa ehkä Postgresin sivuilta ja keskustelupalstoilta, mutta rakenteensa, kattavuutensa, esimerkkiensä ja argumentaationsa puolesta (sähköinen) kirja pitää julkaisumuotona edelleen pintansa nopeasti kehittyvänkin aiheen piirissä. Smith kirjoittaa siistiä insinöörikieltä, jonka sanasto on alan erikoistermejä lukuunottamatta väritöntä yleiskieltä.

Functional Programming in Scala

Paul Chiusano ja Rúnar Bjarnason, Functional Programming in Scala. Esipuheen kirjoittanut Martin Odersky. Manning, Shelter Island, NY, USA, 2015.

Vanhan viisauden mukaan iterointi on inhimillistä, mutta rekursio on jumalaista. Iterointia käytetään tietokoneohjelmoinnissa, matemaattisessa approksimoinnissa ja suomalaisessa hallitustyöskentelyssä. Se on tehtävien prosessointia ikään kuin silmukassa: suoritetaan työvaiheita, kunnes tulee lupa lopettaa. Rekursio on matemaattisempi: siinä työvaiheen tulos riippuu saman operaation edellisistä arvoista. Esimerkiksi Richard Stallmanin avoimen lähdekoodin hanke GNU on rekursiivinen akronyymi—se tulee sanoista GNU's Not Unix. Hah hah.

Jos Hartwall-areenan yleisö pitäisi järjestää nousevaan aakkosjärjestykseen sukunimen mukaan, iteratiivinen lähestymistapa aloittaisi lavalta katsottuna vasemmasta yläkatsomosta ja alkaisi yksitellen siirrellä ihmisiä sopivaan järjestykseen. Rekursiivinen lähestymistapa voisi järjestää ihmiset kussakin katsomossa ensin istuimittain (helppo), istuinriveittäin ja sitten katsomoittain lopulta yhdistäen tulokset koko areenan tulokset. Esimerkki on ontuva, mutta rekursio on  yksinkertaisesti maallisen yläpuolella.

Mikä sitten tekee rekursiosta jumalaista? Ensinnäkin sisäkkäisten operaatioiden hahmottaminen on ensinnäkin ihmiselle vaikeaa. Operaatio, joka selvittää, mikä on esimerkiksi yhdeksäs fibonacciluku, nojaa siihen, mitkä ovat kahdeksas ja seitsemäs fibonacciluku, mikä nojaa kuudenten ja viidenteen fibonaccilukuun jne. Tällainen päässälasku on vaikeaa vähänkään suurempien lukujen kohdalla. Rekursiiviset lukujonot eivät ole tietenkään arkipäivää, mutta rekursio on hyödyllinen sisäkkäisten,  keskenään samanlaisten tietorakenteiden käsittelyssä. Tietojenkäsittelijä puhuu puista, verkoista ja linkitetyistä listoista, eli erilaisista tavoista järjestää tietoa nopeasti ja tehokkaasti käsiteltäväksi.

Toiseksi rekursio tuottaa elegantteja ratkaisuita. Hyvin vähäeleisesti tai ytimekkäästi se ratkaisee mahdollisesti hyvin monimutkaisia ongelmia. Tämä vähäeleisyys tai ytimekkyys on läheistä sukua matematiikan estetiikalle. Rekursiota esiintyy myös luonnossa, suunnittelussa ja muotoilussa: Fibonaccilukujonon peräkkäisten lukujen suhde lähestyy kultaista leikkausta. Fraktaalit ovat rekursiivisia, itsesimilaarisia joukkoja, joita luodaan keinotekoisesti, mutta esimerkiksi kukka- ja parsakaali ovat rekursiivisia fraktaaleja rakenteita.

Vuosien varrella olen käyttänyt rekursiota säästeliäästi soveltaen sitä hyvin rajattuihin ongelmiin, koska rekursiolla on hintansa. Pitkät ketjut sisäkkäisiä funktiokutsuja edellyttävät raskasta  kirjanpitoa. Kun aloitin opintoni 1990-luvun puolivälissä, rekursiota pidettiin tapana rampauttaa tietokoneen suorituskyky. Verkkojen ja puiden läpikäyntiin "tosielämässä" suositeltiin iteraatiota. Tämä rekursioon liittyvä raskaus on kuitenkin ns. imperatiivisten tai deklaratiivisten ohjelmointikielten ongelma. On olemassa näille rinnakkainen, funktionaalinen ohjelmointiparadigma.
 
Paul Chiusanon ja Rúnar Bjarnasonin teos Functional Programming in Scala (2015) on tuore johdanto funktionaaliseen ohjelmointiin. Se pysyy paradigmana lähempänä matemaattista lambdakalkyylin mallia, jossa iteroinnin sijaan ikään kuin sievennetään operaatiota, kuin imperatiivinen paradigma. Keskeinen ero on tilamuuttujien käytössä: puhtaasti funktionaalisissa kielissä niitä ei ole tai, kuten todellisissa funktionaalisissa kielissä tehdään, niitä ei suosita. Näin Hartwall-areenan katsojalukumäärää ei koottaisi minkään juoksevan laskurin vaan pitkän, rekursiivisen funktion evaluoinnin kautta hieman fibonaccilukuesimerkin tapaan.

Tilamuuttujien hylkäämisellä saadaan aikaan viitteellinen läpinäkyvyys (referential transparency). Tällöin funktion eli suoritettavan operaation palautusarvo sisältää kaiken sen, mitä funktio tekee, eikä funktiolla ole sivuvaikutuksia.

An expression e is referentially transparent if, for all programs p, all occurrences of e in p can be replaced by the result of evaluating e without affecting the meaning of p. A function f is pure if the expression f(x) is referentially transparent for all referentially transparent x.

Tilamuuttujia voi käyttää funktion sisällä (joissain syheröisissä algoritmeissa se voi olla miltei pakko), mutta ne eivät koskaan näy ulos. Näin muodoin funktionaalinen ohjelmointi on ohjelmointia ilman sivuvaikutuksia. Inside every function with side effects is a pure function waiting to get out. Funktionaaliset kielet suosivat myös rekursiota. Esimerkiksi Scalan—siis ohjelmointikielen—kääntäjä osaa kirjoittaa ns. häntärekursion auki silmukaksi ilman yhtäältä tilamuuttujia ja ja toisaalta kallista kirjanpitoa.

Chiusano ja Bjarnason esittelevät esimerkkien kautta sivuvaikutusten eliminointia, mutta kaikki esimerkit poikkeuskäsittelystä rinnakkaisohjelmointiin, kirjastorajapinnoista jäsentämiseen pyörivät monadien ympärillä. Niitä käytetään ketjuttamaan operaatiota ja kommunikoimaan sitä, mitä operaatiot tekevät. Tuloksena on vaikuttavan kaunista jälkeä—osin tietysti rekursion takia. Scalassa on lisäksi paljon kaikenlaista, mitä kirjoittajat eivät käsittele.

Ohjelmointikielet muistuttavat toisiaan kapealta sanastoltaan ja syntaksiltaan, mutta niiden taustalla oleva filosofiat, joiden ohjaamana ongelmia puretaan ohjelmakoodiksi, voivat olla hyvin erilaisia. Functional Programming in Scala havainnollistaa erinomaisesti Scalan ja laajemmin funktionaalisen ohjelmoinnin taustalla olevan idean. Kirja ei ole kuitenkaan helppo, enkä pysty soveltamaan monadeja ja niiden tarjoamaa tyylikästä ilmaisuvoimaa rutiininomaisesti het' kirjan luettuani.

SQL Performance Explained

Markus Winand, SQL Performance Explained. English Edition. Markus Winand, 2012.

Relaatiotietokantajärjestelmiin liittyy jonkin verran teoriaa ja runsaasti käytäntöä. Relaatioalgebra tai normalisoidut kantamallit on kivoja ideaaleja, jotka toimiakseen edellyttävät kaikenlaista tunkkaamista, jotta vasteajat pysyvät kohtuullisina datamäärien kasvaessa.

Markus Winandin SQL Performance Explained (2012) käsittelee tietokannan suorituskykyä nimenomaan indeksien näkökulmasta. Indeksit ovat tietokantahakuja nopeuttavia tietorakenteita, jotka ovat tyypillisesti sivutettuja B-puita, vaikka muitakin muotoja on olemassa. Indeksointi nopeuttaa hakuja mutta hidastaa tietojen lisäystä ja kasvattaa levytilan ja muistin tarvetta.

Winand esittelee eri tietokantajärjestelmien erityispiirteitä ja työkaluja, mutta likaiset käytännön yksityiskohdat pysyvät etäällä. Niinpä hän konkretisoi indeksien hyödyt vaiheittain tehostuvien kyselysuunnitelmien kautta, mutta fyysisten laitteiden, levypuskurien, muistin, prosessorien tms. ominaisuudet eivät ole tämän kirjan ongelma.

Ammattilaiselle kirja on helppolukuinen, eikä uutta asiaa tule tavattomasti. Kirjan tarjoama näkemys taululiitoksiin (nested loop, hash join, sort merge) ja kyselysuunnitelmien aukilukeminen ovat tietysti hyödyllisiä, samoin indeksien anatomia. Kirja antaa keinot selvittää syyt hitaisiin kyselyihin ja teoriataustan ongelmien ratkaisemiseen, mutta ison datamäärän kanssa homma oikeastaan vasta alkaa tästä.

Agile Web Development with Rails 4

Sam Ruby, Dave Thomas, David Heinemeier Hansson, Agile Web Development with Rails 4. The Pragmatic Programmers, Raleign, NC, USA, 2013.

Vuonna 1993 japanilainen Yukihiro Matsumoto julkaisi Ruby-ohjelmointikielen. Se oli vahvasti oliopohjainen skriptikieli, jonka oli tarkoitus mahdollistaa paitsi olio-ohjelmointi, myös sekä funktionaalinen että imperatiivinen ohjelmointi. Niinpä Ruby mahdollistaa saman asian ilmaisemisen useaan eri tapaan. Usean paradigman noudattaminen tekee kielestä taipuisan tai jopa sekavan.

Ruby pysyi tuhansien muiden ohjelmointikielten tapaan pinnan alla laajemman yleisön tietämättömissä vuosikaudet, kunnes David Heinemeier Hansson julkaisi vuonna 2005 verkkosovellusten tekemiseen tarkoitetun sovelluskehyksen Ruby on Railsin, josta tuli nopeasti hyvin suosittu. Sovelluskehys oli avointa lähdekoodia ja rakentui konventioiden varaan, mikä helpotti ja nopeutti tietokantoja käyttävän verkkosovelluksen kehittämistä. Nimensä mukaisesti se oli kirjoitettu Rubyksi, mikä nosti esoteerisen kielen välittömästi laajaan käyttöön. Ruby on edelleen kehitystyön alla; sen viimeisin versio 2.0 ilmestyi tämän vuoden helmikuussa.

Sam Rubyn, Dave Thomasin ja David Heinemeier Hansson Agile Web Development with Rails 4 on opas Ruby on Railsin viimeisimpään versioon 4. Kirja on sekin työn alla; kirjan elektronista betaversiota on julkaistu pienin korjauksin helmikuusta asti. Nyt elokuussa tehtiin viimeiset korjaukset, ja nyt kirja on menossa painoon. Luin ohessa tai itse asiassa aluksi kirjan versiota 3.2., mutta siirryin elokuussa tuoreen 4.0 ääreen.

Kirja etenee verkkosovellusten oppaiden tapaan: alkuun pikainen sohaisu jonkin toimivan aikaansaamiseksi, sitten vaiheittain etenevä verkkokauppaesimerkki ja lopuksi Ruby on Railsin käsitteiden ja toiminnallisuuksien pureskelua. Johdanto tarjoaa alkuun asennusohjeita, teoriaa MVC-mallista ja lyhyen johdannon Ruby-kieleen.

Verkkokauppaesimerkki iskee nopeasti kiinni varsinaiseen aiheeseen. Agile-menetelmät eli ketterät menetelmät oletetaan tunnetuiksi. Esimerkkijärjestelmä on kirjoja myyvä sivusto, jonka kehittäminen etenee ikään kuin agile-projektina, jossa edetään pienin askelin ja esitellään toimivaa järjestelmää asiakkaalle tiiviiseen tahtiin. Kirjoittajat tuovat yksikkötestit ja funktionaaliset testit kuvaan heti alussa. Esimerkkien myötä verkkokauppaan tuodaan toiminnallisuuksia, Ajaxia, autorisointia ja autentikointia. Kolmannessa osassa kirjoittajat esittelevät toiminnallisuuksia toisistaan irrallisina kokonaisuuksina, muttei konkreettisten esimerkkien tarjonta varsinaisesti heikkene.

Kirjoittajien teksti on suoraviivaista ja puhekieleen taipuvaista. Kollegiaalinen lienee sopiva sana. Kirja sisältää kaiken tarvittavan lähdekoodin poislukien itseopiskelutehtävien ratkaisut (lähdekoodi on saatavilla kirjan omilta sivuilta). Kirjan kannessa on Railsin virallinen logo, mikä on harvinaista: Hansson on sallinut tavaramerkkinsä käytön vain projekteissa, joissa hän on itse mukana. Kirjalla on siis virallisuuden leima.

Agile Web Development with Rails 4 opettaa (tai palauttaa) nopeasti auttavat työskentelytaidot, mutta - kuten kaikissa kielissä - sujuvuus syntyy kielen jatkuvasta käytöstä. Työskentelin joskus kuutisen vuotta sitten jonkin aikaa Railsin parissa, mutta taidot ruostuvat ja sovelluskehykset muuttuvat. Ruby-kieli ja erityisesti Rails-sovelluskehys ovat kulkeneet hyvän matkaa eteenpäin. Verkosta ladattavien lisäosien yhteensopivuudessa uusimpaan versioon on vielä toivomisen varaa, mutta asia korjaantunee syksyn mittaan.

Jos pitää päästä nopeasti kiinni Ruby on Railsiin, tämä on ihan hyvä opas siihen.

PostgreSQL: Up and Running

Regina Obe ja Leo Hsu, PostgreSQL: Up and Running. A Practical Guide to the Advanced Open Source Database. O'Reilly Media, Sebastobol, CA, USA, 2012.

PostgreSQL on relaatiotietokannan hallintajärjestelmä. Sitä on kehitetty avoimen lähdekoodin projektina ammoisista ajoista; viimeisin julkaistu versio ilmestyi keväällä 2013. Regina Obe ja Leo Hsu ovat paikkatietojärjestelmien asiantuntijoita, ja tämä on heidän toinen yhteinen tietokirjansa.

PostgreSQL: Up and Running on helppolukuinen johdanto Postgresin käyttöönottoon ja ylläpitoon. Relaatiotietokannat ja niissä käytettävä kyselykieli SQL oletetaan tunnetuiksi. Kirjoittajat esittelevät PostgreSQL:n asetuksia, käyttäjäryhmien ja tietokantojen hallintaa, asennettavia lisäosia, varmuuskopiointia ja tähän kaikkeen käytettäviä työkaluja psql ja pgAdmin.

PostgreSQL sisältää SQL:n perustietotyypit, mutta Obe ja Hsu käyvät läpi tietokannan erikoisemmat tietotyypit kuten SERIAL-, ARRAY-, XML- ja aikatietotyypit. Tietokantataulujen, -näkymien ja -indeksien osalta PostgreSQL tarjoaa hieman standardista poikkeavia vaihtoehtoja. Talletettuja proseduureja, jotka PostgreSQL:ssä ovat yksinkertaisesti funktioita, voi kirjoittaa eri kielin, myös C:llä tai Perlillä. Kirjoittajat antavat lopuksi vinkkejä kyselyiden nopeuttamiseen ja analysointiin sekä datan replikointiin ja palveluiden pystyttämiseen.

Obe ja Hsu kirjoittavat helppolukuista englantia, joka alaan perehtyneelle avautuu vaivatta. Melkein poikkeuksetta kirja käsittelee aiheita pintapuolisesti, eikä pelkästään kirjan avulla esimerkiksi GIST- tai GIN-indeksien pystyttäminen tule onnistumaan. Tekstissä onkin paljon hyperlinkkejä internetistä löytyvään dokumentaatioon. Täten PostgreSQL: Up and Running on tiivis, noin 160-sivuinen johdanto asioihin, joita Postgresin kanssa kannattaa ottaa huomioon. Kirja tarjoaa vähän tiiviin johdannon ulkopuolella.

TextMate

James Edward Gray II, TextMate: Power Editing for the Mac (2007). Pragmatic Bookshelf, 2009.

TextMate on Allan Odgaardin Mac OS X -käyttöjärjestelmälle kirjoittama tekstinkäsittelyohjelma. Se ei ole WYSIWYG, eli se sopii erinomaisesti tekstitiedostojen, kuten ohjelmakoodin, kirjoittamiseen. Olen käyttänyt TextMatea satunnaisesti vuodesta 2005, mutta, koska Mac sisältää Emacsin, en ole jaksanut perehtyä TextMateen sen enempää (siinä toimivat monet Emacsin näppäimistökomennotkin). Koska tarkoitus on perehtyä Ruby on Railsiin (uudestaan), on paikallaan aloittaa se työkalujen suunnalta; TextMate on ollut erityisesti Rails-kehittäjien suosiossa.

Grayn kirja TextMate tarjoaa aivan alkuun lyhyen taustan ohjelman historiasta, asentamisesta ja kirjan käyttämistä näppäimistökonventioista. Sitten kirja valaisee tekstineditointia. Tekstinkäsittelyn perusasiat oletetaan tunnetuiksi, ja Gray pureutuu TextMaten projekti- ja tiedostohallintaan, tekstialueiden valintaan ja säännöllisten lausekkeiden soveltamiseen haku- ja korvauskomennoissa.

TextMatessa on myös viljalti kielikohtaisia automaatioita esim. useimmille ohjelmointikielille, joiden avulla voi paitsi tuottaa myös kääntää tai validoida koodia, käynnistää testejä ja komentorivikehotteita. TextMaten voi kytkeä myös osaksi sähköpostiohjelmaa tai versionhallintatyökaluksi. Lisäksi usein toistettavia tekstikatkelmia voi koota talteen ja täydentää kirjoitettavaan dokumenttiin pikanäppäimin. Usein toistettavat rutiinit voi tallentaa ja ajaa samaan tapaan pikanäppäimin.

Lopuksi Gray uhraa hyvän sivumäärän kielille ja kieliopeille. Ohjelmointikielet ja dokumenttikielet (HTML, JSON) ovat formaaleja kieliä, ja tekstinkäsittelyohjelma voi helpottaa käyttäjää validoimalla dokumentin, korostamalla kieliopin rakennetta ja niin edelleen. Lisäksi Gray käy läpi TextMaten asetukset ja muunneltavat teemat.

Tietokoneohjelmista kirjoitetut kirjat tapaavat vanheta melko nopeasti. Tämäkin teos on jo vuosia vanha. Hankin Grayn teoksen Pragmatic Bookshelfin alennusmyynnistä. Suuri osa ohjeista löytyisi varmasti verkosta, mutta PDF kulkee kätevästi mukana. Gray kirjoittaa helppolukuista käpistelyproosaa, joka varmasti aukeaa myös maallikoille. Mitään ihmeellistä kirja ei sisällä; se on jäsennelty opas TextMaten käyttöön.

The Clean Coder

Richard C. Martin, The Clean Coder: A Code of Conduct for Professional Programmers. Prentice-Hall, 2011.

Richard C. Martin on kokenut ohjelmistoammattilainen, joka on yksi agile-manifestin luojista ja ensimmäisiä ketterien menetelmien kehittäjiä. Hänet on kirjoittanut hyväksymistestausjärjestelmän FitNessen, muutaman ohjelmointia tai ohjelmistotyötä käsittelevän kirjan.  Sittemmin Uncle-Bob on pureutunut ohjelmistokehittäjien ammattimaiseen työskentelyyn: hän yrittää kiinnittää ohjelmistokehityksen käsityöperinteeseen insinööriperinteen sijaan. The Clean Coder käsittelee juuri tätä aihetta.

Martin kadehtii lääkäreitä, jotka sitoutuvat tiettyyn työskentelytapaan ja -etiikkaan. Softa-ammattilaisilta puuttuu muutamaa jalustalle nostettua sankarikoodaajaa lukuunottamatta ihanne, so. mitä ammattilaisuus on. The Clean Coder kirjaa ammattilaisihanteen, joka on lyhyesti sanottuna vapaa-ajan investoimista osaamisen ylläpitämiseksi ja sitoutumista laatuun, yhteistyöhön ja itse esitettyihin aikatauluhin. Ammattilainen osaa painostuksesta huolimatta sanoa 'ei' ja pystyy löytämään keinot, missä voidaan sanoa 'kyllä. Martin haluaa eroon insinööriperinteestä, koska ohjelmistokehitys nojaa enemmän yksilöihin kuin prosesseihin. Niinpä yksilöiden täytyy pitää osaamisestaan, asenteestaan ja työkaluistaan huolta samaan tapaan kuin entisaikojen käsityöläismestarit.

Kirjan luvut alkavat kertomuksilla Martinin pitkän uran varrelta. Hän ruotii tekemiään virheitä, ja johtaa niistä reunaehtoja ammattimaiselle ohjelmistokehittäjälle. Kirja on helppolukuinen, mutta sen esittämä ihanne on vaativa.

Kanban and Scrum: making the most of both

Henrik Kniberg, Mattias Skarin, Kanban and Scrum: making the most of both. C4Media, 2010.

Henrik Kniberg ja Mattias Skarin ovat ruotsalaisia ohjelmistokonsultteja, jotka ovat erikoistuneet lean- ja agile-menetelmiin. Kanban and Scrum käsittelee kahta agile-menetelmää, Kanbania ja Scrumia, jotka molemmat ovat itseohjautuvat ohjelmistotiimin muutokseen sopeutuvia prosesseja. Kirjan tarkoitus on tarjoilla tiivis määritelmä kummastakin, selvittää menetelmien välisiä eroja ja näyttää esimerkein, miten ne toimivat.

Kirjan ensimmäinen osa käsittelee Kanbanin ja Scrumin yhtäläisyyksiä ja eroja. Ne ovat iteratiivisia ja inkrementaalisia, eli työtä tehdään toistettavissa sykleissä ja työ tehdään pienissä palasissa, jolloin muutoksiin reagoiminen on helpompaa. Tiimi kokoontuu säännöllisesti käsittelemään ohjelmistoprosessinsa ongelmia ja korjaamaan niitä.

Menetelmistä Scrum asettaa enemmän vaatimuksia: roolit, backlogin priorisointi, päivittäiset tapaamiset, kehitysnopeuden mittaus ja itseohjautuvuus. Työkuormaa rajoittaa iteraation pituus ja kehitysnopeus. Kanban rajoittaa ainostaan samanaikaisten keskeneräisten tehtävien määrää pyrkien optimoimaan läpimenoaikaa. Se voi sopia mm. itsenäisesti tehtävien, ylläpitotöiden tapaisten toisistaan riippumattomien tehtävien hallintaan.

Kirjan toinen osa käy läpi tapausesimerkkejä. Esimerkkien tukena on kaavakuvia, piirroksia ja valokuvia.

Kanban and Scrum on noin satasivuinen kirjanen. Lyhyydestään huolimatta sivut ovat väljästi taitetut, ja tekstissä on hieman toistoa. Tiiviinä johdantona se on kuitenkin ihan toimiva.

The Pragmatic Programmer

Andrew Hunt, David Thomas, The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley, 1999.

Yhdysvaltalaiset ohjelmistoammattilaiset Andrew Hunt ja David Thomas päätyivät kirjoittamaan kokemuksistaan ja näkemyksistään kirjan The Pragmatic Programmer. Kirja on ollut menestys yli kymmenen vuotta, ja miehet ovat sittemmin perustaneet The Pragmatic Bookshelf -kustantamon.

Sana pragmaattinen juontuu latinan kautta kreikasta, missä pragma tarkoittaa tekoa. Pragmaattinen ohjelmoija on siis käytännöllinen: hän on realistinen, järkevä ja hänen työtään ohjaavat sellaiset teoreettiset periaatteet, jotka toimivat käytännössä. Noh, dialektis-materialistinen pilailu sikseen.  

The Pragmatic Programmer lähtee siitä, miten ollaan ohjelmointiammattilainen. Ohjelmointi on käsityötä, ja kirjoittajat pohjustavat analogioissaan käsityöläisperinnettä ja -etiikkaa. Ammattilaisen tulee pitää työkalunsa (osaamisensa) hyvässä kunnossa, seurata alan kehitystä ja omaksua uusia menetelmiä uusien (ja vanhojen) ongelmien äärellä.  Kirjoittajat kokoavat kirjan lukuihin ohjeita aiheittain kattaen mm. pragmaattisen ajattelutavan, työkalut, ongelmanratkaisun, suunnittelun, projektien hallinnan, testaamisen ja vaatimusten, muutosten sekä versioiden hallinnan. Argumentaatio, esimerkit ja tiivistelmät ovat kaikki hyvin käytännönläheisiä.

Ammattilaisuus ja ammattietiikkaan sitoutuminen on hieno päämäärä itsessään. Sitten kirjoittajat menevät esittämään, että olisi hyvä tunnistaa keskeisiksi muuttuvia teknologioita ajoissa, jotta voisi paukutella henkseleitään ja leuhottaa sitten, kun teknologia on valtavirtaa. Tässä kyse on kilpailusta ja pätemisestä, mitkä eivät liity ammattilaisena olemiseen sinänsä. Tämä lipsahdus ja kirjan jaaritteleva sä-passiivi ovat keskeiset heikkoudet.

The Pragmatic Programmer on ollut olennaisesti muokkaamassa ohjelmistoammattilaisuuden työtapoja ja menetelmiä. Edellisestä lukukerrasta on viisi vuotta, ja nyt kirjan esittämät ajatukset tuntuivat omilta.

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ä.

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ä.

Object-oriented and Classical Software Engineering

Stephen R. Schach, Object-oriented and Classical Software Engineering, 6th ed. McGraw-Hill, New York, NY, 2005. 

Eteläafrikkalainen Stephen R. Schach valmistui maisteriksi fysiikasta, mutta vaihtoi pian alaa, väitteli matematiikasta ja päätyi ohjelmistotuotantoprosesseja tutkivaksi tietojenkäsittelijäksi. Vaikka tietojenkäsittelyssä on monta mielenkiintoista tutkimusaluetta, ohjelmistotuotannon saavutuksilla lienee kauaskantoisimmat vaikutukset tutkimusalueen ulkopuolella "todellisuudessa". Niin, ohjelmistotuotanto (software engineering) on oppisuunta, joka tähtää virheettömän, käyttäjän tarpeita vastaavan ohjelmiston toimittamiseen sovitussa aikataulussa ja budjetissa. Jotta näihin ideaaleihin päästään, on syytä ohjelmistoa kehittäessä soveltaa sopivia tekniikoita, joita mm. tässä kirjassa käsitellään.
 
Heti alkuun Schach lukeekin opiskelijalle tai tulevalle ammattilaiselle madon luvut. Vuonna 2000 tehdyn 280,000 kehitysprojektia käsittäneen tutkimuksen mukaan vain 28% onnistui suunnitellusti, 23% projekteista keskeytettiin, ja loput 49% toimitettiin myöhässä, arvioitua budjettia kalliimpina ja vähemmin toiminnallisuuksin (tutkimustuloksia on tietenkin sittemmin arvosteltu). Toisen, vuonna 1976 tehdyn tutkimuksen tunnistama huono onnistumisprosentti herätti keskustelun ohjelmistokriisistä. Oman kokemukseni mukaan kriisi on kaikkea muuta kuin ohi.

Ennen vuotta 1975 alalla ei ollut juuri laajalle levinneitä kehitysmenetelmiä. Klassinen ohjelmistokehitysmalli hahmottui seuraavan kymmenen vuoden aikana tarjoten järjestelmälliset tavat tietorakenteiden ja -voiden analyysiin, ohjelmointiin ja testaukseen. Malli osoittautui kuitenkin riittämättömäksi järjestelmien kasvaessa ja kompleksisuuden lisääntyessä. Klassiset menetelmät keskittyvät tyypillisesti operaatioihin, joilla tietoa muokataan, tai sitten tietomallinnukseen, jonka ympärille ohjelmisto rakennetaan, mutta ei molempiin. Olio-ohjelmointi on paradigma, jossa tieto ja sitä koskevat operaatiot paketoidaan olioiksi, joiden käyttäytyminen on huomattavasti helpompi suunnitella, toteuttaa ja testata. Olio-ohjelmoinnin edut ovat kiistattomat, ja Schach kuljettaakin klassista ohjelmistoparadigmaa mukana tekstissä nimenomaan vertailukohtana.

Object-oriented & Classical Software Engineering ilmestyi ensimmäisen kerran vuonna 1990. Käsillä oleva kuudes laitos on vuodelta 2005. Väliin mahtuu tietotekniikan laaja leviäminen ja internet. Kirjaa on tietenkin korjailtu ja kirjoitettu uudestaan, mutta osa tekstistä nojaa vanhoihin lähteisiin. Tämä on hyvä ja huono. Hyvä se on siksi, että tietojenkäsittelytiede ei ole eikä pitäisi olla pelkkää tekniikkaa vaan myös kulttuuri. Monien "uusien" juttujen juuret ovat 1970-luvulla tai kauempana. Näin on esimerkiksi inkrementaalisen ja iteratiivisen projektimallin kohdalla, samoin olio-ohjelmoinnin. Huonoa on se, että, jos nopeasti kehittyvältä alalta pitää antaa yleiskatsaus, vanhojen ja todennäköisesti vähän käytettyjen ohjelmistometriikoiden läpikäyntiin ei ole ehkä tarve uppoutua. Pahempi ongelma on, että eri aikoina kirjoitettu teksti ei kulje luvusta toiseen kauniisti, vaan se tuntuu erityisesti loppua kohden poukkoilevan.

Kirjan ensimmäinen osa esittelee ohjelmiston elinkaarimalleja, kehitysprosesseja, kehitystiimejä, kehitystyökaluja, testausta, suunnittelua, uudelleen käyttöä, suunnittelua ja arviointia. Toinen osa käsittelee ohjelmiston elinkaaren työnkulkuja (workflow) kuten mm. vaatimusmäärittely (klassinen ja oliomalli), suunnittelu, toteutus ja ylläpito. Kaaviot ovat pääosin joko ER tai UML-tekniikoin piirrettyjä. Kiusallista on, että Java-ohjelmointiesimerkit, jotka ovat toki vain esimerkkejä, rikkovat paikoin Javan perusideologiaa. Kirjoittaja mainitsee agile-menetelmät mutta ei usko niiden voimaan suurten projektien toteutuksessa. Vastaesimerkkejä on olemassa, mutta Agile-menetelmät vaatinevat tiukkaan ammattietiikkaan sitoutumista, ja kovat ammattilaiset saavat millä tahansa menetelmällä asiat hoidettua -- Agile-menetelmät ovat vain yksi hyvä tapa. Jos tekijätiimissä vallitsee vaatimattomampi ammatillinen eetos, esim. vesiputousmalli takaa, että useimmiten saadaan edes jotain ulos jossain vaiheessa.

Kirja oli hyvä muistinvirkistys, ja eheämpi sisällysluettelo tekisi kirjasta kohtuullisen manuaalin. Hajanaisuus on ehkä tiedostettu, koska Schachilta julkaistiin heti 2007 uusi teos Object-Oriented Software Engineering, josta siis klassinen menetelmistö on pudonnut ainakin otsikosta.

Database Modeling and Design

Toby Teorey, Sam Lightstone, Tom Nadeau, Database Modeling and Design: Logical Design, fourth edition. Morgan Kaufmann, San Francisco, CA, USA, 2006.

Tietokanta on kokoelma rakenteista tietoa (esim. kalenteri, kortisto, asiakasrekisteri). Usein tietokannalla tarkoitetaan nimenomaan digitaalista relaatiotietokantaa. Database Modeling and Design on oppikirja relaatiokannan suunnitteluun ja toteutukseen. Kirjoittajista Teorey toimii professorina Michiganin yliopistossa, Lightstone on tutkijana IBM:llä, ja Nadeau puunaa järjestelmiä yritysmaailmassa.

Kirja käsittelee tietokannan elinkaaren suunnittelusta ja loogisesta mallista fyysiseen malliin, toteutukseen ja viimein tuotantoon. Sisältö keskittyy alaotsikon mukaisesti nimenomaan toiseen vaiheeseen eli loogiseen malliin: mitä käsitteitä tietosisällössä on ja miten niiden väliset suhteet tulisi kuvata. Työkaluista, joilla loogista mallia työstetään, esitellään Entity Relationship (ER) ja Unified Modeling Language (UML) -kaaviot. Sitten näytetään, miten vaatimukset otetaan huomioon suunnittelussa ja miten looginen malli kääntyy SQL-kielelle.

Taulujen normalisointiin on varattu kokonainen luku, mutta huolimatta tästä erityisesti neljäs ja viides normaalimuoto jäävät tekstin pohjalta utuisiksi. Sitten tarkastellaan online-analysointia (OLAP) ja sen vaatimuksia ja toteuttamista. Lopuksi luodaan katsaus suunnittelutyökaluihin, mikä on varmasti nopeiten vanheneva osa kirjan sisältöä.

Lukijalle herää kysymys, kenelle kirja on kirjoitettu? Onko se oppi- tai kurssikirja (tai kuten amerikkalaiset sanovat "tekstikirja")? Kirjassa on joitain tehtäviä kurssin tueksi, mutta esitetyt määritelmät ovat paikoin epäselviä, eikä konteksti tai esimerkit selitä niitä auki juuri sen paremmin. Peruskäsitteistö oletetaan jo tunnetuksi, eikä lopussa olevien tiiviiden liitteiden lisäksi SQL:n perusasioita käsitellä. Relaatioalgebraa tms. ei kirjassa käytetä. Kirja on sisällöltään  hieman kevyt, tai se on ainakin helppolukuinen, mutta tarkoitettu hieman pidemmälle ehtineille. Siten kirja sopii ehkä ammattilaisen muistinvirkistykseksi. Esimerkkien painopiste on liiketoimintapuolella ja sangen käytännöllisissä seikoissa.

Refactoring To Patterns

Joshua Kerievsky, Refactoring to Patterns. Addison-Wesley, Boston, MA, USA, 2004.

Yhdysvaltalainen Joshua Kerievsky on ohjelmistoalan konkari, joka on vuosien mittaan kehittänyt ja opettanut parempia työskentelytapoja. Refactoring to Patterns on otsikkona ytimekäs, mutta se tuskin aukeaa ohjelmointia heikosti tuntevalle. Kirjassa nojataan Martin Fowlerin määritelmään, jonka mukaan refaktorointi on "behavior-preserving transformation" eli ohjelmakoodin muokkaamista selkeämpään, laadukkaampaan luettavampaan ja taipuisampaan muotoon ilman, että ohjelman käyttäytyminen varsinaisesti muuttuu. Refaktorointi ei siis korjaa bugeja tai lisää uusia toiminnallisuuksia. Pattern (design pattern) on yleisesti sovellettava ratkaisumalli tietyntyyppisiin ohjelmointiongelmiin. Kirjan otsikko siis viittaa sellaiseen refaktorointiin, jonka lopputuloksena lähdekoodi toteuttaa ratkaisumalleja.

Kerievsky kirjoittaa pitkän johdannon, joka esittelee Design Patterns (Gamma et al.) ja Refactoring (Fowler) kirjojen pääteesit, vaikka kirjoittaja tuntuu (syystäkin) edellyttävän, että lukija on lukenut em. teokset. Refaktoroinnit on ryhmitelty luomiseen, yksinkertaistamiseen, yleistämiseen, suojaamiseen ja kokoamiseen liittyviin käyttötapauksiin. Jokaisesta refaktoroinnista on esitelty siihen liittyvän ratkaisumallin UML-kuvauksen lisäksi refaktoroinnin motivaatio, edut ja haitat, mekaniikka ja esimerkki monivaiheisen refaktoroinnin tekemisestä lähdekoodeineen ja kommentteineen. Viime mainitut esimerkit seulovat erinomaisella tavalla ajattelua ratkaisumallien ja refaktoroinnin takana.

Refactoring to Patterns on kovakantinen,  tyylikäs kirja. Teksti ei ole erityisen raskasta tai tiivistä, vaan Kerievsky maalailee taustaa esimerkeilleen sangen vuolaasti.