Targo tarkvara

Umbes kümme aastat tagasi oli mul kord kõrge palavik, mis takistas kooli või tööle minekut. Arvuti taha suutsin end siiki vedada ja kirjutasin teatava Kivirähu teksti põhjal üles Vana Programmeerija loo.

Kümne aasta juubeli puhul panin ta siia taas kirja. Nendele, kel huvi asja võõramaalastega jagada, tõlkisin selle millalgi ka inglise keelde.

Vana Programmeerija

Öösel toodi firmasse uus mees.
“Said su siis nõusse,” ütles üks programmeerija kaastundlikult. “Küllap jootsid su täis, nii nagu meid kõiki. Kes siis kaine peaga sellisesse firmasse tuleb!”
“Kas tead, kuhu kadus too mees, kelle asemele sind värvati?” küsis teine kaastöötaja. “Projektijuht lõi ta maha. Lihtsalt lõi maha ja kõik. Palju mehi on tema rusika läbi oma otsa leidnud.”
“Nii ongi õige!” ütles uus mees rahulikult. “Kus seda enne nähtud, et firmas ei tapeta! Mina olen vana häkker, olen kõik operatsioonisüsteemid ise läbi testinud ning iga kord on taplemist olnud. Vat vanasti, siis olid ikka mehed! Igaüks käis majas ringi, juhtmeots käes, ja kui sai, siis laskis voolu! Mina ainsana jäin hinge, lõpetasin edukalt projekti ja kauplesin end uude kohta. Jah, mina tunnen tarkvara tegemise kombeid!”
Ja ta ronis magamiskotti ning jäi norinal magama.
Hommikul tundis projektijuht uue mehe vastu huvi.
“Kus ta on?” küsis ta analüütikult. “Tutvustan talle meie firma tavasid.”
Analüütik läks näost punaseks ja lõi silmad maha.
“Kuidas nüüd öelda… Istub jututoas… Ma küll ütlesin, aga…”
“Mis!” röögatas projektijuht. “Laiskleb! Kas ta peab meie firmat laatsaretiks või! Tuhat nullpointerit! Näita, kus ta on!”
Programmeerija vedeles tõesti jututoas ning haigutas aeg-ajalt magusalt.
Projektijuhti nähes ta naeratas unelevalt.
“Mõtlesin just sellest ajast, mil ma veel noor olin,” ütles ta. “Siis olid mehed selgest rauast. Mina isegi olen ju teab kui mitu korda haljast assemblerist bugisid rookinud. Ükskord juhtus sihuke ette, et hoia ja keela! Kolm korda tuli ringi kompileerida. Aga ma talle andsin!”
“Mida!” käratas projektijuht. “Sa veel seletad, lurjus!”
“Nonoh!”, ütles mees pahaselt. “Hoia oma pudrumulk vaos, kui sa häkkeriga kõneled. Ega ma oma juttu lõpetanud pole. Teinekord tuli andmebaasimootorit parandada – t erve kollektiiv läks selle pärast peast segi, aga siis leidis terav kirves kivi! “Noh, roju!” ütlesin ma talle. “Nüüd ma su jahvatan!” See oli ka üks kodeerimine, mida tänaseni meenutatakse.”
Projektijuht kuulas ja läks raevust kollaseks.
“Kas sa tead, kellega sa praegu räägid!” kisendas ta. “Sa räägid projektijuhi endaga!”
“Mis projektijuht sina oled!” lõi vana programmeerija käega. “Selliseid projektijuhte on ennegi nähtud. Vaata vanasti, siis olid projektijuhid. Silmad olid teistel punnis, käisid trampides mööda koridori ja vandusid nii , et kõik masinad käigu pealt GPF-i andsid. Sinusuguseid keskkoolihäkkereid ei lastud uksest sissegi, nad tõid õnnetust kaasa. Mine parem oma tuppa ja küll mina siin asjad korda sean. Mina tunnen C++’i nagu oma pük se.”
“Nii!” pöördus ta seejärel analüütiku poole. “Mitut CASE-vahendit te kasutate?”
“Ühte,” vastas see hämmeldunult.
Vana programmeerija vangutas pead.
“Kus seda enne nähtud!” ütles ta. “CASE-vahendeid peab olema vähemalt seitse ja diagramme tuleb üle joonistada kaksteist korda päevas. Nii oli vanasti alati. Saada mehed joonistama!”
“Mulle tundub, et…” alustas jahmunud projektijuht, aga vana programmeerija käskis tal pudrumulgu kinni pidada.
Serveri kettaruumi kulutas vana programmeerija rohkem kui kõik ülejäänud kokku ja käskis finantsdirektoril seejärel uut riistvara muretsema minna.
“Nii ei jätku meie rahadest kuigi kauaks,” söandas finantsdirektor poetada.
“Firmas peabki vähe raha olema,” vastas vana programmeerija kindlalt. “Omal ajal, kui ma FreeBSD-ga tegelesin, ei saanud keegi seitse kuud sentigi palka. Mis teie siin ka üldse tarkvarategemisest teate.”
“Mis firma tarkvara kasutatakse?” uuris ta seejärel analüütikult.
“Microsofti,” vastas too.
“See tuleb kohe maha kustutada,” ütles vana häkker. “Kus seda enne nähtud, et Microsofti tarkvara kasutatakse! See toob ju sulaselget õnnetust! Kõik vanad programmeerijad teavad, et Microsoftis pesitsevad kurjad vaimud. Ru ttu tarkvara ketastelt maha! Mul on meeles üks juhtum, kus kah keegi rumal projektijuht Microsofti tarkvara arvutitesse lasi installeerida. Sealt firmast ei pääsenud peale minu keegi eluga, operatsioonisüsteemidest ronisid aga deemonid välja ja käisid öösiti magamiskottidest meeste verd imemas.”
Jubedusega kuulanud töötajad formateerisid kiiresti kõik kõvakettad üle.
“Jeesus Maria!” hüüdis vapustatud projektijuht. “Nüüd meie tähtajad hävivad! Ma lähen hulluks!”
“Tarkvaratootmisel peabki hulluks minema, siin teisiti ei saa,” nõustus vana häkker. “Meil läks omal ajal kogu kollektiiv hulluks.”
“Projektijuht ägas ja pages oma tuppa varju.
Vana programmeerija jalutas mööda ruume ning sattus viimaks süsopi manu.
“Süsteem töötab valesti,” ütles ta pärast hetkelist mõtlemist.
“Mul on siin graafiline abivahend, mis süsteemi jälgimisega tegeleb,” vastas süsop.
Vana häkker vilistas.
“See’p see on!” ütles ta. “Graafiline kasutajaliides! Kus seda enne nähtud on! Kellel oli vanasti graafiline kasutajaliides? Mitte kellelgi! Käsurida on kõik, mis häkkeril vaja läheb. Graafiline kasutajaliides on ainult eksitamiseks mõeldud.”
Ta lükkas süsopi kõrvale, kustutas X-Windowsi ning läks tööst väsinuna uuesti puhkama.
Siis anti teada peatsest voolukatkestusest. Projektijuht, kelle nägu reetis, et tema paar viimast tundi pole olnud kergete killast, väljus oma toast ja käskis tööd salvestada.
“Rumalus!” leidis vana programmeerija. “Las aga olla! Pidage kõik oma pudrumulgud kinni, küll mina juba andmetega hakkama saan!”
Siis tuligi voolukatkestus ja pooleliolevad tööd hävisid.
õhtul pidid Microsofti esindajad, kellega firma koostööd tegi, tulema projekti seisu üle vaatama.
Kuna süsop oma tööd teha ei saanud, ei saadud ka andmeid taastada ning Microsofti esindajad said kurjaks.
“Nüüd me oleme pankrotis,” oigas juhtkond.
“Firma peabki pankrotti minema,” õpetas vana programeerija, kes hetkekski rahu ei kaotanud. “Mis firma see on, mis pankrotti ei lähe?! Nii palju, kui mina olen töötanud, pole ükski firma pankrotistumata jäänud! Omal ajal…”
Aga ta ei jõudnud lõpetada, sest enne seda jõudsid kohale Microsofti juristid, kes ta seal koos teiste töötajatega kinni võtsid ja Bill Gatesi enda ette toimetasid.
Bill istus väärikalt troonil ja kohendas oma kandilisi prille.
“Midagi halba teiega siin ei juhtu,” ütles ta. “Hakkate vaid minu produktide kallal kodeerijateks nagu kõik need, kes enne teid minu valdustesse sattusid. Nüüdsest olete mu sulased!”
Tekkis hetkeline vaikus ja kohe seejärel oli kuulda vana programmeerija häält, kes Wordi patchis.
“Kus seda enne nähtud, et Word PC peal jookseb!” pahandas ta. “Wordi koht on HP peal.”
“Kas see pole mitte see vana programmeerija!” hüüatas Bill selge hirmuga. “Jälle siin!”
“Mina ikka,” vastas häkker. “No miks su prillid küll kandilised on? Need on ju alati olnud ümmargused.”
“Viige ta ruttu tagasi!” karjatas Bill. “Ruttu!”
Ning juristid viisid vana programmeerija minema.
Järgmisel päeval istus ta terminali taga ja mängis muda, kui sisse astusid kaks meest.
“Vajame kogenud programmeerijat!” hõikas üks neist.
“Siin ma olen,” vastas vana programmeerija ja läks meestega kaasa.

Mitmesuguste uuringute põhjal on leitud, et ligi pooli alustatud tarkvaraprojekte võib lugeda ebaõnnestunuks. Seega, kui lugejal on olnud tegemist mõne tarkvaraprojektiga, on suure tõenäosusega olemas ka kogemus mõne puusse läinud projektiga. Huvitav on aga jälgida, milliseid abinõusid selle puhul ette võetakse. Selgub näiteks, et inimesed on õnnetud ja rahulolematud, mida teha? Juhtkond korraldab neile kõva peo, uskudes, et selle abil saab kõik korda, aga kas see oli tegelikult asi, mida vaja?

Steve McConnell laiendab oma suurepärases raamatus “Software Project Survival Guide” Maslow hierarhia ideed tarkvaraprojektidele.

Järgneval skeemil on klassikaline Maslow hierarhia inimeste kontekstis:

Laiendades sama ideed tarkvaraprojektile saame aga sellise diagrammi:

Ja nagu inimeste puhul, pole meil mõtet tegeleda hierarhia ülemiste osadega, kui alumised on rahuldamata. Oletame, et mul on paha tuju. Sõbrad kutsuvad mind kinno, et asja parandada, aga see ei muuda midagi, kui minu probleem on tekkinud hoopis sellest, et mul on kõht tühi! Samamoodi ei aita inimestele peo korraldamine, kui probleemiks on see, et tähtajad on ebarealistlikud ning inimesed peavad kogu aeg ületunde tegema.

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.

Motivatsiooni saame jagada positiivseks (me teeme midagi, et meiega midagi head juhtuks) ja negatiivseks (teeme midagi, et halb juhtumata jääks), samuti väliseks (keegi teine tahab, et me midagi teeks) ja sisemiseks (ise tahame seda teha).

Selle põhjal saame laias laastus neli liiki motivatsioonifaktoreid: kolm neist ei tööta ja üks töötab. Sellegipoolest kasutab 95% maailma ettevõtetest enamasti mingit kombinatsiooni kolmest mittetöötavast meetodist.

Kõige olulisem tähelepanek on, et väline motiveerimine üldjuhul ei tööta, ei hea ega halvaga, vaatleme seda mõnede näidete varal:

Sõjaväes õpivad inimesed küllaltki kiiresti, et käsk on vanem kui meie ja käsule vastuhakkamisel on enamasti kurvad tagajärjed, olgu tegemist siis kuitahes rumala käsuga. Ka tsiviilelus juhib nii mõnigi organisatsioonijuht oma inimesi nagu sõdureid: “Teed sellepärast nõnda, et mina ütlen nii, muidu oled vallandatud! Ja jutul lõpp!!”

Programmeerijad, sindrinahad, arvavad aga enamasti, et nad teavad ise kõige paremini, kuidas asju teha (ja tihti teavadki), ja reageerivad seetõttu kamandamismeetodile lastes oma produktiivsuse allapoole igasugust arvestust. Teiseks eeldab kamandamismeetod arvestatavat mikromanageerimist, niipea kui piitsaplaksutataja silmapiirilt kaob, lastakse end jällegi lõdvaks ja ei tehta üldse midagi. Asi lõpeb sellega, et juht kurnab ennast ära, tehtud ei saa aga ikka midagi.

Hoiatava näite sellest, kuidas väline halvaga ähvardamine ei aita, leiame tegelikult meditsiinist. Südameoperatsioonil käinud inimesi hoiatatakse üldjuhul, et kui nad oma eluviise (olgu siis liigse söömise, joomise, suitsetamise vms osas) ei muuda, siis nad surevad varsti ära. Kui paljud inimesed aga tegelikult ennast parandavad? Selgub, et 2 aastat pärast operatsiooni on 90% patsientidest tagasi endiste harjumuste juures!

Ühesõnaga, kui isegi surmaga ähvardamine ei aita, kui inimesel puudub tegelik sisemine soov midagi muuta, kui palju lootust on siis otsesel ülemusel?

Teine viis, kuidas inimesi püütakse panna midagi tegema, on neid ühel või teisel viisil ära ostes, olgu tegemist siis raha, nänni, “kuu parima töötaja” tiitli või muude vahenditega.

Esimene probleem sellise lähenemise juures on, et tarkvaraprojekti juures on äärmiselt raske leida mingit lineaarset väärtust, mida mõõta ja seejärel rahasse ümber kantida. Kui premeerida näiteks koodiridade arvu, kirjutab programmeerija kas suure hulga kommentaare või formaadib koodi niiviisi, et see võimalikult pikk välja tuleks, või teeb otseselt sohki, lisades projektile hulga “võltskoodi”, mis tegelikult midagi ei tee.

Kui premeerida ennetähtaegset ülesannetega valmis saamist, “täidetakse” ülesanne ilma testimata ja muul viisil üle nurga lastes.

Kui premeerida vähest vigade arvu, teeb programmeerija testijaga diili, et vigu ei panda kirja ja statistikas näeb kõik ilus välja (kui me maksame testijale lisatasu selle järgi, kui palju vigu ta leiab, lähevad programmeerija ja testija tülli ning tiimitöö lendab vastu taevast).

Sõltumata sellest, millise meetodi me leiutame, on programmeerija üldjuhul piisavalt taiplik, et optimiseerida oma tulemust vastavalt sellele, mida me parajasti mõõdame, ning tulemus saab enamasti palju hullem, kui enne mõõtmisviisi sisseviimist.

Peamine viga, mis mõlemal juhul tehakse, on see, et inimese sisemine motivatsioon asendatakse välisega. Kui ma tahan kirjutada head koodi sellepärast, et mulle meeldib hea tulemus, siis ma pingutan selle nimel, et kood tuleks võimalikult hea. Kui mulle selle eest aga raha pakutakse, siis hakkan ma mõtlema, et “ma pean kirjutama head koodi, et raha saada”. Väline motivaator on aga alati nõrgem kui sisemine ning paradoksaalsel kombel on mul äkitselt hoopiski vähem soovi oma tööd võimalikult hästi teha.

Kuidas sisemist motivatsiooni kasvatada? Kui ma teaksin sellele küsimusele täpset vastust, siis juhiksin praegu mõnd Fortune 100 ettevõtet, aga arvamusi siiski:

On väga oluline, et töötaja jagaks ettevõtte identiteeti ja peaks ettevõtte eesmärke enda omadeks. Siinkohal on suureks abiks, kui ettevõttel on mingil viisil üllas või võimas visioon, millega inimestele meeldib ennast samastada. Miljonid väga andekad inimesed töötavad küllaltki väikese raha eest heategevates organisatsioonides, sest neile meeldib töötada õilsa eesmärgi nimel, isegi kui nad ise on lihtsalt raamatupidajad või itimehed, mitte ei jaga isiklikult nälgivatele lastele leiba.

Kommertsettevõttel on muidugi natuke raskem üllas olla, aga ka siin leiab hea tahtmise korral lahenduse. Microsofti missioon on aidata inimestel kogu maailmas oma tööd efektiivsemalt teha. Paljude teiste firmade missioon on Microsoft troonilt tõugata ja seeläbi “õiglus jalule seada”

Teine identiteedi aspekt on seotud töötaja kolleegidega. Kui inimesed tunnevad end kokkukuuluvatena nagu perekond, on nad vastastikku lojaalsed ja üksteisele pühendunud. Kui minu töökaaslased on mulle olulised, pole mulle vaja mingit välist motivaatorit, et nende nimel ekstra pingutada ja ühise eesmärgi nimel asjad võimalikult hästi valmis teha.

Kolmandaks on vaja, et ettevõtte kultuuris väärtustatakse siiralt head tulemust. Meile kõigile meeldib, kui meid hinnatakse ja respekteeritakse, seda siis nii ülemuste kui ka kolleegide poolt. Kui programmeerija ülemuseks on aga endine müügimees, kes C-l ja Javal vahet ei tee, jääb see vajadus aga rahuldamata ning mingil hetkel langeb paratamatult ka motivatsioon.

Üks olulisemaid asju, mille üle mul oma Microsofti-kogemuse juures hea meel on, on võimalus töötada koos väga erineva tausta ja päritoluga inimestega. Ainuüksi minu otseses alluvuses on olnud inimesi Hiinast (sh nii emamaalt, Taiwanist kui ka Hong Kongist), Indiast, Kanadast, Poolast, Slovakkiast, Türgist, USAst ja Venemaalt, lisaks kolleege kõikvõimalikest muudest kohtadest Soomest Botswanani. Konkreetselt arendajate osas on ameeriklased Microsoftis muuseas suur vähemus ja mõnes divisjonis ei moodusta isegi mitte suurimat rahvusgruppi.

Selle juures on huvitav tähele panna, kuidas kellegi kultuuriline ja majanduslik taust on inimesi vorminud. Ühelt poolt võib igas keskkonnas kohata nii geeniusi kui ka luusereid, IQ ja töökuse monopoli pole ühelgi piirkonnal, aga sellegipoolest torkavad silma mõned iseärasused.

Ameeriklased elavad tugevate kapitalistlike traditsioonidega arenenud tööstusühiskonnas, kus valitseb tugev sisemine konkurents ettevõtete ja ka indiviidide vahel. Ettevõtete seas on tihti väga tugev spetsialiseeritus, igaüks on leidnud endale konkreetse kitsa turuniši, millelt oma kasumit saada. Ameerikasse kolides üllatas mind suuresti, kui palju siin ikkagi erinevaid kaupu ja teenuseid on võimalik saada, mis on kõik selle konkurentsi ja spetsialiseerumise tagajärg. Üksikisikute tasemel paistavad silma kaks aspekti: esiteks tohutu ettevõtlikkus – peaaegu kõigil minu ameeriklastest tuttavatel on kunagi olnud oma äri, nad plaanivad seda tulevikus luua või vähemalt unistavad sellest. Teiseks aspektiks on jällegi seesama spetsialiseeritus, Ameerikas kohtab väga palju inimesi, kes on mingi konkreetse eriala äärmiselt tugevad spetsialistid, kuid nad jäävad hätta, kui on tegemist millegagi, mis otseselt nende valdkonda ei puutu. Samuti toetub ameeriklane hädas palju konkreetse spetsialisti abile, selle asemel, et asju ise korda ajada, olgu tegemist siis elektriku, politseiniku või advokaadiga.

Indialaste puhul on oluline vahe, kas me räägime tüüpilisest väljarännanud IT-spetsialistist või inimesest Bombay tänavalt. Tohutu ülerahvastatuse tõttu on Indias lääne inimese jaoks kujuteldamatu konkurents ülikoolikohtadele ja headele ametipostidele. Kraadiõppesse pääseb vaid maksimumhinnetega ja isegi kõrgelt haritud inimesel pole enamasti muud valikut, kui töötada Ameerika firma tech suppordis ja kuulata redneckide virisemist, et miks nende modem ei tööta. Kui siia lisada veel takistused, mida USA immigratsiooniteenistus seab osadest riikidest sisserändajaile, saame kokku terve hulga sõelasid, millest tüüpiline Indiast pärit itimees on pidanud läbi saama. Sellega seoses järgivad nad tihti punktuaalselt igasuguseid tobedamaid ja vähemtobedamaid reegleid (ehk täidavad vene korraldusi saksa täpsusega), kuna nende kogemuse järgi võib reegli eiramine kaasa tuua rongist maha jäämise.

Idaeurooplased on tihti vastupidise mentaliteediga. 50 aastat kommunismiaega on neile õpetanud, et reeglid on juhuslikud ning suvalised (isegi kui nad vabamas ja loogilisemas ühiskonnas seda ei ole) ja neid võib enamasti eirata. Vahel on see halb, vahel hea, olenevalt sellest, kas tulemuseks on geniaalne innovatsioon või faux pas, mille tõttu teised peavad ületunde tegema.

Hiinlaste juures on huvitaval kombel esindatud jooned kõigist ülaltoodutest: suurrahva mentaliteedist tingitud mõningane teadmatus muu maailma osas, rahvaarvust tingitud tihe konkurents ja kommunistlikust riigikorrast tulenev teatav vajadus igapäevaelus vahel mõningast osavust kasutada.
Samas on Hiina kultuurile lääne omaga võrreldes omane küllaltki tugev kollektivism. Kui Ameerikas on vanasõna, et varajane lind saab ussi kätte (early bird gets the worm), siis Hiinas on väidetavalt vanasõna, et varajane lind lastakse maha ehk siis hoopis teine suhtumine individuaalsesse initsiatiivi. Eriti Hiina filiaalidega asju ajades torkab silma, et inimesed võtavad vastu mingi otsuse ja siis kohalik ülemus räägib kõigi eest, võrreldes sellega, kuidas Euroopa või Ameerika filiaalis igaüks isiklikult esile püüab tikkuda.

Eestlastel on idaeurooplaste alamliigina veel üks eripära: väikerahvana on Eestis põhimõtteline struktuurne puudus inimestest. Ühemiljonilise rahvaarvuga riigis tuleb ära täita needsamas võtmepositsioonid (olulised riigiametid, põhiliste majandusvaldkondade juhtivate ettevõtete direktorid jne), mis sajamiljoniliseski, aga sobivad kandidaadid tuleb leida palju väiksema seltskonna seast. Kuna igalühel polegi erilist soovi suur juht ja otsustaja olla, põrkavad rahvusvaheliste firmade esindajad Eesti filiaalidega tegeledes kokku nende jaoks kummalise probleemiga, kus keegi ei tahagi eriti ülemus olla ja teeb pigem oma tavalist tööd. Oma tavalises suurkorporatsiooni keskkonnas on nad harjunud pigem olukorraga, kus igale juhtivale kohale on kohe kümme kandidaati, kuna inimestel pole muud varianti silmapaistmiseks. Eestis on aga igal soovijal küllaltki lihtsalt võimalik saada kas seltskonnaajakirja veergudele, televisiooni, parlamenti või mõne top 100 ettevõtte juhikohale, mis enamiku inimeste ambitsioonid rahulikult ära maandab – kui mujal on tegemist tõsise ambitsiooniüleküllusega, siis Eestis selle puudusega.
Samuti täidetakse Eestis sarnaseid ülesandeid tihti palju väiksema arvu inimestega, kui mujal ning igaüks peab tihti ära katma palju laiema vastutusala kui rahvarohkemas ühiskonnas tavaks. Kui Redmondis on Microsofti Office’i divisjonis terve eraldi tiim, mis tegeleb ainult build toolide ja skriptidega, siis Eestis teeb programmeerija ise kõik vajaliku muu töö kõrvalt ära. Seetõttu on eestlane itimehena tihti palju laiema profiiliga, kuid tal puudub tavaliselt sügavam eriteadmine oma valdkonnast. See tähelepanek ei kehti muidugi mitte ainult IT kohta, mulle tundub, et näiteks ameeriklasega võrreldes on eestlane ka üleüldiselt varmam avaldama amatöörlikku arvamust mõnel suvalisel poliitilisel või filosoofilisel teemal.

Mis on jutu moraal: Nagu alguses öeldud, ei mõjuta kultuurikeskkond kellegi oskust või võimet oma igapäevaseid tööülesandeid täita ja kõigist ülaltoodud statistilistest tähelepanekutest on palju erandeid. Siiski on hea, kui meeskonnas on esindatud erineva taustaga inimesed, kes lähenevad probleemile erinevalt ning suudavad näha midagi, mis teistel ehk tähele panemata jääb. See ei kehti muidugi mitte ainult rahvuse, vaid ka sotsiaalse või majandusliku päritolu, hobide, selle, kas tegemist on linna- või maainimesega jms kohta. Mida rohkemad on erinevad kogemused ja oskused meeskonnas esindatud, seda väiksem on risk ja seda tugevam lõpptulemus.

Paljud inimesed on kindlasti kuulnud Myers-Briggsi iseloomutüüpide testist, kui mitte, siis soovitan kindlasti see test läbi teha, annab väga viljakat mõtlemisainet nii iseenese mõistmise kui ka teistega suhtlemise osas. Internetis on mitmeid saite, kus saab MB testi teha. Siinkohal vaatame, millised on mõned huvitavad MB rakendused konkreetselt tarkvaratootmise situatsioonis.

MB teljed on: Introvert-Extravert, Sensing-Intuitive, Thinking-Feeling ja Judging-Perceiving. Vastavalt sellele, kuidas inimene neil telgedel paikneb, vastab tema iseloomutüübile 4-täheline lühend.
Järgneval diagrammil on toodud statistilised tulemused, kus kollasel põhjal on (protsentuaalselt) USA elanikkonna statistilised iseloomutüübid ja rohelisel põhjal 5000 kas organisatsiooniliselt või tehnoloogiliselt liidripositsioonil töötava tarkvaraspetsialisti tüübid.

  
Väga oluline on rõhutada, et ükski iseloomutüüp pole a priori teistest parem või halvem. Ühiskonnas edukate inimeste seas on kõiki tüüpe, neid tuleb lihtsalt ära tunda ja arvestada, milline käitumine neile millist mõju avaldab.Kui kedagi huvitab, siis mina olen INTJ  

Esimene telg ehk kust me oma energiat ammutame: Extravert-Introvert

 
Küsimus: Mis vahe on introvertsel ja ekstrovertsel programmeerijal?
Vastus: Introvertne programmeerija vaatab sinuga rääkides enda kinganinadele, ekstrovertne sinu omadele…

Tegelikult on muidugi ka programmeerijate seas nii tõelisi  I-sid kui ka E-sid, kõigi sellest tulenevate tagajärgedega. I/E tänavadefinitsioon on, et E räägib palju ja I on kogu aeg vait. See pole tegelikult õige, ma ise võin vajaduse korral rääkida-rääkida-rääkida, rahvale kõnesid pidada ja üleüldiselt esineda, aga tegelikult olen ma pigem introvert. 

I/E tegelik definitsioon on, et E saab oma tegutsemiseks vajaliku energia inimestega suhtlemisest, I aga omaette olemisest ja mõtisklemisest. Selle asjaolu mõistmine on väga oluline näiteks inimestele sobiva töökeskkonna loomisel.

E moto on “arutame asja”, ta on sotsiaalne, aktiivne, laiutiminev, väljendusrohke. E peab kogemuse läbi tegema, et seda mõista.
I arvab, et E on lärmakas, pealetükkiv, pealiskaudne, impulsiivne, väsitav.

I moto on “mõtleme asja läbi”, ta on vaikne, sügavutiminev, privaatne, reserveeritud. I peab kogemust enne mõistma, et seda läbi teha.
E arvab, et I on vaikne, kättesaamatu, ennastimetlev, eemalviibiv, väsitav.

Tarkvaraorganisatsioonis avaldub see eelkõige tiimide kompositsioonis ja õige keskkonna loomisel. Tüüpiliseks näiteks on igavene debatt selle üle, kas inimestel peaks olema vaikne, privaatne oma tuba või peaksid nad olema koos ühes suures ruumis, kus on võimalik igal hetkel teistega suhelda, olenevalt iseloomutüübist on mõne inimese jaoks õige variant üks, mõne jaoks teine. Vale valiku puhul juhtub lihtsalt, et töötaja on päeva lõpuks väsinud ega saa eriti midagi tehtud, kuigi kõik muud tingimused võivad olemas olla.

Minu idee on siinkohal luua asutuses “vaiksed piirkonnad”, toad, kuhu I saab vajaduse korral minna ja kriitilisel hetkel vaikselt ning segamatult oma tööd teha, ilma et ta sinna kogu aeg isoleeritud oleks. Suhtlemises on tähtis märgata, et I eelistab tihti kirjalikku väljendust, ütleb vähem, kuid väljaöeldu on see-eest rohkem läbi mõeldud, ning I võib kergemini solvuda, kui need mõtted tähelepanuta jäetakse.

Olukorras aga, kus kiiresti ja agressiivselt oma sõna sekkasaamine on oluline (nagu teatud tüüpi läbirääkimistel), omab E jällegi suurt eelist, sest selleks ajaks kui I on küsimuse oma peas läbi mõelnud, on E-d juba järgmisele teemale hüpanud. 

Teine telg ehk kust me infot saame: Sensing-iNtuition

  
 ”Sensing” tuleb siinkohal mõista selles tähenduses, mida me oma viie meelega konkreetselt tajume.

S-tüüpi inimesed hindavad eelkõige fakte, praktilisust, detaile, korrastatust ning on oma mõtetega peamiselt olevikus.
N arvab, et S on kujutlusvõimetu, pedantne, detailne, igav ja piiratud.

N mõtleb pigem tulevikule, võimalustele, tähendustele, mustritele ja muutustele.
S arvab, et N on ebapraktiline, lõdva mõtlemisega, abstraktne, ennustamatu ja distsiplineerimatu.

Programmeerimine on väga abstraktne tegevus ja programmeerijad kipuvad olema rohkem N-tüüpi. Siit saab alguse ka üks tüüpilisi konflikte programmeerijate ja klientide vahel. Tarkvarainimesed on tihti peaga pilvedes ning mõtlevad sellele, kui tehnoloogiliselt uhke, võimas, universaalne ja abstraktne nende lahendus on, samal ajal kui klient nutab, et tema konkreetset erijuhtumit arvesse ei võeta.
Universaalset ja abstraktset koodi on palju põnevam kirjutada, kui erijuhtumeid nikerdada, aga reaalne elu paraku peamiselt erijuhtumitest koosnebki. Selle asjaolu teadlik arvestamine, enese kahe jalaga maa peale surumine ning püüd maailma kliendi seisukohalt näha aitab tihti kaasa palju soojematele ja viljakamatele suhetele.  

Kolmas telg ehk kuidas me otsuseid teeme: Thinking-Feeling

T-d iseloomustavad sõnad on objektiivne, kindel, täpne, analüüsiv, ta mõtleb eelkõige sellele, kas miski on loogiline või ei ning püüdleb absoluutsele õiglusele.
F arvab, et T on objektiivne, kuid “ei saa asjale pihta”, range, tundetu ja hoolimatu.

F seevastu subjektiivne, empaatiline, hooliv, lähtub väärtustest ja harmooniast ning hindab eelkõige inimestevahelisi suhteid.
T arvab, et F on ebaloogiline, subjektiivne, pehme, irratsionaalne ja emotsionaalne.

Kuna arvutile tuleb kõik konkreetselt puust ette teha, on programmeerijad enamasti T tüüpi ja siit leiamegi järgmise konflikti. IT-mees võib tähtsat klienti külastades talle otse näkku öelda, et kliendi firmas on kõik valesti, korda pole ollagi ning keegi ei oska oma tööd õigesti teha. Enda seisukohalt käitus ta täiesti loogiliselt ning tegi kliendile teene, samamoodi nagu arvutile patchi installeerides, asjaolu, et suhe rikutud sai, ei pane ta tähelegi.  

Neljas telg ehk kuidas me asju lõpule viime: Judging-Perceiving
  

J teeb kindlaid plaane ja otsuseid, seab kõigele tähtaja, armastab organisatsiooni, struktuuri ning lõpetatust.
P arvab, et J on kontrolliv, struktuurne, planeeriv, piirav ja paindumatu.

P on pigem paindlik, uudishimulik, avatud, spontaanne ning eelistab kõik võimalused avatuks jätta.
J arvab, et P on kontrolli alt väljas, korratu, teeb asju viimasel hetkel, organiseerimatu ja ebausaldusväärne. 

Siinkohal on tarkvarainimeste seas esindatud mõlemad tüübid, aga me leiame terava vastuolu näiteks siis, kui on vaja projektigraafikut koostada või muud laadi tähtaegu seada.

J lubab kohe, et asjad on nädala lõpuks valmis, aga jätab vahel mõned asjaolud tihti arvestamata, mis lõpeb pikkade ületundidega.
P jällegi katsub konkreetse tärmini väljaütlemisest igati hoiduda, aga see ei tulene mitte laiskusest, vaid  arusaamast, et probleemi lahendamiseks on palju võimalusi ning ta soovib asja kallal lihtsalt vabas vormis nikerdada, et näha, mis välja tuleb.

Projektijuhtimise seisukohalt on oluline kummalegi anda ülesanded, mis neile sobivad: konkreetsed, ajakriitilised asjad J-le ning vabamas vormis (näiteks mõne uue tehnoloogia uurimise) P-le.

Kokkuvõtteks rõhutaks veelkord, et ükski neist tüüpidest pole parem kui teised, aga oma kolleegi, ülemuse, alluva või kliendi loomuse mõistmine aitab kindlasti kõigil oma tööd paremini teha.
Lisalugemiseks veel üks huvitav lehekülg antud teemal: http://www.sfu.ca/~smbarber/educ819.htm

Mulle meeldib Cameron Diaz. Tavaliselt on mul üsna kiire ja olen seetõttu filmide osas küllaltki valiv, vaatan enamasti ainult kõrgelt hinnatud filme, aga CD puhul teen erandi ja vaatan teisi ka. Mitte, et see asjana iseeneses kuigi märkimisväärne oleks, aga samamoodi talitavad ka miljonid teised inimesed üle maailma, mistõttu Cameronil on võimalik küsida filmi eest kuni 20 miljonit dollarit. Arvestades, et Charlie’s Angels tõi sisse sadu miljoneid, siis investeering polnud üldse paha.

Mõelgem nüüd, kui Diaze asemel oleks sama rolli mänginud, noh, näiteks Merle Palmiste. Mitte, et ma MP-d kuidagi maha tahaksin teha, aga ilmselt oleks filmi menu olnud vähemalt suurusjärgu võrra väiksem ja see on ka põhjus, miks Merle nii palju raha ei teeni.

Aga kui filmis oleks olnud näiteks 64 Merle Palmistet, kas see oleks midagi päästnud? Arvatavasti mitte. Samas püüavad mitmed tarkvaraprojektide juhid tihti just nimelt nõnda talitada. Algatatakse võimsa eelarvega suurejooneline projekt ja siis võetakse seda täide viima sada keskpärast programmeerijat. Eelmises artiklis sai juba mainitud, et vahel võib üks programmeerija teha ära sama palju tööd, kui mõnel teisel juhul sada inimest, kuid vahel ei suuda isegi sada inimest luua midagi, mis oleks võrreldav ühe geeniuse tööga.
Näitlejate puhul võib muidugi vaielda, kas nende erinev populaarsus on tegelikult õigustatud, nii et toome konkreetsemalt mõõdetava näite. Tegelen vahel pikamaajooksuga, minu maratonijooksu isiklik rekord on 3:12:11, mis on rahvasportlase kohta täitsa OK. Samas ei tuleks Etioopia koondisele ilmselt kunagi pähe ühe Haile Gebrselassie asemele viiskümmend Targot palgata. Ja niisamamoodi on tarkvara alal asju, millega saavad hakkama vaid vähesed, aga samas on tegu aspektidega, mis annavad ühele produktile võistlejate ees selle üliolulise pisikese edumaa.

Siinkohal puutume kokku ühe ülimalt olulise asjaoluga, mis eristab näiteks tarkvara ja filme paljudest muudest kaupadest. Tarkvara kopeerimise kulu on tootmisega võrreldes olematu ning kui meie staarprogrammeerija on meile selle väikese, kuid olulise eelise andnud, hakkavad inimesed kasutama paremat produkti ja võitja saagiks jääb terve vastav turusegment, tuletagem meelde kasvõi aega, mil Sergei ja Larry internetiotsingusüsteemide maailma pea peale pöörasid.

Nüüd jõuame ühe olulise teelahkmeni, mis tihti tähelepanuta jäetakse: masstoodetud tarkvara ja üksiktellijale tehtav tarkvara on täiesti erinevad maailmad. Masstoodetud tarkvara alal valitsevad väga kõrgelt makstud staarid, samamoodi nagu Hollywoodi massifilmide alal. Microsofti edu kontoritarkvara alal sai suuresti alguse Charles Simonyi palkamisega, kes selle eest ka rikkalikult tasutud sai.
Konsultatsiooniturul, kus tarkvara hakkab kasutama vaid piiratud arv inimesi, pole staarifaktor nii oluline. Samamoodi nagu Eesti galapeole sobib Merle Palmiste külalisena väga hästi ja sinna pole vaja tingimata Hollywoodi staari tuua (kuigi ma arvan, et korraldajad ei ütleks ka sellest võimalusest ära), pole kohalikule bensiinijaamale andmebaasi tegemiseks tingimata vaja superstaari.
Programmeerija produktiivsuse tagamine on muidugi endiselt kriitiline, sõltumata sellest, mida me teeme, aga oluline on tähele panna, et üht liiki turule orienteeritud organisatsioon ei ole niisama lihtsalt ümber kohandatav teisele. Enamiku tarkvarafirmade jaoks on jackpot ikkagi tiražeeritud tarkvara turul, kus liiguvad tõeliselt suured rahad, kuid et seal laineid lüüa, pole võimalik võtta kampa keskpäraseid koodiväänajaid ja neile öelda, et tehke nüüd next big thing valmis, vaja on vähemalt üht staari, kes meeskonda veaks, ning soovitatavalt võiks ka kõrvalosatäitjad Oscariväärilised olla.

- Mis on programmeerija produktiivsus?

Paljud tarkvaraprojektide eest vastutavad inimesed vaatlevad programmeerijat kui masinat, kuhu ühest otsast lähevad sisse raha ja kofeiin ja välja tuleb programmikood, umbes nagu joogiautomaat: paned raha sisse ja vajutad nuppu ning tulemus ongi käes.

Puutudes kokku olukorraga, kus üks programmeerija või programmeerijate meeskond saavutab paremaid tulemusi kui teine, piirdubki enamik otsustajatest nende parameetrite timmimisega. Programmeerijat proovitakse ära osta, pakutakse talle nii palju tasuta kohvijooke, kui süda kannab, ning nõutakse selle eest iga päev tuhandet uut koodirida.
Selline lähenemine on muidugi vigane nii sisendi kui ka väljundi osas. Koodiridade hulk on küllaltki halb mõõdik, samamoodi nagu seda on tehtud vigade arv jms statistilised näitajad. Millised on paremad mõõdikud, sellest teine kord, praegu keskendume eelkõige sisendi poolele.

- Miks produktiivsuse üle muretseda? 

Teine tüüpviga on enamasti programmeerija produktiivsuse tähtsuse tohutu alahindamine. Õmbleja või müürsepa poolt tehtud töö hulk kõigub ehk paar korda ja tihti vaadeldakse programmeerijat samamoodi. Ahah, lõpetasid sama kooli? OK, paneme su sama palgataseme peale samu asju tegema. 
Tegelikult võib üks programmeerija ideaalolukorras produtseerida 100 või rohkem korda toodangut kui teine ning ilmselgelt peaks iga projekti eest vastutaja tähtsamate murede seas (tarkvaratootmise põhiteoreemi kõrval) olema produktiivsuse tõstmine. Millised komponendid produktiivsust mõjutavad, katsume allpool lahti kirjutada.

1. Motivatsioon

“Don’t work for a living, work for a reason” ütles Microsofti värbamissait, kui ma nendega liitumist plaanisin. Ja tõepoolest, Microsofti kultuur on täielikult läbi imbunud ideest, et me teeme midagi vägevat, mida miljonid inimesed kasutavad, ja oleme turuliidrid. Erinevatel firmadel on muidugi erinevad motivaatorid, mida selle koha peal välja pakkuda, kuid sellised ideed on tihti asjaolu, mis inimesi pärast kella viite tööl hoiab või laupäeval kontorist läbi astuma kutsub. Kui mul on valida, kas vaadata telekat või tegeleda projektiga, saab kaalukeeleks asjaolu, kas see projekt on miski, mis rahuldab minu kõrgemaid vajadusi Maslow hierarhias (eeldusel, et kõik programmeerijad saavad tänapäeval piisavalt raha, et esmased vajadused on rahuldatud). Näideteks neist hüvedest võivad olla teiste inimeste respekt, võimalus rakendada loovust, saavutuse tunne, huvitavate probleemide lahendamine, tähtsustunne vms.
Ma arvan, et kõigi muude asjaolude võrduse korral on hästi motiveeritud, innuka töötaja ja sunnitud, jalgu järel vedava töötaja produktiivsuse vahe kuni 3x.

2. Vahendid

Vahendite all pean ma silmas nii riistvara kui ka tarkvara, kusjuures mõlema kategooria alla kuulub ehk rohkem asju, kui inimesed tavaliselt mõtlevad. Näiteks on monitori suurus produktiivsuse seisukohalt enamasti olulisem kui protessori kiirus, tarkvara alla ei kuulu mitte ainult kompilaator/debugger, vaid ka hulk muid vidinaid profileerijatest source controlini jne.
Valede/kehvade vahendite valik on vahel põhjustatud kliendi veidratest soovidest, vahel teadmatusest, vahel ihnsusest. Olen ise kogenud variante kõigist, igal korral katastroofiliste tagajärgedega, halvimal juhul neist kulus teatud ülesannete sooritamiseks julgelt terve kuu, kui korralike vahenditega oleks läinud loetud päevad.

3. Keskkond

Kas programmeerijatel on olemas koht, kus nad saavad ukse kinni tõmmata ja segamatult oma tööle keskenduda, eemal mürast, tuuletõmbest ja kõrvalruume rentiva pontsikubaari aroomist? Või on fooniks telefonide pidev helin, inimeste sisse-välja traavimine, bossi õiendamine sekretäri kallal ja kõrvallauas anekdoote rääkiv kolleeg? Kõrge produktiivsuse tsooni jõudmine võtab vaimset pingutust nõudva töö puhul vähemalt 15 minutit ning iga segaja puhul tuleb nullist alustada. Suur segajate arv päeva jooksul kahandab kõrge produktiivsusega aega mitu korda.

4. Teadmised

Programmeerimine on asjana iseeneses põnev tegevus, inimene loob eimillestki midagi, mis on väga rahuldustpakkuv kogemus. Sellepärast ongi ehk maailmas rohkem programmeerijaid, kes ka hobi korras oma erialaga tegelevad, võrreldes näiteks juuksuritega.
Teiselt poolt on tegemist väga laia ning kiireltareneva valdkonnaga, kus on samas võimalik peaaegu igat probleemi paljudel erinevatel viisidel lahendada.
Seega pole olemas mingit konkreetset teadmiste kogu, mille inimene koolist kaasa saaks ja oleks “valmis programmeerija”, valdav enamik inimeste teadmistest pärineb lihtsalt niisama asjade kallal nikerdamisest ja nende vastu huvi tundmisest. Programmeerijat tööle võttes küsin ma talt alati näidet sellest, mida ta on lihsalt niisama oma lõbuks valmis teinud või milliseid probleeme lahendanud. Inimestel, kellel on harjumuseks tarkvaraga ka hobi korras tegeleda, on üldjuhul tohutult laialdasemad teadmised kui teistel. Kas ja millal neid teadmisi vaja läheb, on juhuse küsimus, aga kriitilisel hetkel võib leidlik lahendus hoida kokku mitmeid päevi “jõumeetodil” lahendamisele kulunud aega.
Sama kehtib ka akadeemiliste teadmiste kohta: andmebaaside loengut kuulates võib ju küll mõelda, et millal mul seda algrebrat vaja läheb, aga olles vastamisi keerulise päringuoptimiseerimisülesandega, on mul tihti hea meel olnud, et koolikogemus aitab mul mõista, mis andmebaasimootori sees tegelikult toimub.

Üldise tähelepanekuna paistavad kõige produktiivsemad ja mõjukamad inimesed projektis alati silma laialdase teadmistepagasiga, mis on suhteliselt lõdvas sõltuvuses lõpetatud koolide arvust või akadeemilise kraadi kangusest.

5. Projekti läbipaistvus

Kui programmeerija ei tea, mida klient tegelikult tahab, kui analüütik ei  tea, mida programmeerija parajasti teeb, ja bossi peal kasutatakse Jedivõtteid stiilis “these aren’t the droids you’re looking for”, pole midagi imestada, kui asjad venivad ja venivad, aga midagi valmis ei saa. Korralik projektijuhtimine garanteerib muuhulgas:
- spetsifikatsiooni, millest nii klient kui ka programmeerija samamoodi aru saavad
- source trackingu, mille põhjal igaüks saab vaadata, kui palju koodi on kirjutatud ja mida see teeb
- vigade andmebaasi, kust on võimalik igal hetkel vaadata, kas produkt on heas või halvas seisus
- muutuste kontrolli, kus koodimuutused üle vaadatakse, et vältida projekti isevoolu teed minekut
- põhifunktsionaalsuse pideva (soovitatavalt automaatse) testimise, mille pealt on alati võimalik vaadata, kas asi tegelikult töötab või ei.

Need asjad aitavad igal osalisel mõista oma rolli projekti üldises olekus ning võtta vastu optimaalseid otsuseid selles osas, mida parajasti on vaja teha (nt kas on praegu hea uut funktsionaalsust luua või hoopis vanad vead ära parandada, mida kuu aega hiljem juba palju raskem teha on).

6. Otsustusvabadus

Tänapäeva sõjavägedes ei pääse samuti tarkvarast üle ega ümber ja nii mõnigi mundrikandja väänab samas ka koodi. Samas pole tulemused enamasti just kiita. Ma arvan, et probleem on suuresti sõjaväe hierarhilises, vastuvaidlematus ülesehituses. Kui seersant Sigajenko ikka ütleb, et siia paned goto, siis hoiad suu kinni ja paned.

Enamik programmeerijaist õnneks mundrit kandma ei pea, aga tundub, et nii mõndagi firmat juhitakse sarnastel alustel. Programmeerija on siiski see, kes asja tehnilisest küljest kõige rohkem teab, ja nii mõnigi projekt on kihva keeratud sellega, et asjatundmatu juhtkond sunnib tehnilisi töötajaid ebaoptimaalsetele radadele. Leian, et inimene, kes tegelikult koodi valmis kirjutab, peab omama otsustusvabadust vahendite, tehnilise disaini ja muude sarnaste küsimuste osas. Kui projekti kallal töötab palju inimesi, on neil muidugi vaja ühte jalga käia, kuid ka siis peavad otsustajad olema programmeerijate endi esindajad. Kokkuhoitud aeg kaalub kindlasti üles mittetehnilise juhtkonna või tellija võimunäitamisvõimalused, inimeste moraali hoidmisest rääkimata.

7. Kogemused

Last but not least, eelmiste projektidega saavutatud kogemused on alati kulla hinda väärt. Infotehnoloogia on tohutult kiiresti muutuv valdkond ja projekti tegemise ajal õppimine on pigem reegel kui erand. Seda enam väärtustuvad juhused, kus eelmises projektis õpitut on võimalik uuesti kasutada, või veelgi parem, on olemas näiteks üldotstarbeline klassiteek, mida uuele projektile sujuvalt üle saab kanda.

Kogemused võivad olla mitut laadi, vahel on nad kogenud programmeerija peas, kes uutele inimestele oma nõuga palju päevi jalgratta leiutamist kokku võib hoida, vahel kristalliseerunud olemasoleva koodi näol. Oluline on selle kogemuse loomine ja säilitamine. Kui vana programmeerija uuele bossile ei meeldi ja lahti lastakse, või kui keegi leiab, et nüüd liigub kõik see mees uuele tehnoloogiale ning vana koodi viskame minema, on tagajärjeks üldjuhul paljude, paljude inimkuude kaotus.

Kokkuvõtteks, programmeerija produktiivsus sõltub paljudest faktoritest, lisaks ülaltoodutele on veel mitmeid teisigi. Edukad on üldjuhul ettevõtted, kes suudavad võimalikult paljud nupud õigesse asendisse pöörata ning hiljem imestavad nad isegi, et mis küll naabermaja inimestel viga on, et nad ka kümme korda rohkema aja ja raha kulutamise järel midagi valmis pole saanud.