Targo tarkvara

Majandusteadusliku definitsiooni järgi on rahal kolm peamist rolli:

• Vahetusvahend (et me ei peaks oma tarkvara otse ülikondade ja pirukate vastu vahetama)
• Arveldusühik ehk väärtuse mõõt (et me saaks aimu, mitu pirukat meie tarkvara väärt on)
• Akumulatsioonivahend (pirukaid ja Windows Vista karpe teatavasti tagavaraks ei kogu)

Igapäevasuhtlemises on rahal aga tihti kehv aura, raha seostatakse peamiselt asjade, kulutamise ning tarbijalikkusega.

Ma ise olen eluaeg vilets tarbija olnud, aga raha meeldib mulle sellegipoolest. Täpsemalt meeldib mulle idee raha teenimisest kui väärtuse loomisest.

Konkreetselt tarkvara kontekstis: vaba vs kommertstarkvara on väga poleemiline teema, mille üle vaieldakse hääli kähedaks ja kulutatakse klaviatuure auklikuks. On inimesi, kelle arvates tarkvara eest raha küsimine on võrreldav kutsikate piinamise ja muude koledustega. On inimesi, kes teevad tarkvara lihtsalt sellepärast, et neile meeldib tehnoloogia ja asjade kallal nikerdamine. Kas sellest tarkvarast ka kellelegi kasu on, pole nende jaoks nii väga oluline, nad saavad oma rahulduse lihtsalt asjaga tegelemisest.

Samas, kui ma teen valmis mingi tarkvaratüki ja selle eest raha saan, tähendab see, et ma olen maailmale lisanud konkreetselt selle rahahulga eest lisaväärtust, sest kellegi arvates oli tegemist piisavalt hea asjaga, et selle eest maksta. Mida rohkem makstakse, seda suurem on kliendi silmis minu tarkvara väärtus ja seda rohkem olen ma asjaga rahul.

Seega, mõtteviisis, mille järgi me tahame oma tarkvara eest võimalikult palju raha saada, pole midagi halba ega koledat, sest see sunnib meid pidevalt mõtlema, kuidas oma tarkvara kasutaja jaoks võimalikult väärtuslikuks teha. Ainult tehnoloogilisele aspektile keskendumine tekitab situatsiooni, kus programmeerija meelest on tegemist millegi ülivingega, aga kasutaja kehitab sellegipoolest õlgu, sest konkreetselt tema mugavuse peale pole keegi mõelnud.

Tarkvarafirma Joostes Marss ostis hiljuti AS HüperKonsultantidelt uue HüperGeneraatori(tm) versiooni. HüperGeneraator on kirjade järgi vahend, mis kirjutab programmeerija eest 97,4% koodist ise valmis, joonistad ainult diagrammi ette, vajutad nuppu ja voilà, rakendus ongi olemas.

Järgmises projektis otsustatigi HüperGeneraator täie hooga tegevusse rakendada. Nagu ikka, tehti pärast esialgset analüüsi valmis projekti graafik. Programmeerijad Priit ja Peeter vaatasid eeldatava mahu üle, lugesid vormid-päringud-moodulid kokku ja leidsid, et kuus kuud tööd tuleb kindlasti ära. Projektijuht Joosep polnud nõus: aga HüperKonsultantide demost oli ju näha, et need vormid, mis varem võtsid päeva, võtavad nüüd ainult pool tundi! Üle kahe kuu ei tohiks kindlasti minna! Priit ja Peeter ei osanud ka suurt midagi vastu kosta, Joosepil on uhkem ametinimetus, eks tema teab paremini.

Tippjuht Tõnis vaatas graafiku üle, imestas küll, et kas tõesti saab nii ruttu, aga eeldas, et küllap projektiga lähemalt seotud inimesed teavad paremini. Samamoodi imestas klient Kustav, aga lõpuks löödi siiski käed.

Tegelikkuses selgus muidugi näiteks, et

• HüperGeneraator genereerib koodi ainult positiivse stsenaariumi jaoks, igasuguste vigade käsitlemine tuleb hiljem juurde pookida.
• Vormide asetusest on HüperGeneraatoril küllaltki fikseeritud arusaam ja kui Kustav leidis, et tema töötajad kõiki vajalikke andmeid korraga ei näe, tuli need ringi teha.
• Sama päringute kohta.
• Kui midagi oli juba valmis genereeritud ja sinna seejärel muudatusi tehtud, aga äkitselt oli vaja andmemudelit kohendada, siis uuesti genereerimine hävitas muidugi olemasolevad muutused.
• jne. jne.

Asi lõppes muidugi sellega, et Priit ja Peeter tegid kõvasti ületunde, Joosep kutsuti mitu korda Tõnise juurde vaibale, Kustav sai omakorda ministeeriumi ülemuste käest pähe jne.

Küsimus, kas koodi genereerimine on üldse mõistlik idee, on eraldi teema (sellest millalgi tulevikus), aga praegu on huvitav tähele panna, millistele eeldustele kõik osalised oma tegevuse rajasid. Igas olukorras jaguneb otsuste alusmaterjal kaheks: info, mis tegelikult teada on, ja asjad, mida me eeldame. Olukorras, kus on tegemist millegi tundmatuga (olgu see siis tehnoloogia, teostaja, partner või klient), on teadaolev info suures vähemuses, jäämäe veealuse osa moodustavad eeldused.

Antud juhul:

• Kõik osalised eeldasid, et HüperGeneraator on antud projekt jaoks sobiv vahend.
• Priit ja Peeter eeldasid, et Joosepil on eelnev kogemus taoliste vahenditega.
• Joosep eeldas, et kui programmeerijad juba uue ajagraafikuga nõus on, siis saavad nad sellega ka kindlasti hakkama.
• Tõnis eeldas, et projektirühm on kava korralikult läbi mõelnud.
• Kustav eeldas, et Joostes Marsil on tekkinud uued võimalused projekte senisest kiiremini täide viia.

Üks eeldus viis teiseni ja kui projekt lõpuks kümne kuu pärast (sest liiga agressiivselt planeeritud projektid võtavad vahepealse ümbertegemise tõttu veel rohkem aega) valmis sai, ei jõudnud keegi ära imestada, kuidas asjad küll nii hulluks said minna.

Joostes Marss pole teab mis hiigelfirma, aga isegi seal oli halbadel eeldustel katastroofiline tagajärg. Suurtes, paljude inimestega organisatsioonides on eeldustel kriitiline roll. Töötan praegu Microsofti Office’i divisjonis, mis koosneb kümnetest väiksematest produktidest, igaühel omakorda kümned arendajad. Kõik need produktid on omavahel tihedalt integreeritud, kui näiteks SharePoint lisab uue andmetüübi, peavad inimesed Outlooki, InfoPathi, Accessi, ECMi, Searchi ja mitmetes teistes gruppides, mis SharePointist andmeid oskavad lugeda, mõtlema, kuidas seda kõige paremini toetada. Muidugi katsutakse sama ülesande mitmekordset lahendamist vältida, aga see põhjustab enamasti situatsiooni, kus mitmed tiimid ootavad kellegi järel, et need selle ühise lahenduse valmis teeksid, teised tiimid ootavad jällegi esimeste järel jne. Sellises ahelas on rohkesti võimalusi halbadel eeldustel põhinevate otsuste tegemiseks, olgu siis tegemist tehnoloogia, ajagraafiku, inimeste võimekuse või millegi muu valesti hindamisega. Sellepärast tuleb ka panna suurt rõhku uurimisele, mis meie edu jaoks kriitilistes lõikudes tegelikult toimub ja kuidas asjad töötavad. Olulisel kohal on siinkohal näiteks täpsusküsimise ja täpsusvastamise rakendamine.

Eeldused võib jagada mitmesse kategooriasse, millest igaühe kohta saab enamasti küsida häid, täpseid küsimusi. Vaatleme näiteks HüperKonsultantide reklaamlauset:

HüperGeneraator 5.0 on parim projektide läbiviimiseks! HüperGeneraator suurendab teie koodikirjutamiskiirust sada korda!!!

Juba ainuüksi seda lauset lugedes, ilma tehnilistesse detailidesse süüvimata, peaksime mõtlema järgmistele eeldustele, mis selles reklaamis peituvad:

1. Väärtuse eeldus: koodi kiiresti valmimine on hea. Küsimus: kas koodi kiire valmimine on meie projekti juures tegelikult kõige olulisem?

2. Mõõtmise eeldus: koodi hulka ja valmimiskiirust on võimalik mingi ühe mõõdupuu järgi mõõta. Küsimus: kas me saame koodi kirjutamise kiirust mõõta? Kuidas?

3. Võimalikkuse eeldus: koodi genereerimine on alati võimalik. Küsimus: kas koodi genereerimine on alati võimalik?

4. Sihtgrupi eeldus: HüperGeneraator suurendab konkreetselt meie koodikirjutamiskiirust. Küsimus: kas meie oleme toote õigeks sihtgrupiks? Või on tegemist raamatupidajatele, kes tegelikult programmeerida ei oska, mõeldud abivahendiga?

5. Eksistentsi eeldus: meie probleemiks on, et kood ei saa piisavalt kiiresti valmis. Küsimus: kas koodi kirjutamise kiirus on probleemiks? Või võtab mõni muu tegevus hoopis rohkem aega?

6. Kategooria eeldus: Kõik projektid on sarnased ja HüperGeneraatoriga lahendatavad. Küsimus: kas erinevad projektid on võrreldavad? 

7. Samalaadsuse eeldus: meie projektid on samasugused kui teised. Küsimus: kas meie projekt on samasugune kui teised HüperGeneraatoriga lahendatud projektid?

8. Unikaalsuse eeldus: HüperGeneraator on parim vahend koodivalmimiskiiruse suurendamiseks. Küsimus: kas HüperGeneraator on ainus vahend, mida me kasutada saaksime?

9. Ajalise kestvuse eeldus: ka meie tulevased projektid on HüperGeneraatori abil lahendatavad. Küsimus (juhul kui praegune projekt on tõesti HüperGeneraatori jaoks sobilik):  aga meie järgmine ja ülejärgmine projekt?

Sarnaseid eeldusi võib leida igasugustest situatsioonidest. Tulevad näiteks misjonärid ukse taha ja küsivad: “Kas te usute, et Jumal soovib teile head ja armastab teid kogu südamest?”. Selle kohta võiks kohe mitukümmend eeldust leida, aga jäägu see heale lugejale mõtlemiseks

Kui ehitajad ehitaksid maju samamoodi nagu programeerijad kirjutavad programme, siis esimene rähn hävitaks tsivilisatsiooni. – Murphy seaduste kogust

Leidsin riiulist mingi ehitusinseneridele mõeldud tehnilise taskuraamatu (pole aimugi, kuidas see sinna sai). Muuhulgas on seal palju tabeleid mitmesuguste materjalide omaduste kohta: tellised, teras, vineer, tihedus, kõvadus, tugevus. Arusaadav, et iga korralik insener peab omama ülevaadet, milliste materjalidega ta töötab, mis on nende tugevuspiirid ja muud tehnilised omadused. Seda enam on hämmastav, kui vähesed programmeerijad teavad, millest nad tegelikult oma programme kokku panevad. Rakendusprogrammeerija ei tea, mis toimub klassiteekide sees, mida ta kasutab. Teekide kirjutaja ei tea, mis toimub operatsioonisüsteemis. Süsteemprogrammeerija ei tea, mis toimub riistvaras. Kõige selle juures on imekspandav, et tarkvara üldse vahel töötab ja midagi mõistlikku teeb.

Kiire test: Kui sa oled C# programmeerija, siis kas sa tead, kui suur on mscorlib.dll? Kasutad XMLi? Kui suur on System.Xml.dll? (Java, C++ jne spetsialistid võivad mõelda oma põhiliste klassiteekide ja runtime’ide peale). Ei tea? Tegemist on umbes samasuguse probleemiga, kui ehitaja ei tea, kui palju kaalub tellis, sest iga kord kui keegi vastava rakenduse käima paneb, mõjutab laetud teekide hulk rakenduse mälutarvet ja sellega otseselt programmi jõudlust. Analoogiliselt, kui sa kasutad näiteks mingit stringitöötlusteeki, on hea teada, mis on nende operatsioonide tegelik ajaline keerukus, kui pilditöötlemisteeki, siis millised on selle sisemised andmestruktuurid, et saaks hinnata mäluvajadust jne.

Objekt-orienteeritud programmeerimine on väga hea asi, aga ebasoovitava kõrvalefektina on see veelgi süvendanud olukorda, kus inimesed:

1. ei tea, mis klassiteegi sees toimub, sest kõik on ilusasti ära peidetud, pakendatud ja kapseldatud
2. ei oska ilma spetsiaalse teegita ise üldse ühtki probleemi lahendada

Kord saadeti mind asja uurima suure, tähtsa ja rikka kliendi juurde, kes kurtis, et tema veebiserver ei skaleeru. Lasin nende avalehe profileerijast läbi ja leidsin tuhandeid String.Concat väljakutseid. Selgus, et nad panevad suure hulga oma HTMList lihtsalt stringiliitmise teel kokku, mis on C# kasutades muidugi rumal. Tegemist on tüüpilise näitega, kus programmeerija ei tea, kuidas tema vahendid tegelikult töötavad.

Osaks minu tööülesannetest on aeg-ajalt potentsiaalsete töösoovijatega vestlemine (veel enne tegelikku intervjuud/katseid). Küsin sealhulgas nende käest lihtsaid tehnilisi küsimusi, et leida, kas on üldse mõtet edasi vestelda või on tegu mõlemapoolse ajaraiskamisega. Tuleb siis selline tegelane, küsin tema käest, et kui tal on programmis näiteks massiiv punaseid palle ja rohelisi palle, kuidas oleks kõige parem neid sorteerida, nii et punased pallid satuvad algusesse ja rohelised lõppu. Tema selle peale, et teeks ArrayListi ja kasutaks siis selle Sort meetodit. Kas ta teab, kuidas Sort meetod töötab? Ei. Aga kui ta peaks ise sellise meetodi kirjutama? Vaikus. Bzzzzzt, järgmine, palun. Esiteks pole klassiteekides leiduvad üldotstarbelised sorteerimisalgoritmid antud ülesande puhul sugugi optimaalsed, teiseks pole mul midagi peale hakata inimesega, kes arvutiteaduse põhikontseptsioonidega hätta jääb (nagu ehitusinsener, kes füüsikaeksamil põrub). Aja- ning mäluvajaduse keerukusest ei jõudnud muidugi rääkima hakatagi.

Uuri allikteksti, sula ühte koodiga – Linus Torvalds

Inimesed küsivad mult vahel nõu programmeerimisõpikute kohta. Häid õpikuid on palju, aga minu meelest on hea programmeerija parimaks lektüüriks hea kood Mitmesuguste andekate inimestega koos töötamise järel olen oma Microsofti-kogemuse juures rõõmus võimaluse üle igasugust huvitavat koodi lugeda, Windows, Office, .Net Framework, kõigis neis on geniaalseid lahendusi, rääkimata asjade mõistmisest tulenevast rahuldusest ja teadmistest, mis võimaldavad mul oma tööd efektiivsemalt teha (ma ei räägi siin mingitest sala-APIdest, vaid lihtsalt algoritmide tasemel mõistmisest). Väljaspool Microsofti on loomulikult samuti tuhandeid võimalusi uurida, kuidas asjad töötavad, olgu siis Open/Shared Source’i maailmas või mujal, ja suureks vaheks hea programmeerija ning tipp-programmeerija vahel on tihti see, kui palju ta igasuguste vidinate uurimisele on aega kulutanud. Kui alliktekstid pole saadaval, uuri jõudluskarakteristikuid, profileeri klassiteeke jne, et aru saada, kuidas asjad töötavad.

Ja hoidu rähnide eest

We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” – Larry Wall

Klassikalised kristlikud voorused on: mõistlikkus, mõõdukus, meelekindlus, õiglus, usk, lootus ja armastus. Samas, nii palju kui ma ka ei püüaks klassikalist vooruslikku elu elada, on vähemalt minu naise arvates mind märgatavalt paremini varustatud laiskuse, kannatamatuse ja edevusega. Kuna aga vähemalt professionaalses elus on viimased kolm mind kõvasti rohkem edasi aidanud kui esimesed seitse, siis tuleb ilmselt olukorrast võtta, mis võtta annab Siin ei tule asja muidugi nii mõista, et me neid kolme omadust kogu aeg ja igas situatsioonis peaksime kasutama, küll aga on nad meile suureks abiks oma igapäevase koodi kirjutamisel.

Esimene voorus: laiskus

Tarkvarafirmal Joostes Marss tuleb teha Hulkuvate Kasside Riiklikule Inspektsioonile statistiliste aruannete moodul, toomaks eraldi välja, kui palju erinevate ajaperioodide lõikes koeri ja kasse kaotatakse ja leitakse. Jagatakse siis ära: pooled aruanded Priidule ja pooled Pärtlile. Priit hakkab asjaga kohe hoolega pihta, kirjutab ühe lehekülje keerulist andmebaasikoodi teise järel. Ajaperioodide arvestamisel on teatavasti palju erijuhtumeid, teha päringut näiteks juuni viimasest pühapäevast 5. septembrini pole triviaalne ja Priidu kood koosneb lõpuks suurest hulgast if-then-else klauslitest, igaühe sees omakorda keeruline arvutus. Priit muudkui kirjutab, möödub päev ja teine, projektijuht Joosep küsib, kuidas läheb, Priit näitab suurt hulka koodi ja seletab pikalt, kui keerulise ülesandega ikka tegemist on, ja kuidas tal veel kolm korda nii palju koodi tuleb kirjutada, enne kui asi valmis. Kuna koodihulgast on ilmselgelt näha, et asjad edenevad, siis Joosep rahuneb natuke.

Pärtel ei tee samal ajal pealtnäha suurt midagi, nokitseb asja kallal, sirgeldab ühtteist paberile, lõpuks teeb siiski kompilaatori ka lahti. Joosep on mures ja küsib Pärtli käest, et näe, Priidul juba nii palju koodi valmis, mida sina teed? Pärtel vastu, et pole hullu, küll saab. Ja teatab õhtul, et temal on kõik valmis. Joosep ei usu, sest koodi pole pealtnäha nagu ollagi, aga näeb siis, et tõepoolest, kõik töötab, kiiresti ja korralikult. Pärtel ei viitsinud palju koodi kirjutada ja tekitas lihtsalt denormaliseeritud vahetabeli, kuhu enne aruannete koostamist andmed kopeeritakse, ja mille pealt päringute tegemine on selge, lihtne ja lühike.

Tegelikult on laiskus arvutitega lahutamatult seotud. Kuna arvuti on loodud selleks, et inimese eest töö ära teha, poleks virk inimene kunagi sellise leiutise peale tulnud. Hea programmeerija püüab teha kõik, et omaenda vaeva võimalikult vähendada. Las arvuti töötab, tema on rauast. Ma ise pean konkreetset kooditoksimist küllaltki tüütuks ega viitsi sellega palju vaeva näha, selle asemel püüan nuputada, kuidas võimalikult vähese arvu ridadega hakkama saada või üleüldse mõnd olemasolevat komponenti kohandada. Selline nuputamine on palju huvitavam ja inimesele kohasem ning rahuldust pakkuvam tegevus, rääkimata sellest, et tähtajad saavad kiiremini valmis ja ka tulemus on enamasti kvaliteetsem (vigade hulk kipub kasvama koos koodi hulgaga).

Laiskus soodustab veel mitmeid häid harjumusi nagu

• korduvate tegevuste jaoks spetsiaalsete utiliitide kirjutamine
• koodi hoolikam testimine ja debugimine (sest tarkvara põhiteoreemi järgi kulub meil testimata ja debugimata koodi peale rohkem aega)
• selge ja lihtsa koodi kirjutamine, selle kommenteerimine ja dokumenteerimine (et hoida kokku aega, mis muidu kuluks teiste inimeste aitamisele ja rumalatele küsimustele vastamisele)
• taaskasutatavusele optimiseerimine, et me ei peaks sama koodi mitu korda kirjutama
• jne

Teine voorus: kannatamatus

Ma arvan, et inimeste kannatamatus on asjaolu, mis on otseselt põhjustanud Moore’i seaduse ja palju muud lahedat.

Kannatamatusega saab mõõta näiteks selliseid asju:

• Mitu korda ma pean sama koodi uuesti kirjutama, enne kui ma selle jaoks uuestikasutatava mooduli teen?
• Mitu korda ma viitsin oma programmi testides samu liigutusi teha kuni ma sagedasemate operatsioonide jaoks lühema ja intuitiivsema meetodi välja mõtlen?
• Kui kaua ma jaksan mingi olemasoleva tarkvara järel oodata enne kui ma parema ja kiirema lahenduse välja mõtlen ja sellega palju raha teenin?
• Kui kaua ma mõne inimese või teenuse järel ootan, enne kui ma asja ise kiiremini ja efektiivsemalt ära teen või veel parem, automaatse lahenduse leiutan?
• Kas ma kannatan olukorda, kus inimesed minu tiimis kirjutavad tuhat rida koodi, kui hakkama saaks ka viiesajaga? Või korraldan ma neile koolituse, et nad parematest metoodikatest aimu saaksid?

Kolmas voorus: edevus

Kui Pärtel oli oma aruanded ennetähtaegselt valmis saanud, ei jäänud ta siiski rahule sellega, et juba enne olemas olnud, valmis koodis käisid paljud aruanded liiga aeglaselt. Päringud olid kirjutatud täpselt kliendi tellimuse kohaselt, imiteerides protsesse, mida klient Kustavi alluvuses töötavad kontorirotid enne kas siis Exceli või ka paberi ja pliiatsi abil sooritasid. Selle tõttu kopeeriti ka andmeid liigselt ühest kohast teise, päringud käisid üle seitsmeteistkümne erineva tabeli korraga jne. Pärtel uuris veel natuke asja, kombineeris mõned tabelid kokku, lisas paar indeksit, kirjutas mõne stored procedure’id lihtsalt päringusse lahti jne. Järgmisel päeval ehmus Joosep, et kas kõik testandmed on ära kustutatud või milles asi, et aruanded järsku mitukümmend korda kiiremini toimivad. Pärtlile ei läinudki eriti korda, kas kliendi jaoks on oluline vahe, kas aruanne käib kümme sekundit või kümnendik sekundit, kuid tal oli võimalus näidata, kes on ettevõttes alfaprogrammeerija.

Hubris ei tähenda küll päris täpselt edevust, aga mulle meeldib “edevus” tähendusväljana isegi rohkem. Tegemist on jõuga, mis paneb programmeerijat seatud ärilisi eesmärke ja tehnilisi nõudeid ületama, mis sunnib neid kirjutama eriti elegantset koodi, mis vastab headele tavadele ja standarditele, kuid teeb asju siiski efektiivsel ja isikupärasel moel. Tihti ei pane lõppkasutaja selliseid töövõite otseselt tähelegi, aga edevale programmeerijale on tähtis eelkõige kolleegide imetlus. Seetõttu katsub ta kirjutada koodi, mille kohta kellegil midagi norida ei oleks, mis on tarkvara kvaliteedi seisukohalt muidugi väga hea.

Lisaks koodi efektiivsusele avaldub edevus muidugi ka muudes asjaoludes:

• Kes saab oma töölõigu esimesena valmis?
• Kelle koodis on kõige vähem vigu?
• Kelle tehtud kasutajaliides on kõige uhkem?

Kui edevat programmeerijat selliste asjade eest piisavalt tunnustada, kasvab produktiivsus mühinal, piitsa ja präänikut ei lähe üldse vajagi.

Eelmises kirjutises tuli juttu oma kasutajate mõistmise tähtsusest. Leidsin vahepeal veel rea lugusid sellest, kuidas erinevad firmad on kasutaja tundmaõppimist tõsiselt võtnud ning seeläbi huvitavaid ja innovatiivseid lahendusi tootnud.

• Ameerikas on praegu väga populaarsed James Dysoni leiutatud tsükloneraldusega tolmuimejad. Jättes kõrvale asjaolu, et tegemist on tehnilise uuendusega, mis tolmuimemist efektiivsemaks muudab, võime küsida, miks selle tolmuimeja kate just läbipaistev peab olema? Kas selleks, et näha, kui palju seal tolmu sees on? Tegelikult meeldib paljudele inimestele alateadlikult näha, kuidas praht tolmuimejas ringi käib ja seeläbi “tappa saab”. Katsugu ta veel tulla silmailu rikkuma! Inimesed ei saa sellest enamasti ise arugi, aga neile meeldib Dysoni tolmuimejaga koristamine millegipärast rohkem kui teistega.

• Kõik teavad, et tervisejooks on kasulik, aga sellegipoolest ei tule jätku enamikul inimestest püsivust sellega tegelemiseks. Kuidas asja parandada? Jooksmisest tulenev kasu on pikaajaline protsess, raja lõpus pole enamasti mingit kohest rahuldust. Kuidas aga kohe jooksjale mingi preemia anda? Nike ja Apple tulid kahe peale välja tootega, mis ühelt poolt ergutab sind jooksmise ajal ning teiselt poolt laseb enda tulemusi teiste omadega võrrelda. Ja kas saab olla suuremat rahuldust, kui näha, kuidas sa teiste inimestega võrreldes arened? Pole siis imestada, et Nike Plus on hea äri.

• Et paremini mõista vanema põlvkonna autojuhte, leiutas Nissan spetsiaalse ülikonna, mis takistab teatud liigutusi, et mõista, milline on auto ergonoomika vanemate inimeste seisukohalt. Sarnased ülikonnad on olemas ka selleks, et simuleerida näiteks rasedat naist või muid iseärasusi.  

Tarkvara seisukohalt võime siin mõelda: enamikus IT-firmades on olemas infrastruktuur ja tööriistad (alates kiirest internetiühendusest arendusvahenditeni), mis meie jaoks IT lihtsaks ja mugavaks teevad. Enamikul meie kasutajatest seda aga pole ja me peaksime iga valminud tarkvaratoodet vaatama eelkõige nende inimeste seisukohalt, kellel on väiksemad võimalused. Näiteks kas meie vormid mahuvad ka väiksema kui 21″ ekraani peale ära? Kas meie andmehulgad on edastatavad ka vähema kui 1Gbit kohtvõrgu kaudu? Kas meie rakendused jooksevad ka alla 2GB mäluga?

• Autoteema teisest äärmusest leiame näite, kuidas Honda saatis Honda Legendi disainerid ja insenerid 6 kuuks Saksamaale, et nad uuriksid, mis tunne on reaalselt autobahnil kihutada ja mida ühel autol selle jaoks vaja läheks, Jaapanis sellist võimalust polnud.
• Paljud lahendused tulevad pähe lihtsalt inimeste igapäevaelu vaadeldes. Nii on leiutatud näiteks kohvikruusihoidjaga pesumasin, väike külmkapp ühikatubade jaoks, mille pealne on lahtivolditav väikeseks lauaks jne. Minu lemmikuks on siin Whirlpool Gladiator GarageWorks ja spetsiaalne garaažikülmkapp, juba ammu ei hoita garaažis ainult autosid, vaid sellest on saanud paljude meeste elu- ja hobikeskus, mille jaoks on kohandatud terve hulk kodutehnikat.

• Kes on Aasias reisinud, teab, et suur osa sealsest jaekaubandusest toimub kaootilistel avaturgudel. Kui Kishore Biyani Indias Pantalooni supermarketite keti asutas, olid tema poed alguses samasugused nagu nende lääne ekvivalendid, korrapäraselt seatud riiulite ja sirgete vahekäikudega. Hoolimata sellest, et poed olid ilusad, puhtad ja odavad, ei tulnud inimesed sinna, sest selline kauplemisviis polnud neile omane. Ei aidanud muu, kui imiteerida traditsioonilisi turge, praegu on Pantalooni poed ebakorrapärased, kaubad vedelevad näiliselt juhuslikult, asjade üle on võimalik tingida, aga rahvast käib seal nagu murdu.

• Oluline on aga, et me annaks endale aru, kas tegemist on vaid ühe kasutaja iseärasusega või laiema suunaga. Tihti saavad suured projektid alguse kellegi kinnisideest, mis tegelikult aga kedagi ei huvita, üheks suurimaks ja kallimaks näiteks siinkohal on Iridiumi satelliidid. Algse idee kohaselt pidi olema tegemist tootega “mobiilsele ettevõttejuhile”, kes kogu aeg maailmas ringi rändab. Ärimehed ei tahtnud aga suurt, kallist ja kobakat satelliittelefoni, pärast 5 miljardi dollari kulutamist saadi poole aastaga vaid 10000 kasutajat ning Iridium läks vähem kui aasta pärast pankrotti. Praeguseks on Iridiumi võrk siiski kasutuse leidnud, aga hoopis avamerepurjetajate ja muude rändurite seas.

• Teise näite sellest, kuidas me ei saa aru, kes meie klient tegelikult on, leiame meditsiinist. Meditsiiniskännerid on tõeline tehnikaime, näidates 3D pilti kõigest, mis inimese kehas toimub. Aparatuuri tootjad rääkisid arstidega, milliseid võimalusi viimastel vaja läheks ja said pika nimekirja. Kui aga masinad valmis tehti, selgus, et nende kasutusaeg hoopis langes. Milles asi? Selgus, et päriselt ei kasuta masinaid mitte arstid, vaid laborandid, kellele arst lihtsalt ütleb, et teha seda või toda. Ja kuna uuel masinal oli liiga palju nuppe ja vidinaid, millest laborandid aru ei saanud, jäid ka uued võimalused unarusse.

See on tegelikult tarkvaramaailmas igapäevaselt toimiv efekt. Inimene, kes meilt toote tellib, ei ole tihti teps mitte seesama, kes seda lõpuks kasutama hakkab!

• Kui Apple oma esimese sülearvuti lõi, oli firmal juba tugev kogemus lauaarvutitega, ja juba tollal pandi Apple’is suurt rõhku disaini perfektsusele. Mac Portable oligi perfektne… lauaarvuti seisukohalt. Tüüpiliseks näiteks on, et Portable’i aku pidas vastu üle 10 tunni (!), mis tegi arvuti palju suuremaks ja raskemaks kui konkureerivad tooted, aga näitab hästi, et tegijatel polnud täpset aimu, mis elu sülearvutikasutaja elab.

• Veel näide meditsiinitehnikast: Laparoskoopia on kirurgia haru, kus inimese sisse torgatakse fiiberoptiline kaabel ning ning kirurg vaatab ekraanilt, mis sul sees toimub. Katsetusel süsteemi testides toimis kõik hästi. Kui aga millalgi tegelikku operatsioonisaali mindi, leiti, et ruum on abistajaid täis ja kirurg peab kogu aeg üle nende küünitama, et ekraani näha. Lahenduseks oli heads-up display, spetsiaalsed prillid, millelt pilti saab vaadata, aga ilma kasutajat tema loomulikus keskkonnas jälgimata poleks tehnoloogid iial selle mõtte peale tulnud.