Joel on Software   Joel ohjelmistoista

Lisää suomenkielisiä Joel on Software -artikkeleita.

Lisää englanninkielisiä Joel on Software -artikkeleita.

Lähetä sähköpostia kirjoittajalle (vain englanniksi)

Oletko koskaan kuullut SEMA:sta? Se on melko pienen piirin tuntema systeemi, jolla mitataan kuinka hyvä ohjelmointitiimi on. Ei, odota! Älä klikkaa sitä linkkiä! Sinulta menee kuusi vuotta pelkästään niiden juttujen ymmärtämiseen. Olen kehitellyt oman, täysin vastuuttoman ja lepsun testin ohjelmointitiimien laadun arviointiin. Mahtavaa siinä on se, että se vie noin 3 minuuttia. Voit käydä lääketieteellisen siinä ajassa, minkä säästät.

Hieno puoli Joelin Testissä on, että jokaiseen kysymykseen on helppo ja nopea vastata kyllä tai ei. Ei tarvitse laskea koodirivejä-per-päivä tai keskimääräistä-bugien-taittopistettä. Annat tiimillesi yhden pisteen jokaisesta kyllä-vastauksesta. Testin huono puoli on, että sitä ei pitäisi käyttää varmistamaan, että olet tehnyt turvallista softaa ydinvoimalaan.

12 pistettä on täydellistä, 11 siedettävää mutta 10 tai sen alle tarkoittaa, että teillä on vakavia vaikeuksia. Totuuden nimessä on sanottava, että useimmat ohjelmisto-organisaatiot saavat 2 tai 3 pistettä ja tarvitsevat paljon apua, koska Microsoftin kaltaiset yritykset pyörivät kahdellatoista koko ajan.  

Nämä eivät tietenkään ole ainoat asiat, jotka määräävät menestymisen tai epäonnistumisen: jos teillä on mahtava ohjelmointitiimi tekemässä tuotetta, jota kukaan ei halua, niin, no, sitä ei kukaan halua. On myös mahdollista kuvitella tiimi täynnä "guruja," jotka eivät tee mitään näistä asioista, mutta jotka silti tuottavat uskomatonta softaa, joka muuttaa maailman. Yleensä kuitenkin jos nämä 12 asiaa ovat kunnossa, teillä on kurinalainen tiimi, joka pystyy toistuvasti toimittamaan sen mitä lupaa.

1. Käytättekö versionhallintaa?
Olen käyttänyt sekä kaupallisia versionhallintajärjestelmiä että CVS:ää, joka on ilmainen ja voin vakuuttaa, että CVS on ihan hyvä. Jos ette käytä versionhallintaa, ohjelmoijasi stressaantuvat kun he yrittävät tehdä yhteistyötä. He eivät voi mitenkään tietää mitä toiset ovat tehneet. Virheitä ei pystytä helposti perumaan. Versionhallinnan käytöstä on sekin etu, että lähdekoodista on kopio jokaisen ohjelmoijan kovalevyllä. En ole vielä koskaan kuullut projektista, joka olisi käyttänyt versionhallintaa ja menettänyt paljon koodia.

2. Voitteko tehdä buildin yhdellä askeleella?
Tällä tarkoitan: Kuinka monta askelta on julkaisukelpoisen buildin tekemisessä uusimmasta lähdekoodista. Hyvillä tiimeillä on yksi skripti, joka hakee lähdekoodin, kääntää kaiken, rakentaa EXEt, kaikki mahdolliset versiot, kielet ja #ifdef-kombinaatiot, rakentaa asennuspaketit ja luo lopullisen median -- olkoon se sitten CD-levyn image, webisaitti, josta softa on ladattavissa tai mitä vaan.

Jos prosessissa on enemmän kuin yksi askel, siihen tulee helposti virheitä. Kun julkaisuhetki on lähellä, "viimeiset" bugit täytyy pystyä korjaamaan nopeasti, tekemään lopulliset EXEt jne. Jos koodin kääntämisessä, asennusohjelman rakentamisessa jne. on 20 askelta, menee sekaisin ja tekee tyhmiä virheitä.

Tästä nimenomaisesta syystä viimeisessä työpaikassani vaihdettiin WISE:sta InstallShield:iin. Me vaadimme, että asennus piti pystyä ajamaan skriptistä, automaattisesti, joka yö, NT:n ajastimesta. WISE:a ei pystynyt ajamaan schedulerista yön aikana, joten heitimme sen menemään. (WISE:n mukavat tekijät vakuuttavat minulle, että heidän viimeisin versionsa tukee jokaöisiä buildejä.)

3. Teettekö päivittäisiä buildejä?
Kun käytetään versionhallintajärjestelmää, yksittäinen ohjelmoija voi joskus vahingossa rikkoa buildin. Hän on voinut esimerkiksi lisätä uuden tiedoston ja kaikki kääntyy hienosti ohjelmoijan omalla koneella. Hän unohtaa kuitenkin lisätä tämän tiedoston versionhallintaan. Sitten hän lukitsee koneensa ja lähtee kotiin onnellisena ja tietämättömänä. Kukaan muukaan ei pysty tekemään töitä ja heidänkin on mentävä kotiin, mutta onnettomana.

Buildin rikkominen on niin paha (ja yleinen) ongelma, että buildejä kannattaa tehdä joka päivä, jotta kaikki hajoamiset varmasti huomataan. Isoille tiimeille hyvä tapa varmistaa, että hajoamiset korjataan heti, on tehdä päivittäinen buildi joka iltapäivä, vaikkapa lounasaikaan. Ennen lounasaikaa kaikki saavat lisätä koodia versionhallintaan niin paljon kuin haluavat. Kun palataan lounaalta takaisin, buildi on valmis. Jos se onnistui, hienoa! Jokainen hakee viimeisimmät lähdekoodit ja jatkaa työntekoa. Jos buildi epäonnistui, se korjataan ja sillä aikaa muut voivat jatkaa hommia käyttäen lähdekoodin edellistä, ehjää versiota.

Excelin kehitystiimissä meillä oli sellainen sääntö, että jos joku rikkoi buildin, hän sai "rangaistukseksi" pitää huolta buildeistä kunnes joku toinen rikkoi sen. Tämä antoi hyvän motivaation olla rikkomatta buildiä ja toisaalta kaikki pääsivät tutustumaan buildiprosessiin ja joutuivat oppimaan miten se toimii. 

Lue lisää päivittäisistä buildeistä artikkelistani Päivittäiset buildit ovat ystäviäsi.

4. Onko teillä vikatietokanta?
Sano mitä sanot, mutta julkaiset huonoa koodia jos kehität ohjelmia, vaikka vain yksinäsi, ilman tietokantaa, jossa kaikki tunnetut viat on listattu. Monet ohjelmoijat luulevat, että he pystyvät muistamaan kaikki viat. Höpönlöpön. Minä ainakaan en pysty muistamaan kuin pari kolme vikaa kerrallaan ja jo seuraavana aamuna tai julkaisukiireiden painaessa päälle kaikki on unohtunut. Vioista on aivan pakko pitää kirjaa tarkasti ja muodollisesti.

Vikatietokanta voi olla monimutkainen tai yksinkertainen. Pienin käyttökelpoinen vikatietokanta sisältää ainakin seuraavat tiedot jokaisesta viasta:

• täydelliset ohjeet vian toistamiseksi
• miten ohjelman piti toimia
• miten ohjelma kuitenkin toimi (vika)
• kuka hoitaa sen
• onko se korjattu vai ei

Jos vianseurantajärjestelmien monimutkaisuus on tähän asti estänyt sinua pitämästä kirjaa vioista, teet vain taulukon, jossa on 5 saraketta ja rupeat käyttämään sitä.

Enemmän vianseurannasta artikkelissa Kivuton vianseuranta. 

5. Korjaatteko viat ennen kuin kirjoitatte uutta koodia?
Aivan ensimmäinen Microsoft Word Windowsille oli projektina oikea "pitkä marssi". Se kesti ikuisuuden. Se myöhästyi jatkuvasti. Koko tiimi teki naurettavan pitkää päivää, projekti myöhästyi taas ja taas ja taas ja stressi oli uskomaton. Kun se perkule lopulta julkaistiin, vuosia myöhässä, Microsoft lähetti koko tiimin Cancuniin lomalle ja sitten istuttiin harrastamaan vakavaa itsetutkiskelua.

Heille valkeni, että projektipäälliköt olivat panneet niin paljon painoa "aikataulun" pitämiselle, että ohjelmoijat olivat koodanneet hätäisesti ja tuloksena oli erittäin huonoa koodia, koska vikojen korjaamista ei oltu sisällytetty aikatauluun. Vikojen määrää ei yritettykään pitää alhaalla. Itse asiassa päinvastoin. Tarina kertoo, että eräs ohjelmoija, jonka piti kirjoittaa koodi, joka laskee rivin korkeuden, kirjoitti vain "return 12;" ja odotti vikaraporttia siitä että hänen funktionsa ei aina toimi oikein. Aikataulu oli vain ostoslista ominaisuuksille, jotka odottivat muuttumista vioiksi. Projektin jälkianalyysissä tälle annettiin nimi "äärettömien virheiden metodologia".

Ongelman korjaamiseksi Microsoft otti kaikkialla käyttöön "vikoja nolla -menetelmän". Monet firman ohjelmoijista naureskelivat, koska se kuulosti siltä kuin johtajat luulisivat pystyvänsä vähentämään vikoja vain käskemällä vikojen kadota. Itse asiassa, "vikoja nolla" tarkoitti, että vikojen korjaaminen on aina tärkeämpää kuin uuden koodin kirjoittaminen. Tässä syy. 

Yleensä, mitä pidempään odotat ennen kuin korjaat bugin, sitä kalliimpaa se on (sekä ajassa että rahassa laskien.)

Esimerkiksi, kun teet kirjoitus- tai syntaksivirheen, jonka kääntäjä huomaa, sen korjaaminen on käytännössä ilmaista.

Kun koodissasi on vika, joka paljastuu heti kun yrität ajaa ohjelman, pystyt korjaamaan sen nopeasti koska koodi on vielä tuoreena muistissasi.

Jos löydät vian koodista, jonka kirjoitit muutamaa päivää aiemmin, sinulta menee jonkun aikaa sen löytämiseen, mutta kun luet kirjoittamasi koodin uudelleen, muistat kaiken ja pystyt korjaamaan vian kohtuullisessa ajassa.

Jos taas löydät vian koodista, jonka kirjoitit muutama kuukausi sitten, olet luultavasti unohtanut paljon siitä koodista ja sen korjaaminen on paljon vaikeampaa. Niin pitkän ajan kuluttua saatat olla korjaamassa jonkun toisen koodia, jonkun, joka on lomalla Aruballa ja tässä tapauksessa vian korjaaminen alkaa muistuttaa tutkimustyötä: on pakko edetä hitaasti, järjestelmällisesti ja harkiten etkä mitenkään pysty arvioimaan kuinka kauan korjaamiseen menee.

Jos löydät vian koodista, joka on jo julkaistu, sen korjaaminen tulee aiheuttamaan huomattavia kustannuksia.

Siinä on ainakin yksi syy korjata viat heti: koska se vie vähemmän aikaa. On toinenkin syy, joka liittyy siihen, että on helpompaa ennustaa kuinka kauan kestää uuden koodin kirjoittaminen kuin korjata vika. Jos esimerkiksi pyytäisiin sinua ennustamaan kuinka kauan kestäisi kirjoittaa koodi, joka järjestää listan, pystyisit antamaan melko tarkan arvion. Jos kysyisin kuinka kauan kestää korjata vika, jossa koodisi ei toimi kun Internet Explorerista on asennettuna versio 5.5, et pysty edes arvaamaan, koska et (luonnollisesti) tiedä mikä vian aiheuttaa. Syyn löytämiseen voi mennä kolme päivää tai kaksi minuuttia.

Tämä tarkoittaa, että jos sinulla on paljon vikoja korjattavana, aikataulusi on epäluotettava. Jos taas olet korjannut kaikki tunnetut viat ja jäljellä on ainoastaan uuden koodin kirjoittamista, aikataulusi on valtavan paljon tarkempi.

Vielä yksi lisäetu vikojen pitämisessä nollassa on se, että voit reagoida nopeammin kilpailijoidesi toimiin. Joidenkin ohjelmoijien mielestä tämä on sama kuin pitäisi tuotteen julkaisuvalmiina aina ja koko ajan. Jos kilpailija julkaisee uuden ominaisuuden, joka varastaa asiakkaitasi, voit nopeasti lisätä vain tämän nimenomaisen ominaisuuden ja julkaista heti paikalla ilman, että täytyy korjata valtava määrä kehityksen aikana kertyneitä vikoja.

6. Onko teillä ajan tasalla oleva aikataulu?
Tästä päästään aikatauluihin. Jos koodisi on edes vähänkin tärkeää liiketoiminnallesi, on paljon syitä, miksi liiketoiminnan on tärkeää tietää milloin koodi on valmis. Ohjelmoijat ovat surullisenkuuluisia siitä, että eivät halua sitoutua aikatauluihin. He huutavat bisnesmiehille: "Se on valmis sitten kun se on valmis!"

Valitettavasti se ei vain riitä. Yrityksen pyörittäminen ja sen suunnittelu vaatii monia päätöksiä, jotka on tehtävä paljon ennen kuin koodi toimitetaan asiakkaille: demoja, näyttelyitä, mainoksia jne. Ainua tapa selvitä siitä on tehdä aikataulu ja pitää se ajan tasalla.

Toinen tärkeä asia aikataulussa on, että se pakottaa päättämään mitkä ominaisuudet toteutetaan ja se myös pakottaa valitsemaan vähiten tärkeät toiminnot ja karsimaan ne ennen kuin joudutaan tilanteeseen, jossa lisätään vielä tämäkin ominaisuus, koska se on niin kiva.

Aikataulussa pysymisen ei tarvitse olla vaikeaa. Lue artikkelini Kivuttomat Ohjelmoijan Aikataulut, joka kertoo yksinkertaisesta tavasta tehdä hienoja aikatauluja.

7. Onko teillä vaatimusmäärittely?
Vaatimusmäärittelyjen kirjoittaminen on kuin hammasvälien puhdistus: kaikki ovat samaa mieltä siitä, että sitä pitäisi tehdä, mutta kukaan ei tee niin.

En ole varma miksi näin on, luultavasti siksi, että ohjelmoijat vihaavat dokumenttien kirjoittamista. Jos tiimi, jossa on pelkästään ohjelmoijia, käy jonkun ongelman kimppuun, heidän mielestään on parempi ilmaista ratkaisu ennemmin koodina kuin dokumentteina. He paljon mieluummin vain hyppäävät sekaan ja rupeavat koodaamaan sen sijaan että tuottaisivat ensin vaatimusmäärittelyn.

Kun ongelma havaitaan suunnitteluvaiheessa, se voidaan korjata helposti muuttamalla muutama rivi tekstiä. Kun koodi on kirjoitettu, ongelmien korjaaminen on paljon kalliimpaa, sekä tunnetasolla (ihmiset eivät halua heittää pois koodia), että ajassa mitattuna, joten ongelmien korjaamista itse asiassa vastustetaan. Ohjelma, jota ei ole rakennettu vaatimusmäärittelyn pohjalta, on yleensä huonosti suunniteltu ja aikataulu karkaa käsistä. Tämä näyttää olleen ongelmana Netscape:lla, jossa neljä ensimmäistä versiota kasvoivat sellaiseksi sopaksi, että johtoporras teki tyhmän päätöksen heittää kaiken koodin pois ja aloittaa alusta. He tekivät saman virheen taas uudelleen Mozillan kanssa luoden hirviön, joka ei ollut kenenkään hallinnassa ja jolta meni useita vuosia ennen kuin se saavutti alfa-tason.

Oma teoriani on, että tämä ongelma voidaan korjata opettamalla ohjelmoijat vähemmän vastahakoisiksi kirjoittajiksi. Heidät voi lähettää kirjoittamisen intensiivikurssille. Toinen vaihtoehto on palkata fiksuja tuotepäälliköitä, jotka kirjoittavat vaatimusmäärittelyn. Kummin päin vain, periaatena tulisi aina olla "ei riviäkään koodia ilman speksiä".

Opi kaikki vaatimusmäärittelyjen kirjoittamisesta lukemalla neljäosainen juttuni. 

8. Onko ohjelmoijien työympäristö hiljainen?
On laajasti dokumentoitu, että tietotyöläisten tuottavuus nousee, jos heille annetaan tilaa, hiljaisuutta ja rauhaa. Ohjelmistojohtamisen klassikko Peopleware kertoo laajasti tästä tuottavuuden kasvusta.

Ongelma on tämä: Me kaikki tiedämme, että tietotyöläinen työskentelee parhaiten pääsemällä "vuohon", toiselta nimeltään "vyöhyke", jossa he ovat täysin keskittyneitä työhönsä ja pihalla ympäristöstään. He menettävät ajantajun ja tuottavat hienoja asioita keskittymällä täydellisesti. Tässä tilassa tehdään kaikki tuottava työ. Kirjoittajat, ohjelmoijat, tiedemiehet ja jopa koripallon pelaajat voivat kertoa sinulle, että he ovat olleet vyöhykkeellä.

Ongelma on se, että "vyöhykkeelle" pääsy ei ole helppoa. Kun sitä yritetään mitata, näyttää siltä, että kestää noin 15 minuuttia ennen kuin työskentely maksimitehokkuudella alkaa. Joskus, jos olet väsynyt tai olet jo tehnyt paljon luovaa työtä samana päivänä, et millään pysty pääsemään vyöhykkeelle ja vietät loput päivästä vain näpertelemällä, lukemalla weppisivuja ja pelaamalla Tetristä.

Toinen pulma on, että vyöhykkeeltä on niin helppo pudota pois. Melu, puhelu, lounaalle lähtö, 5 minuutin matka kahvia hakemaan ja työtovereiden aiheuttamat keskeytykset -- erityisesti työtovereiden aiheuttamat keskeytykset -- ne kaikki pudottavat pois vyöhykkeeltä. Jos työtoveri kysyy sinulta kysymyksen ja aiheuttaa 1 minuutin keskeytyksen ja tämä pudottaa sinut niin pahasti pois vyöhykkeeltä, että tuottavaan työhön pääsemiseen menee puoli tuntia, koko päivän tuottavuutesi alkaa olla vaarassa. Jos teet töitä ympäristössä, joka on kuin meluisa leikkikehä, eli juuri sellaisessa, joita kofeiininkyllästämät nettiyritykset rakentavat, jossa myyntimiehet huutavat puhelimeen ohjelmoijien vieressä, tuottavuutesi laskee koska tietotyöläisten ajatus keskeytyy kerran toisensa jälkeen ja he eivät koskaan pääse vyöhykkeelle. 

Ohjelmoijille tämä on erityisen hankalaa. Tuottavuus riippuu kyvystä pitää paljon pieniä yksityiskohtia lyhyen aikavälin muistissa. Yksikin keskeytys voi saada kaiken pyyhkiytymään. Kun pääset jatkamaan työtä, et muista mitään niistä yksityiskohdista (kuten käyttäämsi paikallisten muuttujien nimet tai missä kohtaa olitkaan sen hakualgoritmin toteutuksessa) ja sinun pitää etsiä ja lukea kaikki uudelleen, mikä taas hidastaa menoa kunnes lopulta pääset taas täyteen vauhtiin.

Tässäpä yksinkertainen laskutoimitus: Oletetaan (kuten todistusaineisto näyttää vihjaavan), että jos keskeytämme ohjelmoijan, vaikkapa vain yhdeksi minuutiksi, olemme oikeasti heittäneet taivaan tuuliin 15 minuuttia tuottavaa työaikaa. Esimerkiksi, pannaan kaksi ohjelmoijaa, Jeff ja Mutt, viereisiin työpisteisiin standardinmukaisessa Dilbert-avokonttorissa. Mutt ei juuri nyt muista strcpy-funktion Unicode-version nimeä. Hän voisi etsiä sen, mikä kestää 30 sekuntia tai hän voi kysyä Jeffiltä, mikä kestää 15 sekuntia. Koska hän istuu Jeffin vieressä, hän kysyy Jeffiltä. Jeffin ajatus katkeaa ja häneltä menee 15 minuuttia tuottavaa työaikaa (jotta Mutt säästi 15 sekuntia).

Siirretäänpä heidät nyt omiin huoneisiinsa, joissa on oikeat seinät ja ovet. Nyt kun Mutt ei muista sen funktion nimeä, hän voisi etsiä sen, mikä kestää edelleen 30 sekuntia tai hän voi kysyä Jeffiltä, mikä kestää nyt 45 sekuntia ja sitä varten pitää nousta ylös (ei niin helppoa keskimääräisen ohjelmoijan lihaskunnolla!). Hän siis etsii sen. Nyt Mutt menettää 30 sekuntia tuottavaa työaikaa, mutta säästimme sitä 15 minuuttia Jeffille. Ahhh!

9. Käytättekö parhaita työkaluja mitä rahalla saa?
Koodin kirjoittaminen käännettävällä kielellä on yksi viimeisiä asioita joita ei pysty tekemään silmänräpäyksessä tavallisella kotikoneella. Jos käännösprosessi kestää kauemmin kuin muutaman sekunnin, nopeimman ja hienoimman koneen hankkiminen säästää aikaa. Jos käännös kestää edes 15 sekuntia, ohjemoija kyllästyy ja rupeaa lukemaan The Onionia, mikä nappaa heidän mielenkiintonsa ja äkkiä monta tuntia on heitetty hukkaan. 

Käyttöliittymäkoodin kehittäminen vain yhdellä monitorilla on kivuliasta, jollei jopa mahdotonta. Jos olet käyttöliittymäkoodaaja, kahden monitorin käyttäminen tekee asioista paljon helpompia.

Useimpien ohjelmoijien täytyy joskus muokata bittikarttoja ikoneihin ja toimintopalkkeihin ja eikä useimmilla ole hyvää bittikarttaeditoria. Bittikarttojen muokkaaminen Microsoft Paint:llä on vitsi, mutta silti useimpien on pakko sitä käyttää.

Viimeisessä työpaikassani ylläpitäjä lähetteli minulle automaattisia sähköposteja, joissa valitettiin, että minä käytin -- ajatelkaas -- 220 megatavua levytilaa tiedostopalvelimella. Huomautin hänelle, että ottaen huomioon levytilan hinnan näinä päivinä, käyttämäni levytila maksaa paljon vähemmän kuin käyttämäni vessapaperi. Jos käyttäisin edes 10 minuuttia hakemistoni siivoamiseen, olisi se mahtavaa tuottavuuteni hukkaamista.

Huipputiimit eivät kiusaa ohjelmoijiaan. Alitehoisten työkalujen käyttämisen aiheuttamat pienetkin harmit kasaantuvat, tehden ohjelmoijista kärttyisiä ja onnettomia. Kärttyinen ohjelmoija ei ole tuottelias ohjelmoija.

Kaiken lisäksi... ohjelmoijat ovat helposti lahjottavissa uusimmilla ja viileimmillä vehkeillä. Tämä on itse asiassa paljon halvempi konsti houkutella heidät töihin kuin kilpailukykyisen palkan maksaminen!

10. Onko teillä testaajia?
Jos tiimillänne ei ole erikoistuneita testaajia, siis ainakin yksi jokaista kahta, kolmea ohjelmoijaa kohti, te joko julkaisette viallisia tuotteita tai hukkaatte rahaa teettämällä sellaista työtä 100$/tunti maksavalla ohjelmoijalla, jonka voisi yhtä hyvin tehdä 30$/tunti maksava testaaja. Testaajien palkkaamatta jättäminen on niin ilmiselvää väärässä paikassa säästämistä, että en kerta kaikkiaan pysty ymmärtämään ihmisiä, jotka eivät tajua sitä.

Lue Viisi parasta (väärää) syytä siihen ettei sinulla ole testaajia, kirjoittamani artikkeli tästä aiheesta. 

11. Joutuvatko työnhakijat kirjoittamaan koodia haastattelussa?
Palkkaisitko taikurin pyytämättä häntä näyttämään muutamia taikatemppuja? Et tietenkään.

Palkkaisitko pitopalvelun hoitamaan häidesi tarjoilun maistamatta heidän ruokiaan? Tuskin. (Ellei kyseessä ole Marjatta-täti, koska hän vihaisi sinua ikuisesti jos et antaisi hänen tehdä sitä hänen "kuuluisaa" jauhemaksakakkuaan).

Silti, joka päivä, ohjelmoijia palkataan pelkästään hienon näköisen ansioluettelon perusteella tai koska haastattelijan mielestä oli mukava jutustella hakijan kanssa. Tai sitten heiltä kysytään yhdentekeviä kysymyksiä ("mikä ero on CreateDialog()- ja DialogBox()-kutsuilla?"), joihin pystyy vastaamaan lukemalla manuaalia. Ei sillä ole väliä ovatko he opetelleet ulkoa tuhansia ohjelmoinnin pikkujuttuja. Väliä on vain sillä pystyvätkö he koodaamaan. Tai vieläkin pahempaa, heiltä kysytään "AHA!"-kysymyksiä, niitä sellaisia, jotka tuntuvat helpoilta kun tiedät vastauksen, mutta ovat mahdottomia vastata muuten.

Olkaa niin kiltit, lopettakaa sen tekeminen. Tehkää haastatteluissa mitä hyvänsä, mutta laittakaa hakija koodaamaan. (Lisää neuvoja löydät lukemalla Sissioppaani työhaastatteluja varten.) 

12. Teettekö käytäväkäytettävyystestausta?
Käytäväkäytettävyystesti on sitä kun napataan ensimmäinen vastaantulija käytävältä ja pakotetaan hänet kokeilemaan juuri kirjoittamaasi koodia. Jos teet tämän viidelle ihmisele, löydät 95% kaikista koodisi käytettävyysongelmista.

Hyvä käyttöliittymäsuunnittelu ei ole niin vaikeaa kuin luulet ja se on elintärkeää jos haluat asiakkaiden rakastavan ja ostavan tuotettasi. Voit lukea ilmaisen online-kirjani käyttöliittymäsuunnittelusta, lyhyt oppimäärä ohjelmoijille.

Kaikkein tärkeintä käyttöliittymissä on, että jos näytät ohjelmasi kouralliselle ihmisiä (viisi tai kuusi todellakin riittää) löydät nopeasti kaikki käyttäjien pahimmat ongelmat. Lue Jakob Nielsenin artikkeli, joka selittää miksi. Vaikka taitosi käyttöliittymäsuunnittelun alalla olisivat kuinka huonot tahansa, sinulla ei ole mitään hätää niin kauan kuin pakotat itsesi tekemään käytäväkäytettävyystestejä. Ne eivät edes maksa mitään. 

Neljä tapaa käyttää Joelin Testiä

1. Pisteytä oma ohjelmisto-organisaatiosi ja kerro tulos minulle, jotta pääsen juoruamaan.
2. Jos olet ohjelmointitiimin manageri, käytä tätä listana, jonka avulla voit tarkistaa, että tiimisi työskentelee niin hyvin kuin mahdollista. Kun rupeat saamaan 12 pistettä, voit jättää ohjelmoijasi rauhaan ja keskittyä täyspäiväisesti estämään bisnesihmisiä häiritsemästä heitä. 
3. Jos olet miettimässä, ottaisitko ohjelmointipestin vastaan, kysy työnantajaehdokkaaltasi kuinka hyvin he pärjäävät tässä testissä. Jos testi antaa liian pienet pisteet, varmista, että sinulla on riittävästi valtaa korjata asioita. Muuten tunnet itsesi turhautuneeksi ja tuottamattomaksi.
4. Jos taas olet sijoittaja tutkimassa ohjelmointitiimin taitoja tai jos ohjelmistoyrityksesi harkitsee fuusiota toisen kanssa, näitä testejä voi käyttää nopeina nyrkkisääntöinä.