Mitä CV:ssä ei saa sanoa

Aina välillä joudun, kuten työtoverinikin, lukemaan CV:itä ja haastattelemaan ihmisiä. Näissä tilanteissa kasautuu mielikuva, että aivan kaikki eivät osaa CV:itä kirjoittaa. En tällä kertaa kuitenkaan aio juuttua tavanomaiseen kritiikkiini liian pitkästä dokumentista. On asioita, joita ei missään nimessä pidä mainita CV:ssä.

Työhaastattelussa ei saa kysyä ihan mitä tahansa. Tyypillinen, ja luultavasti eniten rikottu kielto, on kysyä siviilisäätyä ja lastentekoaikeita. Näitä ei ole kielletty huvin vuoksi, vaan tarkoituksena on estää niitä toimimasta työhönottoperusteena. Tästä johtuen vastavuoroisesti sille, ettei haastattelija saa kysyä, ei myöskään haastateltavan tule ottaa näitä erikseen puheeksi. Asioita, joista ei ole valmis puhumaan haastattelussa, ei myöskään tule kirjata CV:hen.

Kiellettyjen aiheiden oma-aloitteisessa esittelyssä on kaksi ongelmaa.

Ensinnäkin, kun haastateltava ottaa puheeksi aiheen, jota haastattelija ei saa käyttää, se asettaa haastattelijan hankalaan tilanteeseen.

Toiseksi, ja tärkeämmäksi, jos pitää CV:ssä esillä jotain faktaa tai faktoidia, eikä ole ainoa ihminen maailmassa joka näin tekee, on osaltaan luomassa kulttuuria, jossa on oletusarvo, että tämä asia mainitaan. Tämä tekee mainitsematta jättämisestä itsessään huomattavan asian. Kiellettyjen kysymysten olemassaolo tulee jokseenkin perusteettomaksi, jos työhönhaku jo implisiittisesti muuttuu tällaiseksi kysymykseksi, ja se, ettei ymmärrä antaa vastausta kysymättäkin, katsotaan epäilyttäväksi.

Niinpä siviilisäätynsä ja sotilasarvonsa CV:hen kirjoittaminen on ensisijaisesti vihamielinen toimi muita työnhakijoita kohtaan. Ehkä joidenkin mielestä työnhaku on kaikkien sota kaikkia vastaan, mutta minä en halua elää sellaisessa maailmassa.

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

Vesiputous lässyn lässyn

Viime aikoihin asti ohjelmistokehitystä on tehty lähinnä vesiputousmallilla, jossa projekti ensin määritellään, sitten suunnitellaan, sitten toteutetaan, testataan ja luovutetaan asiakkaalle. Malli on raskas ja epäkäytännöllinen. Koska asiakas on mukana vain alussa ja lopussa, hänellä ei ole kontrollia projektiin, ja alun määrittelyssä tehtyjä virheitä ei voida enää korjata.

Kuulostaako tutulta? Kaikkihan haukkuvat nykyään vesiputousmallia, ja scrum on päivän sana.

Mutta ollaanpas nyt rehellisiä. Kuka on nähnyt vesiputousmallia oikeasti käytettävän jossain isossa projektissa? Siis ikinä? Softakehitystä aidosti ilman minkäänlaisia iteraatioita, ilman suunnitelmien korjaamista toteutuksen aikana ja ilman asiakkaan osallistumista kesken projektin?

Missä yhteydessä sellaista voisi oikeastaan edes tehdä? Eihän siitä tulisi mitään.

Totuus onkin, että vesiputousmallia ei ole tarkoitettukaan toteuttettavaksi. Se on oikeastaan referenssimalli, joka listaa asiat joita pitää jossain vaiheessa projektia tehdä.

Vesiputousmallin esitteli Winston W. Royce vuonna 1970 artikkelissaan Managing the development of large software systems. Yllä oleva klassinen vesiputouskaavio on samasta artikkelista. Heti kuvan jälkeen seuraava lause on “I believe in this concept, but the implementation described above is risky and invites failure.”

Loppuosan artikkelistaan Royce käyttääkin sen selittämiseen, miksi tämä hänen olkinukeksi luomansa prosessimalli ei ole realistinen ja miten asiat oikeastaan pitäisi tehdä. Kuvaus sisältää iteraatiota ja asiakkaan aktiivista osallistamista joka vaiheessa. Ja myös melko raskaan dokumentaation, ei hän varsinaisesti ketterää mallia kuvaa.

Miksi vesiputousmallia sitten on esitelty vuosikymmeniä ohjelmistokehityksen vakiomallina, jos se ei ole edes tarkoitettu käytettäväksi sellaisenaan? Hyvä kysymys. Ehkä mallien toteuttamista ei otettu niin kirjaimellisesti, vaan oli tarkoitus osata soveltaa? Sitä voi olla vaikea ymmärtää, mutta äänestettiinhän joskus Kekkostakin. Se oli eri maailma.

Vastaavaan tapaan taloustieteessäkin käytetän yksinkertaistettuja malleja, joissa tehdään epätosiksi tiedettyjä oletuksia. Kaikki mallit ovat vääriä, mutta jotkut ovat hyödyllisiä. Kysymys ei olekaan siitä, kuvaako vesiputousmalli tai vaikka scrum softaprojektin tekemistä “oikein”, vaan siitä, auttaako malli meitä kiinnittämään huomiota oleellisiin kohtiin. Ja tässä vesiputousmalli on huono: se mahdollistaa jatkamisen tyytyväisenä eteenpäin aivan väärään suuntaan.

Oli miten oli, ketteriä menetelmiä ei ehkä kannattaisi enää markkinoida sillä, miten vesiputousmalli ei vastaa todellisuutta. Se olkinukke alkaa olla poltettu loppuun. Parempi puhua niiden hyödyistä sen sijaan.

Aiheesta enemmän myös täällä.

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

Kertakäyttökoodista

Ohjelmoijien kansanperinteeseen kuuluu erottelu kertakäyttökoodiin ja tuotantokoodiin. Tuotantokoodin erilaisia laatutasojakin nähdään yleensä olevan ainakin muutamia. Haluan kuitenkin tarkastella kertakäyttökoodin käsitettä.

Koska koodi kuitenkin jää olemaan, ja on riski sen uudelleenkäytöstä, pitäisi tunnustaa tosiasiat, eikä elää valheessa. Kaikki koodi pitäisi kirjoittaa vähintään minimaalisella tuotantokoodin tasolla: kehittäjän itsensä pitää ymmärtää se myös puolen vuoden päästä.

Ohjelmoijan tapa käyttää tietokonetta on kuitenkin sellainen, jossa on epäselvää missä vaiheessa siirrytään komentorivien kirjoittamisesta ohjelmointiin. “ls -lt | head” ei varmaankaan vielä ole ohjelmointia. Onko “awk -f ‘{x+=$3} END {print x}'”? Raja on epäselvä.

Ohjelmoinniksi pitäisikin varmaan alkaa kutsua komentorivejä, jotka ovat paisuneet niin hankaliksi, ettei niiden lukeminen enää ole suoraviivaista. Tässä vaiheessa niistä pitäisi tehdä minimissäänkin shelliscripti ja antaa sille kuvaava nimi. Rakenteellisen ohjelmoinnin käytäntöihin siirtyminen ei myöskään ole pahitteeksi.

Kertakäyttökoodia on olemassa vain teoriassa, koska kaikesta koodista jää jäljet. Koodi pitäisi aktiivisesti hävittää saman tien, että se voisi jäädä kertakäyttöiseksi.

Toisaalta komentorivien tallennus on äärimmäisen hyödyllistä minkään järjellisen työtehon säilyttämisen kannalta. Tässä on selvästi ristiriitaiset tavoitteet. Säilyttäminen parantaa työtehoa lyhytaikaisesti, mutta hävittäminen vähentää ylläpitokuormaa pitkällä aikavälillä. Ideaalitilanteessa komentorivikieli olisi itsedokumentoivampi kuin nykyiset melko hirveät kissanoksennukset.

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

Mobile Dev Camp 2010

Lauantaina tuli käytyä Mobile Dev Camp -tapahtumassa Helsingissä: luvassa oli eriaiheisia mobiilikehitykseen liittyviä esityksiä ja paneelikeskustelua.

Esitykset olivat keskimäärin kiinnostavia ja liittyivät kattavasti useampiin suosittuihin alustoihin, kuin Nokian Qt, Windows Phone 7 Series ja iPhone -ympäristöt. Windows Phone 7 Seriesin teknisistä yksityiskohdista esittäjä ei tosiaan voinut kertoa paljon, koska virallinen julkaisu on tulossa vasta lähitulevaisuudessa.

Paneelikeskustelut koskivat muun muassa cross platform -kehityksen, eli saman sovelluksen tuominen useammalle alustalle, haasteita. Paneelista löytyi runsaasti kokemusta aiheesta, ja monet näyttivät suunnittelevan tuotteensa usealle alustalle heti alusta. Yleisesti cross platform -kehitys kuulosti olevan kannatava hanke, jonka haasteille löytyy ratkaisuja ja neuvoja muiden kokemuksista.

Toinen paneelikeskustelu koski kysymystä natiivisovellusten olemisesta vastaan websovellukset. Tässä keskustelussa korostui käytettävyys- ja maksukysymykset. Natiivisovelluksilla on paremmat mahdollisuudet sulattua ympäristöönsä ja suorittaa hyvin, sekä hyödyntää myyntiä helpottavia sovelluskauppoja. Websovellusten lyhyempi kehitysaika ja siirrettävyys houkuttaa, mutta vaikeus periä maksuja webissä on edelleen haaste.

Mobile Dev Camp näyttää olevan hyödyllinen tapahtuma kaikille mobiilikehityksestä kiinnostuineille. Palaan mielellä seuraavana vuonna.

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