Konsultin rooli

Kun ohjelmistotaloon tilataan ohjelmistokonsultti, tällä voi olla kolme erilaista roolia. Tarkatselen tässä siis nimenomaan konsultin roolia suhteessa tilaajana toimivaan ohjelmistoyritykseen, en niinkään hänen työnsä varsinaista substanssia.

1. Työntekijä

Konsultti voi tulla paikalle tekemäään mitä käsketään. Siis samaa työtä kuin työntekijätkin saman työnjohdon alaisuudessa.

Tässähän on kyse henkilöstövuokrauksesta. Ohjelmistoalalla vuokrahenkilöstöä vaan tavataan kutsua konsulteiksi. Drinkkejä ei tiskin takana yleensä tee baarikonsultti, eikä tuoppeja plokkaa tarjoilijakonsultti, mutta koodia konsultti vääntää.

Usein kun selitän mitä teen työkseni, kuulija jossain vaiheessa sanoo “ai siis sä teet /oikeeta/ konsultointia”. Kaksi seuraavaa kategoriaa ovat sitten sitä “oikeaa konsultointia”.

2. Ekspertti

Konsultti voi tulla paikalle erityisasiantuntijana, esimerkiksi kertomaan miten asia X, jota ei talon sisällä osata niin hyvin, pitäisi tehdä. Eksperttikonsultti voi myös tulla vaikka auditoimaan ohjelmiston, tietoturvakäytännöt tai muuta vastaavaa.

Oleellista on, että ekspertti tietää asiakasta paremmin miten jokin asia pitää tehdä, ja tulee sen kertomaan.

3. Yhteistyökumppani

Yhteistyökumppanina konsultti pyrkii yhdessä asiakkaan henkilöstön kanssa ratkaisemaan asiakkaan ongelman niin, että seuraavalla kerralla konsulttia ei tarvita.

Johdon konsultit toimivat järjestään tässä moodissa. Kyllä jokainen heidän asiakkaansa osaa johtaa yritystä, kyse on vaan työtapojen petraamisesta yhdessä ulkopuolisen kanssa.

Konsultti ei voi toimia yhteistyössä itsekseen. Toimintatapa edellyttääkin, että asiakkaan puolella on selkeästi nimetty pienehkö ryhmä ihmisiä, jotka osallistuvat aktiivisesti projektiin. Joskus ryhmä on olemassa ennestään, toisinaan se kootaan varta vasten konsulttiprojektia varten.

Käytännössä jokainen konsulttiprojekti on tietenkin näiden kolmen ääripään välimuoto, usein kuitenkin lähempänä yhtä nurkkaa kuin muita. Tilanteessa, jossa noiden välillä pääsee vapaasti valitsemaan, yhteistyömoodi tuottaa yleensä parhaita tuloksia. Useimmiten tietysti projektin reunaehdot rajoittavat valinnan vapautta jo huomattavasti.

Asiakkaan kannalta ajateltuna: konsulttiprojektia tilatessa on hyvä miettiä, tarvitaanko 1) joku paikan päälle tekemään mitä käsketään, 2) expertti kertomaan meille mitä tehdä, vai 3) joku auttamaan suunnittelussa niin että ensi kerralla osataan jo itse.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Avoimen lähdekoodin projekteihin entistä helpompaa osallistua

Jos olet ohjelmistojen kehittäjä, olet melko varmasti jossain vaiheessa syystä tai toisesta tutkinut niin kutsuttuun avoimeen lähdekoodiin perustuvan ohjelmiston lähdekoodia.  Mahdollisesti löysit lähdekoodista myös jotain, jota halusit muuttaa.  Tässä vaiheessa usein herää kysymys: pidänkö muutoksen itse, vai pyrinkö saada muutoksen hyväksyttyä alkuperäisprojektiin?  Tässä kirjoituksessa ei kiinnosta periaatteelliset lisenssikysymykset, vaan julkaisemisen vaiva (ohjelmistoprojektin ulkopuoliselle, jolla ei ole kirjoitusoikeuksia projektin versiohallintaan), ja miten muutoksen julkaiseminen nyt voi olla aikaisempaa huomattavasti helpompaa.

Julkaiseminen on aikaisemmin tarkoittanut haaran luomista versiohallinnassa, lähdekoodipatshin ylläpitämistä ja muutosehdotuksen toimittamista esim. sähköpostissa. Kaiken lisäksi pitää muotoilla saatekirje, jossa muutos esitetään. Tämän lisäksi vastaanottajalle on vaivalloista käsitellä satunnaisesti saapuvia muutosehdotuksia käsin: lukea ja lajitella sähköpostit, soveltaa patshit ja ylläpitää niitä siihen asti kunnes ne joko hyväksytään tai hylätään.

Hajautetut versiohallintajärjestelmät kuin esim. Git ovat paljolti helpottaneet ulkopuolisten osallistumista projekteihin — nyt myös ulkopuoliset voivat hallitusti ylläpitää haaroja.  Mutta edelleen muutoksien julkaiseminen ja hyväksyminen alkuperäisprojektiin voi olla vaivalloista käytännöllisistä syistä.

Minkälainen ratkaisu vähentäisi sekä muutoksen ehdottajan että vastaanottajan vaivoja huomattavasti?  Entä jos muutoksen pystyisi hallitusti julkaista yhdellä komennolla, suoraan ulkopuolisen versiohallintajärjestelmästä? Ja myös vastaanottaa hallitusti yhdellä komennolla, suoraan projektin versiohallintajärjestelmään? Tämä on jo suurin osin mahdollista GitHub -ympäristössä. GitHub:in pull requests -ominaisuus sallii ulkopuolisen hallitusti ehdottaa muutoksia projektin lähdekoodiin. Vastaanottaja voi hallitusti sulattaa tai hylätä valitut muutokset.  Toistaiseksi tämä on harmi kyllä GitHub-spesifinen ominaisuus, mutta leviää toivottavasti myös muualle ajan myötä.

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Go, eli oliko muuta korjattavaa kuin CREAT

Google – tai itse asiassa C:n syyllisenä tunnettu Ken Thompson ja hyvin pieni joukko muita Googlen työntekijöitä – ovat paljastaneet maailmalle kehittäneensä uuden keskimatalan tason ohjelmointikielen.

Julkilausumassa esitellään useita perusteita teolle. Ilmeistä kuitenkin on, että haetaan C:lle tappajaa. Tätä on yritetty ennenkin, eivätkä hyvätkään kielet ole siinä onnistuneet. Mitä tällä kertaa on tehty eri tavalla?

Automaattinen muistinhallinta on katsottu välttämättömäksi. Slicet ovat siisti tapa osoittaa mielivaltaisiin osiin arrayita. (Slicejen erityislaatuisuus Gon tyyppijärjestelmässä sen sijaan ei ole ihan niin siistiä. Tästä myöhemmin lisää.) Automaattisen muistinhallinnan puute tuomitsi C++:n epäoleellisten kuriositeettien joukkoon, mikä oli ilmeistä kaikille jo muutamassa vuodessa. Tässä Go on siis valinnut oikein.

Automaattisen muistinhallinnan filosofian seuraus on luonnollisesti, ettei kielessä voi tehdä pointteriaritmetiikkaa, paitsi osuvasti nimetyn unsafe-paketin kautta.

Mielenkiintoisena valintana eksplisiittinen tyyppihierarkia on jätetty pois. Implisiittisiä tyyppejä on saatettu kokeilla ennenkin, ainakin idea on vanha. Ei tule kuitenkaan mieleen yhtään tällaista kieltä, joten siinä mielessä valintaa on pidettävä rohkeana muuten melko konservatiivisten ratkaisujen seassa.

Jostain käsittämättömästä syystä Gossa – kielessä, jossa ei ole parametrisoitavia tyyppejä – on kokonaista viisi erilaista parametrisoitua tyyppiä: arrayt, slicet, mapit, pointterit ja kanavat. Lisäksi näistä slicet, mapit ja kanavat toimivat eri tavalla kuin kielen muut objektit. Minusta kieli olisi merkittävästi siistimpi, jos tässä vaiheessa olisi luovutettu ajatuksesta, ettei parametrisoitavia tyyppejä tarvita, hyväksytty tyyppiparametrit, tehty näistä kaikista parametrisoitavia tyyppejä ja, mikä tärkeintä, unohdettu make()n ja new()n erottelu. Tästä seuraisi se hinta, että slicejä, mapeja ja kanavia pitäisi erikseen käsitellä pointterien kautta, mutta toisaalta siitä olisi se etu, ettei tarvitse muistaa, että vaikka slicet, mapit ja kanavat näyttävät arvosemantiikan mukaisesti käyttäytyviltä (kuten numerot, stringit, jne), tosiasiassa niiden sisältöä voi muuttaa, jolloin parempi käsitemalli onkin referenssisemantiikka. Kielessä on siis kolme eri muuttujasemantiikkaa: arvot, referenssit ja pointterit, joista referenssejä ei syntaktisesti merkitä erikseen, vaan ne seuraavat automaattisesti siitä kun sliceja, mapeja ja kanavia käytetään arvoina. Kaksi semantiikkaa on yleisesti koettu riittäväksi.

Itse asiassa, jos kielessä olisi parametrisoitavat tyypit, voisi referenssien määrätä aina osoittavan johonkin, eli null pointerit olisivat oletuksena kiellettyjä. Niitä käyttötapauksia varten, joissa tyhjä osoitus on haluttava, olisi erillinen Maybe[T], joka on unionityyppi T-pointterista ja yksittäisestä null-arvosta. Rohkea nosto oikeista funktionaalisista kielistä ehkä, mutta Hoaren miljardin dollarin virhe olisi iso virhe korjattavaksi. Samalla vaivalla, kun suunnittelee uuden kielen pienten vikojen korjaamiseksi, voisi korjata isotkin, sikäli kun ne ovat tunnettuja.

Nämä kaikki huomiot ovat kuitenkin luonteeltaan teknisiä. Loppujen lopuksi tekniset ominaisuudet voivat vain upottaa kielen, eivät tehdä siitä menestystä. Tärkeämpi kysymys on: onko maailmassa tällä hetkellä tilaa uudelle kielelle? Aika näyttää. Googlella on vankka historia työkalujen itse tekemisestä, vaikka vastaavia olisi markkinoilla kuinka. Se, että Google on vaivautunut rahoittamaan kielen kehittämisen, ei ole todiste oikeastaan mistään.

Parin ensimmäisen vuoden aikana nähdään lähteekö Go lentoon vai ei. Jos Windows-versiota ei ilmesty vuoden sisään, ennuste on äärimmäisen kehno. Mutta ensisijaisesti uusi kieli tarvitsee ohjelmoijilta buy-inia, ja sitä ei tule ilman hyvää markkinointia. Google on tietysti maailman suurin markkinointifirma. Markkinointikampanjaa odotellessa.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.