Targo tarkvara

Alanud on taas projektijuhtimise kursus ja siia tekkivad minu loenguslaidid – võrreldes eelmise aastaga väikeste muudatustega.

Räägin teile kõigepealt ühe loo.

Juba antiikajal tegid inimesed vaatlusi ümbritsevate protsesside kohta.

Taigent sai muuta leivaks, savi tellisteks, puid söeks, rasva seebiks.

Mõistagi tekkis neil ka küsimus, et miks ei saaks näiteks raud muutuda kullaks?

Tuhanded alkeemikud nägid selle probleemi kallal sajandite jooksul vaeva. Kuna neil aga puudus arusaam sellest, millest erinevad ained ja materjalid tegelikult koosnevad ning kuidas nende omavaheline vastasmõju tegelikult töötab, ei saanud nende lähenemine ka kuigi süsteemne ja teaduslik olla.

Nad kuumutasid ja aurutasid, filtreerisid ja kondenseerisid, segasid kokku kõikvõimalikke aineid ning kirjeldasid oma tulemusi müstilises, allegoorilises keeles, et “asjasse pühendamata” inimesed millestki aru ei saaks.

Sagedased koostisosad olid näiteks väävel ja elavhõbe, usuti, et kui neid vaid õiges vahekorras lisada, saab nende abil kõike teha.

Ja alkeemikud kallasid ühest purgist väävlit ja teisest elavhõbedat ning laususid veel nõiasõnu peale – habbada-habbada-habbada.

Inimestel on siiski süüa ka vaja ja alkeemikud pakkusid tihti oma teenuseid kuningatele ja vürstidele, et viimased nende eksperimente rahastaks.

Ahnusel on suured silmad ja seetõttu maksiski nii mõnigi võimukandja alkeemikule heldelt, vähemalt esialgu. Pikapeale sai kuninga kannatus muidugi otsa ja ta hakkas konkreetseid tulemusi nõudma.

Kui muidu enam ennast välja keerutada ei õnnestunud, läks nii mõnigi alkeemik lõpuks võltsimise teed ning seadis üles demonstratsiooni, kus kullakangid olid algul näiteks tinaga kaetud, tina sulatati pealt ära ja nähtavale tuli kuld.

Kui nad aga sellega vahele jäid, oli karistus tavaliselt karm. Tihti rakendati sama karistust, mis valeraha tegijate puhul, ehk kallati õnnetule alkeemikule sulatina kurku.

Väga, väga ebameeldiv.

Aeg läks edasi. Matemaatikal oli tegelikult juba antiikajast saadik päris korralik ja range teaduslik põhi all olnud. Renessansi ajal tegi Galilei oma katseid, talle järgnesid Torricelli, Blaise Pascal ja Robert Hooke ja füüsika sai endale samasuguse range põhja.

Lõpuks jõudsid Robert Boyle, Lavoisier, Lomonossov ja Mendelejev ka keemiale range põhja loomiseni ja alkeemikute aeg oli lõppenud.

Sarnaselt juhtuvad revolutsioonid ka teistes teadustes, nad käivad alguses läbi oma “alkeemia faasi”, kus keegi täpselt ei tea, mida ta teeb. Vähehaaval saadakse asjad korda ja meil tekivad konkreetsed seadused, reeglid ja valemid.

Infotehnoloogia vallas käib tarkvaraprojektide juhtimise praktika käib praegu täpselt nagu alkeemia. Projektijuhid teavad, et tarkvara tegemiseks on vaja raha ja programmeerijatele meeldivad kohvijoogid. Ja nii nad lisavadki projektile erinevates vahekordades raha ning kofeiini, täpselt nagu vana aja alkeemikud lisasid erinevatele ainetele väävlit ja elavhõbedat. Ja siis lähevad kliendi juurde ja teevad kliendile habbada-habbada-habbada.

Ja nagu alkeemikute puhulgi, on üsna tõenäoline, et ilma teaduslikuma lähenemiseta lasete te üsna palju projekte kas põhja või viite kuidagi katse-eksituse teel lõpule.

Kui te seda piisavalt palju teete, siis lähevad teie projektiliikmed, ülemused ja kliendid samamoodi närvi nagu keskaegsed kuningad ja nendes tekib soov teid mingil väga ebameeldival viisil hukata.

Praeguse loengusarja eesmärk on teid sellest hullust saatusest päästa, ehk et keegi ei tuleks teile sulatinaga kallale.

See, et te kõik olete tulnud kuulama loengut projektijuhtimisest, ei tähenda veel, et te saate tingimata projektijuhiks, aga suure tõenäosusega hakkate te mitmesugustes tarkvaraprojektides mingis rollis osalema. Võib-olla tellija, võib-olla täitja poolel, vahest programmeerijana, vahest analüütikuna, vahest suure ülemusena.

Sellegipoolest, kuna projektijuhid on projektides kesksel kohal, puutute te nendega kindlasti kokku ja siis on väga hea, kui teil on olemas mingid praktilised nõuded, mida neilt projektijuhtidelt soovida ja kui nad sellega hakkama ei saa, siis saate ise esile astuda ja vajalikud asjad ära teha.

Projektiga tegelejad rajasid süsteemi lähtudes tavaliste kontoritöötajate kogemustest, inimestel on tööjaam, kohtvõrk, andmed jooksevad kõik andmebaasist jne. Ainult et FBI agendid ei ole tavalised kontoritöötajad, nad liiguvad “objektidel” ringi ja neil on vaja andmeid kaasa võtta ning ka offline’is sisestada. Ja keegi ei tulnud ka selle peale enne, kui süsteemi juurutama hakati. Kui palju võtab aega olemasolevale süsteemile turvaliste offline-võimaluste juurdepookimine, võib igaüks ise nuputada, kuid antud projekt katkestati (selle ja paljude, paljude muude probleemide tõttu) pärast 170 miljoni dollari maksumaksja raha kulutamist. Kui vajadused oleks tuvastatud õigeaegselt, oleks kogu süsteemi loodud hoopis teistel alustel ning tohutu hulk aega oleks jäänud raiskamata.

Projektijuhi roll on tihti arusaamatuste ja segaduse allikaks.

Juhtkonna stereotüüp: klient ja programmeerija ei tohi kokku saada, projektijuht kaitseb neid teineteise eest

Tehniku stereotüüp: projektijuht on mingi pintsaklipslane, kes tegelikult asjadest midagi ei tea ja keda asjadest eemal hoida

Olen ise kuulnud programmeerijat halvustavalt mainimas “projektijuhtide invasiooni Eesti tarkvaramaastikul”. Probleem jällegi selles, et kui näiteks programmeerija töö on ka praktikas viidud küllaltki teaduslikele alustele, siis projektijuhid on tihti endiselt alkeemikud. Tegelikult on ka projektijuhtidel olemas täiesti teaduslikud reeglid, kuidas üht projekti edukalt lõpuni viia, täpselt nagu meil on olemas reeglid selleks, kuidas võrrandisüsteemi lahendada.

Iga risk mõjutab potentsiaalselt meie lõpptähtaega.
Riskid on potentsiaalselt vahetatavad aja vastu – projektiplaani saab lisada aega riski maandamiseks.
Alternatiivina saame riskifaktori lahendada enne projekti algust

Lugege lihtsalt neid teste ja mõelge, mida teha, et teie projekt mõnesse sellisesse auku ei kukuks.
Teadmiste omandamisel 70:20:10 suhe: 70% töö käigus omandatav, 20% raamatute lugemine jm iseseisev töö, 10% formaalsed koolitused, sealhulgas praegu siin loengus istumine! Selleks, et reaalselt mõni projekt ära teha, läheb teil tarvis palju rohkem teadmisi, kui see praegune loengukursus teile anda suudab -> lugege kindlasti oluliselt juurde, kursuse kodulehel on soovitatavat lugemismaterjali.

Aga kui te kunagi peaks minuga koos mõnd projekti tegema ja seal projektijuhina tegutsema, siis ma kindlasti eeldan, et te olete Software Project Survival Guide’i või mõne muu ekvivalentse raamatu läbi lugenud, muidu ei võta ma teid tõsiselt.

Need siin on näited, mitte täielik nimistu!

Riske pole kunagi võimalik täielikult välistada, aga neid saab oluliselt maandada kasutades vastavaid “filtreid”.

Kui kliendi ärilised eesmärgid jäävad täitmata, on nad lõpuks ikka õnnetud. Isegi kui teostaja oma raha kätte saab, võib projekti lugeda ebaõnnestunuks, kui keegi seda tegelikult kasutama ei hakka.

Loe lähemalt, Practical Project Initiation, lk 42-43
Huvide näiteid: juhtkond tahab suuremat käivet, andmesisestajad tahavad vähem käsitsitööd -> vähem vigu, müügiagendid tahavad kiiremat ligipääsu andmetele
Eelkujundatud suhtumiste näiteid: Andmesisestajad kardavad, et peavad mingitele uutele koolitustele minema, süsadminid arvavad, et ainult Solaris on õige asi
Võiduläve näiteid: Juhtkond tahab, et meie veebisait pakuks rohkem võimalusi kui konkurentide oma. Andmesisestajad tahavad automaatset veaparandust, andmebaasi administraatorid tahavad 3x suuremat andmebaasimahtu
Piirangute näiteid: juhtkonna eelarve on max 4 miljonit, andmesisestajatel on vanad arvutid ja uus kood peab nendel jooksma, samuti pole neil eelarves raha koolituseks

Sponsor on see, kelle käes on rahakott. Tema maksab nii minu laste leiva kui ka peadirektori Ferrari eest.

Kiviat diagram
Tihti juhtub, et tellija või mõni suur ülemus ütleb

Ma olen üsna kindel, et enamikul teist tuleb kunagi ühel või teisel viisil sellises situatsioonis olla.

Nõuded tegelikult omaette pikk teema, sestap siin kaetud lühidalt

Millal me loeme projekti edukalt lõpetatuks

Aga kui te saate need kõik valmis, on tulemuseks kuld.

Pidasin sel nädalal MHG gümnaasiumiosale ettekande matemaatikast ja teaduslikust meetodist. Panen oma märkmed ka siia kirja.

Tere rahvas! Mul paluti siia täna suhteliselt vabal teemal rääkima tulla. Ja kui tegemist on vaba teemaga, siis üldiselt katsuvad inimesed ikka kõige lihtsama väljapääsu leida.

Aga mis on kõige lihtsam asi, millest rääkida? Enamasti on inimestel kõige lihtsam rääkida iseendast.

Tänase jutu teemaks olen seega mina ise, ehk siis minu temaatika ehk ma-temaatika. Ehk siis matemaatika minu elus. 

Kes ma sihuke olen. 1995 lõpetasin Haapsalu Gümnaasiumi, 1999 Tartu Ülikooli. Kuni 2008 olin Microsoftis ja tegin tarkvara.

Austavaks ametinimetuseks oli mul tarkvarainsener, mis tähendas, et ma sain ise igasuguseid huvitavaid asju välja mõelda ja oma kätega midagi uut valmis teha. Mingil hetkel juhtub aga üsna sageli, et mingis grupis võetakse parim spetsialist ja pannakse ta teisi spetsialiste juhtima, nii juhtus ka minuga ja alates 2005 aastast olen ma tegelenud pigem teiste inimeste juhtimisega kui ise millegi valmistamisega.

2008 tulin Eestisse tagasi, praegu olen Webmedias ja juhin seal üht äriüksust. See tähendab, et mul on oma inimesed, oma eelarve, oma kliendid, oma tulud ja oma kulud. 

Sellega seoses on vaja ka suurt hulka arvutamist, mille tulemusel leitakse enamasti üks konkreetne arv. See arv on minu üksuse kasum või kahjum.

Kui see arv on hea, siis on kõik hästi, sõidame Havaile puhkama ja oleme eluga rahul. Kui see arv ei ole hea, siis on kõik halvasti, inimesi tuleb lahti lasta ja üldse on kõik õnnetud.

Oluline on tähele panna, et tähtis pole mitte selle arvu tagantjärele välja rehkendamine, vaid pigem ennustamine, milliseks kujuneb tulemus järgmisel kuul, järgmisel kvartalil või järgmisel aastal, et meil oleks võimalik selle vastu mingeid konkreetseid samme astuda ja tulevikuks valmis olla. Tuleviku ennustamisel on meil aga tegemist väga paljude erinevate muutujatega ja nende erinevate koosmõjude kombinatsioone saab hinnata ainult mingit laadi statistilist analüüsi kasutades.

Lihtsustatult seega: mida parem matemaatikaoskus, seda parem ennustusvõime ja seda edukam äri.

Eelmine näide oli sellest, kuidas konkreetselt minul läheb vaja matemaatikat mingite konkreetsete ülesannete lahendamiseks. Sama näite võime aga tuua peaaegu suvalise muu eluala kohta. Igapäevastes toimingutes on meil kaks võimalust:

-Me kas teame, et mida teha, meil on selle jaoks mingi hulk reegleid, kuidas mingis konkreetses situatsioonis käituda. Me oskame vastata küsimusele “MIDA?” -Või me võime teada, et miks me midagi teeme, mis on liikumapanevad põhjused, millest need reeglid tulenevad. Me oskame vastata küsimusele “MIKS?”

Niikaua kui kõik on tavapärane, piisab esimesest lähenemisest, aga kui saabub mingi kriisisituatsioon, siis lihtsatest reeglitest enam ei piisa, siis ongi meil vaja vastust küsimusele “MIKS?”

Et MIKS küsimustele efektiivselt vastata, on vaja omada teadmisi selle ameti alusdistsipliinidest.

Oletame, et te tahate hakata presidendiks või mingiks muuks riigimeheks. Selleks, et selles ametis raskete olukordadega hakkama saada, on vaja tunda avaliku halduse põhimõtteid. Selleks aga, et tunda haldust, on vaja tunda sotsioloogiat ja äri. Nende jaoks on aga vaja tunda demograafiat, statistikat ja majandust. Ja niiviisi mööda ahelat edasi minnes jõuame mingil hetkel matemaatikani.

Oluline on see, et me ei kasuta matemaatikat mitte otse, vaid me kasutame selle rakendusi. Seega tuleb meil kindlasti mõista mitte ainult matemaatikat, vaid seda, mis toimub nende vahepealsete noolte sees – kuidas matemaatikat tegelikult ühes või teises teaduses ära kasutatakse ja kuidas neid teadusi omakorda igapäevaelus ära kasutatakse. 

Samamoodi on meil võimalik mõelda ka kõigist muudest asjadest maailmas.

Esimeses lähenduses me võime olla rahul sellega, et asjad on niisugused nagu nad on.

Järgmise tasemena me võime mõelda sellest, et millised asjad veel olemas on?

Ja lõpuks võime mõelda sellest, et MIKS maailma asjad on just sellised nagu nad on?

Ja selle viimase MIKS küsimuse vastuse juurteni minnes jõuame väga tihti selleni, et matemaatika annab meile võtme oma küsimustele vastamiseks. 

Ja kui meil on käes see võti maailma mõistmiseks, muutub meie elu ja asjadest arusaam tohutult rikkamaks ja rahuldust pakkuvamaks.

Räägime järgmiseks natuke filosoofilisemal teemal.

Ehk kust tulevad üldse meie teadmised?

Teadmisi on mitut laadi:

-Enda kogetud asjad

-Teistelt kuuldud asjad, näiteks see, mida vanemad lastele räägivad

-Olemasolevate teadmiste põhjal tõestatud ja põhjendatud asjad  

Need kõik on kvalitatiivselt erinevad ja oluline on nende vahel vahet teha! Samuti on igal sellisel teadmisel usaldatavuse väärtus, mis sõltub teise kategooria puhul näiteks rääkija usaldatavusest ning kolmanda kategooria põhjal tuletusmeetodi korrektsusest ja rangusest.

Usaldatavuse seisukohalt on kõige olulisem teha vahet põhjendatud ja mittepõhjendatud väidete vahel.

Matemaatika on selles osas ideaalne, et matemaatikas ei võeta ühtki väidet tõena, kui ta pole enne põhjendatud ja tõestatud.

Võtame kasvõi sellise lihtsa näite nagu Pythagorase teoreem.

Kui meile lihtsalt väidetakse, et täisnurkses kolmnurgas a2+b2=c2, siis me võime seda lihtsalt uskuda või alternatiivina võime küsida tõestust. Õnneks on matemaatikas väidetel üldjuhul olemas tõestused ja põhjendused. Ja Pythagorase teoreemi saame tõestada üsna lihtsal viisil:

Seega tekitab matemaatika inimeses harjumuse erinevaid väiteid kontrollida ja põhjendada.

Matemaatika vastandiks on selles mõttes religioon. Religioonis öeldakse meile, et me lihtsalt peame mingit asja uskuma ja kõik. Ja kui me ei usu, siis läheme põrgusse. Kasvõi Martin Luther on öelnud, et mõistus on usu suurim vaenlane.

Seal vahepeal on aga veel hulk võimalusi igasugustest väidetest, mille esitajad (nt poliitikud või müügimehed) tulevad ja räägivad meile targa ja veenva näoga, et asjad on just nimelt mingil konkreetsel viisil, aga nad ei põhjenda seda kuidagi! Või siis põhjendavad puudulikult.

Kui me oleme harjunud väidete kontrollimisel matemaatilise rangusega, siis saame ka:

a)Kontrollida, kas meie oponent esitab oma väiteid korrektselt .

b)Leida nendes väidetes vastuolusid.

Mõned näited, millega ma ise olen kokku puutunud:

Näide 1: homöopaatia. Võetakse mingi toimeaine, lahjendatakse seda veega pooleks ja loksutatakse. Siis lahjendatakse jälle ja loksutatakse. Ja nii näiteks 30 (või 60 või 200) korda järjest. Mida rohkem, seda uhkem. Matemaatiliselt saame kerge vaevaga aru, et tulemis pole tõenäoliselt enam mitte ainsatki esialgse aine molekuli, aga inimesed, kes matemaatikat ei tunne, ostavad ikka.

Näide 2: kinnisvarakrahh. Paljud inimesed väitsid tõsise näoga, et kinnisvarahinnad ainult tõusevad ja muud moodi ei olegi üldse võimalik. Ja teised uskusid, hoolimata sellest, et lihtne arvutus näitab, et selline kasv pole majanduslikult jätkusuutlik. Ja võtsid suuri laene eeldusel, et mõne aasta pärast müüvad oma korteri tohutu kasumiga maha ja maksavad laenud tagasi.

Näide 3: puhkuseosakud. Olen juhtunud paarile puhkuseosakute müügiüritusele, kus müügimees veenva näoga seletab, kui hea diiliga ikka tegemist on. Joonistab tahvlile arvusid ja “tõestab”, kui palju raha ma sellega ikka kokku hoian. Mina näen muidugi läbi, et ühes tulbas on arvud inflatsiooniga läbi korrutatud ja teises mitte, selle peale teeb kähku teist juttu. Aga kõrval inimesed ostavad ja kiidavad. Mõni aeg hiljem aga avastavad, kuidas hulk inimesi üritab eBayl meelehetilikult neist osakutest lahti saada.

Ma näen siin saalis mitut matemaatikaõpetajat. Matemaatikaõpetajatelt küsitakse ilmselt tihti, et miks ma pean neid ülesandeid lahendama kogu aeg? Mis mul sellest päris elus kasu on?

Kehalise kasvatuse õpetajad panevad samas näiteks poisse kätekõverdusi tegema. Mis meil sellest päris elus kasu on? Kätekõverduste puhul on vastus küllaltki otsene – see teeb inimest tugevamaks ja ta jaksab päris elus paremini sooritada sarnaseid tegevusi, kus kätejõudu vaja läheb.

Matemaatikaülesannetel on samasugune efekt inimese aju treenimisel. Tegelikus elus koosneb minu enda töö pidevast ülesannete lahendamisest. Mõned näited sedalaadi ülesannetest:

-Hinnang, kui kaua mingi projekt aega võiks võtta

-Hinnang, kui palju me järgmisel kuul raha teenime

Need on puhtalt arvutuslikud ülesanded. Aga on ka selliseid ülesandeid:

-programm töötab praegu liiga keeruliselt – tehke ta lihtsamaks

-programm on aeglane, tehke ta kiiremaks

Ehk siis ülesanded, kus meil pole isegi mitte täpne valem teada, kuidas sellisele ülesandele üldse läheneda. Me peame ise välja mõtlema, millist valemit kasutada, milliseid parameetreid seal rakendada.

Ja siis on veel ülesanded nagu:

- Ma tahaksin, et sinu osakond teeniks rohkem raha

-Tee nii, et inimestel oleks sinu organisatsioonis parem töötada

Selliseid suureemaid ja väiksemaid ülesandeid tuleb minu ette iga päev ridamisi. Ja ainuke võimalus nendega hakkama saamiseks on omada piisavalt hästi ülesannete lahendamiseks treenitud mõistust, nii et ma saan  kiiresti võtta: ülesanne->lahendus, ülesanne->lahendus, ülesanne->lahendus.

Muuseas: vahet tuleb teha harjutusel ja ülesandel. Lihtsalt tulpades võrrandite lahendamine on harjutus. Tekstülesanne, kus valem pole ette antud, on oluliselt kasulikum!

Paljud asjad matemaatikas on kasutatavad väga mitmel eri moel. Näiteks võrrandite lahendamine on osaks praktiliselt kõigist matemaatika rakendusaladest.

Kui me oskame mitmesuguseid erinevaid võrrandeid lahendada, on nad meile abiks igal pool, arhitektuurist ärijuhtimiseni.

Üks ja seesama matemaatiline MUDEL on kasutusel väga paljudes eri valdkondades.

Seega, matemaatika on nagu keeleõpe:

kui me õpime ennast mingis keeles väljendama, on meil võimalik kirja panna lõputult erinevaid mõtteid, üksikutest lausetest kuni paksude raamatuteni.

Ja kui me õpime matemaatika keelt oma elus kasutama, on meil samuti lõputult võimalusi seda erinevates kontekstides ära kasutada.

Kokkuvõtteks:

-Maailm põhineb ühel või teisel viisil matemaatikal.

-Matemaatika mõistmine on võti maailma mõistmiseks (või vähemalt korrektseks mõistmiseks, on ka teisi filosoofiaid, mis annavad meile ebakorrektseid tulemusi).

 -Matemaatika harjutamine loob eeldused elus tekkivate probleemide lahendamiseks.

Sekka küsiti mult veel mitmesuguseid lõbusaid küsimusi:

Küsimus: kas Kuu peale on mõistlik maatükki osta?

Vastus: Igasuguse investeeringu puhul on meil tegemist matemaatilise mudeliga, mis peegeldab mingit laadi reaalsust. Mul on näiteks natuke Microsofti aktsiaid ja Brasiilia riigi võlakirju, mis peegeldavad vastavalt seda, kuidas Microsoftil ja Brasiilial tulevikus läheb. Kui neil läheb hästi, läheb ka minu investeeringul hästi, aga oluline on kasutada eelpool toodud usaldatavuse mõõdikuid ehk siis ise aru saada, kas vastav majanduslik mudel tegelikult paika peab või ei, mitte lihtsalt müügimehe juttu uskuda. Kuu majandusliku tuleviku osas olen skeptiline.

Küsimus: aga kas me saame tegelikult uskuda, et Martin Luther niiviisi ütles?

Vastus: Ainsad a priori usaldatavad väited on matemaatilised tulemused. Kõigi muude kohta kehtib usaldatavuse hinnang, mis on <100%. Kuna aga antud juhul oli tegemist minu jaoks usaldusväärse allikaga, hindan ma selle tsitaadi korrektsuse tõeväärtust kõrgeks.

Küsimus: kas armastus on ka matemaatilise mudeli järgi hinnatav?

Vastus: Armastus tähendab tegelikult seda, et mõni isik tundub meile subjektiivselt tohutult parem ja väärtuslikum kui teised. Loogiliselt võttes inimeste vahel muidugi nii suuri erinevusi ei ole. Bioloogiliselt soodustab armastuse olemasolu aga monogaamsete suhete tekkimist ja selle läbi liigi püsimist. Seega on armastamise võimelistel isenditel geneetiline eelis ja armastus kui fenomen on tekkinud loodusliku valiku tagajärjel. OLULINE: see ei tähenda, et armastus ei oleks hea ja tore. See, kui me suudame mingit fenomeni teaduslikult põhjendada, ei kahanda kuidagi selle emotsionaalset väärtust, täpselt nagu päikeseloojangu värvide füüsikaline selgitus ei tee seda kuidagi vähem ilusamaks

Küsimus: Inimesed mõistavad maailma praegu hoopis teisiti kui tuhat aastat tagasi. Kas meie praegune teaduslik mudel ei ole tuhande aasta pärast täpselt samamoodi aegunud kui praegu tuhande aasta vanune?

Vastus: Teadusliku meetodi eripära on see, et teaduslikud tulemused on falsifitseeritavad ja kolmandatel osapooltel peab olema võimalik nende kehtivust või mittekehtivust sõltumatult kontrollida. Tuhat aastat tagasi oli teadusliku meetodi alusel ära kirjeldatud väga väike osa maailmast, aga see osa, mis oli teaduslikult kirjeldatud, peab suures osas praegugi paika. Praegu on inimeste teaduslik arusaam laienenud ja ma olen optimistlik ka praeguste tulemuste säilimise osas tuhande aasta pärast.

Selle kevade projektijuhtimise loengute viimased materjalid!

Slaidid leiate siit. Audiosalvestus (r-click->save as): 1. osa, 2. osa, 3. osa, 4.osa.

Seekordses loengus pärinevad mõned slaidid originaalis minu võimekatelt töökaaslastelt Siim Puskailt ja Andre Krullilt.

 Eelnevalt on juttu olnud mitmesugustest projektijuhtimise aspektidest – riskid, nõuded, inimesed.

Täna räägime viimasest väga olulisest aspektist – see on raha.

Ja siis võtame selle kõik kokku.

Rahal on ühiskonnal küllaltki oluline kultuuriline roll, mis kajastub ka näiteks paberrahade disainis.

Mõned rahad pole siiski selgelt kunstipäraselt kõige õnnestunumad.

Selline etteulatuv habe jäi paraku ainult Aasia moeks.

Lõpuks pani see tüüp asjad paika.

Teistes kohtades leitakse jälle, et raha peal võiks olla võimalikult hirmuäratavad inimesed.

Kui kätte saan, tapan ära!

See on juba päris jube.

Siis on olemas rahad, mis näevad välja nagu värvipimeduse testid.

Või siis palavikuhallutsinatsioonid.

Diktatuuride rahadel on tihti sarnased jooned. Suur Vend jälgib!

Lihtne inimene (nagu meie!) suundumas kusagile, püstol käes. Tõenäoliselt tapma mõnda teist lihtsat inimest nagu meie, aga kes on meie silmis tehtud vaenlaseks või vaenlase käsilaseks.

Saddamil kasvab mingi asi pea seest välja, aga keegi ei julgenud talle seda ilmselt öelda.

Mõned rahad on lihtsalt mõistetamatud. Mis see on, kas äraraiutud haarmetega kaheksajalg?

Mida kauem ma seda vaatan, seda ebamugavamalt ma ennast tunnen.

http://www.targotennisberg.com/tarkvara/2008/05/31/miks-mulle-meeldib-raha/

Iga projekt taandub lõpuks rahale!

Tihti loetakse kokku ainult arenduse aeg.

Ei tohi unustada ka teiste inimeste aega sinna juurde liita.

Igaühel oma tunnihind!

Kes on seda reklaami näinud?

http://www.youtube.com/watch?v=at_f98qOGY0

http://www.youtube.com/watch?v=WOsylvrwo3I

http://www.youtube.com/watch?v=jAasManZ6IA

Minu enda ajahaldus

Kolmas osa Projektijuhtimise loengutest.

Slaidid on siin. Audiosalvestus: 1. osa, 2. osa, 3. osa, 4.osa (right-click -> Save As).

Seekordses loengus pärinevad mõned slaidid minu taipliku kolleegi Ivo Mägi sulest.

Räägin teile kõigepealt ühe loo.

Üks kõige ohtlikumaid olukordi inimese jaoks on lahing sõjas. Piirkond on täis suurt kuumust, ohtlikke aineid, ülehelikiirusega ringi lendavaid metallitükke jne.

Samas, kõige olulisem mõjutaja inimese elus on enesealalhoiuinstinkt. Seega, kui sõduritel on vaja näiteks üle mingi lagendiku rünnaku joosta, on see nende jaoks kõige loomuvastasem asi maailmas.

Sellegipoolest, kui antakse vastav käsk, siis sõdurid tõusevad püsti ja jooksevad üle selle lagendiku.

Miks?

Peamiselt sellepärast, et neisse on pikkade ja raskete õppuste kestel sisse drillitud absoluutne sõnakuulamine. Nad teavad, et käsk on vanem kui meie ja et nende enda elu pole suures plaanis oluline. USA merejalaväelastel pole lubatud kasutada sõna “mina”.

Põhiväljaõppe käigus õpivad sõdurid oma ülemust kartma rohkem kui surma. Sest ülemus on suur ja hirmus (nagu mina). Ülemus ütleb, et jookse ja sõdur jookseb. Ütleb, et lama ja sõdur lamab. Ütleb, et lenda ja sõdur vehib kõigest hingest kätega, et lendu tõusta.

Paljudele tsiviilelu organisatsioonijuhtidele meeldiks oma organisatsiooni samamoodi juhtida. Et aina käsuta ja kõik kohe teevadki nii, isegi kui see nende isiklikele huvidele või enesealalhoiule vastu käib.

Paljud proovivadki nii teha. Paraku küll mitte väga edukalt. Sõjaväes pole sõduril kusagile pääsu – kui ta jalga laseb, siis püütakse ta kinni, pannakse vangi või lastakse maha. Tsiviilelus saadetakse nõme ülemus aga varem või hiljem pikalt või siis lihtsalt ignoreeritakse teda.

See suhtumine on tegelikult väga levinud, mul on endal ka tihti kiusatus olnud karmi käsutamise abil probleeme lahendada. Ja kui ma kunagi oma vennale rääkisin, et minu  tiimi liikmete töö tulemused ei vasta alati päris sellele nagu ma soovisin, oli tema esimeseks reaktsiooniks: kas sa nende suhtes mingeid sanktsioone ei saa rakendada?

Vabandust, vennas, see asi pole paraku nii lihtne.

Kui ma selle habeme ära võtan, siis mina olen endiselt mina.

Tänane loeng on eelkõige inimeste juhtimisest. Suure tõenäosusega te kõik ei hakka oma karjääri jooksul inimesi juhtima, aga üsna kindel on, et keegi hakkab teid ennast juhtima ja siis on hea teada

Kui paljud siin ruumis on suitsetajad? Kas see, et ma seda pilti näitan, paneb teid suitsetamist maha jätma?

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!

Aga kõigepealt sellest, keda meil üldse ühte projekti vaja on. Järgmised slaidid olid mul juba esimeses loengus ka, aga kordamine kulub ära.

http://www.targotennisberg.com/tarkvara/2008/03/02/staarid/

Audiosalvestuse 1. osa lõpp.

http://www.targotennisberg.com/tarkvara/2008/09/24/arendajate-arengust/

Uus arendaja tuleb projekti, ta ei kata veel oma ruudukest täielikult ära.

Teised arendajad, analüütikud, testijad peavad teda abistama.

Aja möödudes saab abi vajajast abi andja, inimese kompetents kasvab.

http://www.targotennisberg.com/tarkvara/2009/01/15/tagasiside-andmisest-ja-saamisest/

Lugu seitsmest ahvist. Kuulake audiosalvestust J

http://www.targotennisberg.com/tarkvara/2008/06/06/eduka-projekti-retsept/

Audiosalvestuse 2. osa lõpp.

http://www.targotennisberg.com/tarkvara/2008/02/25/programmeerija-produktiivsus-i/

Audiosalvestuse 3. osa lõpp.

Teine osa Projektijuhtimise loengutest.

Siit leiate slaidid. Audiosalvestus: 1. osa, 2. osa, 3. osa.

 Tänane loeng on suurel määral analüüsist. Aga isegi kui te ise olete ainult projektijuht ja analüüsiga ei tegele, peaksite ikkagi teadma, mis toimub ja kuidas on õige asju teha.

 Räägin teile kõigepealt ühe loo.

Kui ma veel ise vaene üliõpilane olin, kärutasin vahel maailmas ringi häälega. Üldiselt lahe kogemus, sest rahvas, kes hääletajaid peale võtab, on üldiselt väga kenad inimesed.

Sekka sattus muidugi ka igasuguseid imeinimesi. Oli näiteks üks tegelane, kes ise ka ei teadnud, kuidas täpselt oma sihtkohta jõuda, tema meetodiks oli lihtsalt kohalike käest juhiseid küsida. Mina ei olnud kahjuks kohalik ja eriti aidata ei osanud. Kohalikku keelt ei tundnud me ka keegi ja nii juht seletaski inimestega käte ja jalgade abil. Ise oli ta küllaltki joviaalses tujus ja valis küsimiseks ka rahvast, kelle adekvaatsus minu meelest kõvasti soovida jättis, aga kes olin mina, et teda selle eest kritiseerida, eks.

Ja nii me tiirutasime ja tiirutasime, kuni lõpuks kulus mõnekümne kilomeetri läbimiseks mitu tundi.

Sel ajal oli mul küll teine elustiil ja rohkem aega kui praegu, nii et viivitusest polnud väga hullu, aga mõnes teises olukorras oleks see küll harja punaseks ajanud.

Tegelikult on meil siin ilmne analoogia tarkvarategemisega. Me võime tarkvaraprojekti ka läbi viia selliselt, et teeme natuke midagi, siis küsime suvaliselt inimeselt instruktsioone, siis teeme jälle natuke, küsime mõnelt teiselt inimeselt jne. Mis te arvate, milliseid ajahinnanguid me sellise meetodi kasutamise korral saame anda?

Või siis võime hankida endale kaardi.

 Ma olen ise suur kaartide ja kaarditarkvara fänn, katsun alati võimalikult suurt navigeerimisvõimekust omada, kui kusagil käin või sõidan.

Tänapäeval on selleks head võimalused, veebis ja GPS seadmetes olevad kaardid ütlevad meile minuti täpsusega, kuhu me mis ajaks jõuame.

Ja tarkvara on ka parem teha, kui meil on täpne instruktsioon ees, et nüüd teeme seda ja siis toda. Ajahinnangutest rääkimata.

Tegelikus elus juhtub aga, et meie tarkvara valmistamise instruktsioonid on pigem sellised. Natuke parem kui turbanis vanamehelt saadud instruktsioonid, aga mitte väga.

Ja ajahinnangud on ka muidugi vastavad.

Tänane loeng ongi sellest, kuidas oma kaart võimalikult täpseks saada.

Definitsioonide erisus on peamine segaduse ja kommunikatsiooniprobleemide allikas tarkvaraprojektis.

Definitsioonid tuleb algusest peale paika panna.

 Lõpliku spetsifikatsiooni sisu on tihti tracetav tagasi ärireegliteni

 Tarkvara võib olla nt veebisait või pihuarvutite süsteem vms asi

baba-interface

 Näide: tehnoloogiline kitsendus, et me tohime kasutada ainult vaba tarkvara. projekt tehti .neti peale. 

Kui mõni neist osadest jääb alguses kirjeldamata, ei pääse me sellest ikkagi – lõpuks tuleb ta lisada ja see võib tähendada olulist projekti ümbertegemise kulu.

 1.Paneme paika mingi konkreetse eesmärgi

Paljude mõõdikute lähteandmed saa ajaarvestussüsteemidest.

Kunagi ma arvasin, et ajaarvestussüsteemid on kuradist, sest programmeerijaid ei tohi hinnata selle põhjal, kui palju aega nad projektile kulutavad.

Aga ajaarvestussüsteemi primaarseks eesmärgiks pole mitte see, kui palju inimene aega kulutab ja kui kaua ta kontoris istub, vaid hoopis see, millele me organisatsioonina oma ressursid kulutame.

Antud juhul oleks mõõdikuks see, et taskidel, mis on ajaarvestussüsteemis, on olemas ka vastavad väljad selle jaoks, mis sorti hooldusega on tegemist.

Äärmiselt oluline tähelepanek: Neid mõõdikuid ei tohi kasutada inimeste töötulemuste hindamiseks!

Olen tihti näinud spetsifikatsioone, mis on lihtsalt üks laam teksti lehekülg lehekülje järel.

Et kui juhtub A, siis kirje B peab liikuma asukohta C.

Välja arvatud juhul kui on täiskuuneljapäev, siis tuleb kirjest D lahutada 15% ja liigutada ta asukohta E

Siis tuleb meil veel liita kokku kirjed F ja G ning saata nad teise süsteemi.

Ja siis kaob kilpkonnaonu vee alla ja mullid tõusevad pinnale. Ja mullid teevad ai-tummer-ker-kommer-ker.

Ja esimese lehekülje lõpuks jäävad kõik lugejad magama.

Loen Tartu Ülikoolis sel kevadsemestril Neeme Vooluga kahasse Projektijuhtimise ainet. Pidasin just oma esimese loengu ja siin on ka materjalid.

Originaalslaidid saab leida siit.

Olin nii lahke, et tegin loengust ka audiosalvestuse. 1. osa 2. osa 3. osa 4. osa
Vahepeal unustasin diktofoni sisse vajutada, nii et osa jutust on ilmselt puudu. Tulge teinekord loengusse korralikult

Loeng põhines osaliselt ühel minu varasemal ettekandel, aga lisasin ja täiendasin oluliselt materjali.

Räägin teile kõigepealt ühe loo.

Juba antiikajal tegid inimesed vaatlusi ümbritsevate protsesside kohta.

Taignat sai muuta leivaks, savi tellisteks, puid söeks, rasva seebiks.

Mõistagi tekkis neil ka küsimus, et miks ei saaks näiteks raud muutuda kullaks?

Tuhanded alkeemikud nägid selle probleemi kallal sajandite jooksul vaeva. Kuna neil aga puudus arusaam sellest, millest erinevad ained ja materjalid tegelikult koosnevad ning kuidas nende omavaheline vastasmõju tegelikult töötab, ei saanud nende lähenemine ka kuigi süsteemne ja teaduslik olla.

Nad kuumutasid ja aurutasid, filtreerisid ja kondenseerisid, segasid kokku kõikvõimalikke aineid ning kirjeldasid oma tulemusi müstilises, allegoorilises keeles, et “asjasse pühendamata” inimesed millestki aru ei saaks.

Sagedased koostisosad olid näiteks väävel ja elavhõbe, usuti, et kui neid vaid õiges vahekorras lisada, saab nende abil kõike teha.

Ja alkeemikud kallasid ühest purgist väävlit ja teisest elavhõbedat ning laususid veel nõiasõnu peale – habbada-habbada-habbada.

Inimestel on siiski süüa ka vaja ja alkeemikud pakkusid tihti oma teenuseid kuningatele ja vürstidele, et viimased nende eksperimente rahastaks.

Ahnusel on suured silmad ja seetõttu maksiski nii mõnigi võimukandja alkeemikule heldelt, vähemalt esialgu. Pikapeale sai kuninga kannatus muidugi otsa ja ta hakkas konkreetseid tulemusi nõudma.

Kui muidu enam ennast välja keerutada ei õnnestunud, läks nii mõnigi alkeemik lõpuks võltsimise teed ning seadis üles demonstratsiooni, kus kullakangid olid algul näiteks tinaga kaetud, tina sulatati pealt ära ja nähtavale tuli kuld.

Kui nad aga sellega vahele jäid, oli karistus tavaliselt karm. Tihti rakendati sama karistust, mis valeraha tegijate puhul, ehk kallati õnnetule alkeemikule sulatina kurku.

Väga, väga ebameeldiv.

Aeg läks edasi. Matemaatikal oli tegelikult juba antiikajast saadik päris korralik ja range teaduslik põhi all olnud. Renessansi ajal tegi Galilei oma katseid, talle järgnesid Torricelli, Blaise Pascal ja Robert Hooke ja füüsika sai endale samasuguse range põhja.

Lõpuks jõudsid Robert Boyle, Lavoisier, Lomonossov ja Mendelejev ka keemiale range põhja loomiseni ja alkeemikute aeg oli lõppenud.

Sarnaselt juhtuvad revolutsioonid ka teistes teadustes, nad käivad alguses läbi oma “alkeemia faasi”, kus keegi täpselt ei tea, mida ta teeb. Vähehaaval saadakse asjad korda ja meil tekivad konkreetsed seadused, reeglid ja valemid.

Infotehnoloogia vallas käib tarkvaraprojektide juhtimise praktika käib praegu täpselt nagu alkeemia. Projektijuhid teavad, et tarkvara tegemiseks on vaja raha ja programmeerijatele meeldivad kohvijoogid. Ja nii nad lisavadki projektile erinevates vahekordades raha ning kofeiini, täpselt nagu vana aja alkeemikud lisasid erinevatele ainetele väävlit ja elavhõbedat. Ja siis lähevad kliendi juurde ja teevad kliendile habbada-habbada-habbada.

Ja nagu alkeemikute puhulgi, on üsna tõenäoline, et ilma teaduslikuma lähenemiseta lasete te üsna palju projekte kas põhja või viite kuidagi katse-eksituse teel lõpule.

Kui te seda piisavalt palju teete, siis lähevad teie projektiliikmed, ülemused ja kliendid samamoodi närvi nagu keskaegsed kuningad ja nendes tekib soov teid mingil väga ebameeldival viisil hukata.

Praeguse loengusarja eesmärk on teid sellest hullust saatusest päästa, ehk et keegi ei tuleks teile sulatinaga kallale.

See, et te kõik olete tulnud kuulama loengut projektijuhtimisest, ei tähenda veel, et te saate tingimata projektijuhiks, aga suure tõenäosusega hakkate te mitmesugustes tarkvaraprojektides mingis rollis osalema. Võib-olla tellija, võib-olla täitja poolel, vahest programmeerijana, vahest analüütikuna, vahest suure ülemusena.

Sellegipoolest, kuna projektijuhid on projektides kesksel kohal, puutute te nendega kindlasti kokku ja siis on väga hea, kui teil on olemas mingid praktilised nõuded, mida neilt projektijuhtidelt soovida ja kui nad sellega hakkama ei saa, siis saate ise esile astuda ja vajalikud asjad ära teha.

FBI näide: Projektiga tegelejad rajasid süsteemi lähtudes tavaliste kontoritöötajate kogemustest, inimestel on tööjaam, kohtvõrk, andmed jooksevad kõik andmebaasist jne. Ainult et FBI agendid ei ole tavalised kontoritöötajad, nad liiguvad “objektidel” ringi ja neil on vaja andmeid kaasa võtta ning ka offline’is sisestada. Ja keegi ei tulnud ka selle peale enne, kui süsteemi juurutama hakati. Kui palju võtab aega olemasolevale süsteemile turvaliste offline-võimaluste juurdepookimine, võib igaüks ise nuputada, kuid antud projekt katkestati (selle ja paljude, paljude muude probleemide tõttu) pärast 170 miljoni dollari maksumaksja raha kulutamist. Kui vajadused oleks tuvastatud õigeaegselt, oleks kogu süsteemi loodud hoopis teistel alustel ning tohutu hulk aega oleks jäänud raiskamata.

Projektijuhi roll on tihti arusaamatuste ja segaduse allikaks.

Juhtkonna stereotüüp: klient ja programmeerija ei tohi kokku saada, projektijuht kaitseb neid teineteise eest

Tehniku stereotüüp: projektijuht on mingi pintsaklipslane, kes tegelikult asjadest midagi ei tea ja keda asjadest eemal hoida

Olen ise kuulnud programmeerijat halvustavalt mainimas “projektijuhtide invasiooni Eesti tarkvaramaastikul”. Probleem jällegi selles, et kui näiteks programmeerija töö on ka praktikas viidud küllaltki teaduslikele alustele, siis projektijuhid on tihti endiselt alkeemikud. Tegelikult on ka projektijuhtidel olemas täiesti teaduslikud reeglid, kuidas üht projekti edukalt lõpuni viia, täpselt nagu meil on olemas reeglid selleks, kuidas võrrandisüsteemi lahendada.

Iga risk mõjutab potentsiaalselt meie lõpptähtaega.

Riskid on potentsiaalselt vahetatavad aja vastu – projektiplaani saab lisada aega riski maandamiseks.

Alternatiivina saame riskifaktori lahendada enne projekti algust.

 Lugege lihtsalt neid teste ja mõelge, mida teha, et teie projekt mõnesse sellisesse auku ei kukuks.

Teadmiste omandamisel 70:20:10 suhe: 70% töö käigus omandatav, 20% raamatute lugemine jm iseseisev töö, 10% formaalsed koolitused, sealhulgas praegu siin loengus istumine! Selleks, et reaalselt mõni projekt ära teha, läheb teil tarvis palju rohkem teadmisi, kui see praegune loengukursus teile anda suudab -> lugege kindlasti oluliselt juurde, kursuse kodulehel on soovitatavat lugemismaterjali.

Aga kui te kunagi peaks minuga koos mõnd projekti tegema ja seal projektijuhina tegutsema, siis ma kindlasti eeldan, et te olete Software Project Survival Guide’i või mõne muu ekvivalentse raamatu läbi lugenud, muidu ei võta ma teid tõsiselt.

Need siin on näited, mitte täielik nimistu!

Kes loeb Dilbertit? Lugege kindlasti, kasvõi selleks, et ise mitte samasuguseid jamasid korraldada.

Audiosalvestuse 1. osa lõpp.

Riske pole kunagi võimalik täielikult välistada, aga neid saab oluliselt maandada kasutades vastavaid “filtreid”.

 Kui kliendi ärilised eesmärgid jäävad täitmata, on nad lõpuks ikka õnnetud. Isegi kui teostaja oma raha kätte saab, võib projekti lugeda ebaõnnestunuks, kui keegi seda tegelikult kasutama ei hakka.

Loe lähemalt, Practical Project Initiation, lk 42-43

Huvide näiteid: juhtkond tahab suuremat käivet, andmesisestajad tahavad vähem käsitsitööd -> vähem vigu, müügiagendid tahavad kiiremat ligipääsu andmetele

Eelkujundatud suhtumiste näiteid: Andmesisestajad kardavad, et peavad mingitele uutele koolitustele minema, süsadminid arvavad, et ainult Solaris on õige asi

Võiduläve näiteid: Juhtkond tahab, et meie veebisait pakuks rohkem võimalusi kui konkurentide oma. Andmesisestajad tahavad automaatset veaparandust, andmebaasi administraatorid tahavad 3x suuremat andmebaasimahtu

Piirangute näiteid: juhtkonna eelarve on max 4 miljonit, andmesisestajatel on vanad arvutid ja uus kood peab nendel jooksma, samuti pole neil eelarves raha koolituseks

Sponsor on see, kelle käes on rahakott. Tema maksab nii reatöötaja laste leiva kui ka peadirektori Ferrari eest.

 Ma olen üsna kindel, et enamikul teist tuleb kunagi ühel või teisel viisil sellises situatsioonis olla.

 Nõuded tegelikult omaette pikk teema, sestap siin kaetud lühidalt.

 Millal me loeme projekti edukalt lõpetatuks?

 Aga kes loeb XKCD-d? Ma võtan teid oma kampa!

 Tuletame meelde seda 24 kuu vs 6 kuu juhtumit eespool.

ˇ

 Mida teha, kui sulle ikkagi survet avaldatakse, et asjad peavad saama kiiremini ära tehtud?

Audiosalvestuse 3. osa lõpp.

Enne, kui me edasi läheme,. arutame, miks järgnevad asjad meile üldse vajalikud on.

Ebaproduktiivne tegevus = haigused, vanade vigade parandamine, koodi ümber kirjutamine aruanded, pausid jne.

Arvatakse, et protsess on ka samasugune ebaproduktiivne tegevus.

Millalgi tuleb protsess niikuinii lisada ja see hakkab palju rohkem aega võtma. Samuti hakkab rohkem aega kuluma muudele tegevustele, mis otseselt projekti edasi ei vii.

Protsess võtab alguses aega, aga hiljem saavad osalised asja käppa.

 Kommunikatsiooniplaani mõte on selles, et keegi ei unune ära ega teki situatsiooni, kus mitme kuu ärel teatatakse, et asjad ei kõlba kusagile ja tuleb ringi teha.

Näide: kui meil on olemas nõuete kogumise abivahend, siis see ei tähenda, et meil oleks äkitselt olemas ka adekvaatsed nõuded!

Nõuete saamiseks tuleb endiselt vaeva näha!

Aga kui te need asjad kõik ära teete, võib juhtuda, et teil õnnestub tõepoolest kulda teha.

Soovin edu.

Pidasin hiljuti Webmedias ettekande sellest, mida tuleks teha tarkvaraprojekti alguses, enne kui me tegelikult ridagi koodi kirjutame.

Panen oma materjalid siia ka, ehk on kellelegi abiks. PowerPointi formaadis slaidid on siin.

Pidasin neil päevil Webmedias ettekande antud teemal. Põhimõtteliselt olen sel teemal siin ka varem juttu teinud, aga arendasin teemat natuke edasi.

Originaalslaidid saab leida siit, aga edasi juba sisu ise, koos minu märkmetega, mis on ehk hajusamad/kaootilisemad, kui minu tekst tavaliselt

The basic tenets of OOP are abstractions, encapsulation, inheritance and polymorphism: Hopefully all of us know about them, and know when and how to use them. The main idea is that we don’t have to know what’s inside a component, we can swap them in and out, and do a bunch of other cool things.

Make no mistake about it, I think OOP is good, it makes us more productive, and it makes our code much more flexible, maintainable and extensible.However, it also has some inherent dangers: we see an API, it looks very safe and simple. We add 1 line of code that is using this API and introduce who knows what. Perhaps it adds 5 extra SQL queries? Or does some processing that doesn’t scale to our data?

Let’s look at a civil engineering analogy.

In civil engineering, there are whole courses and thick handbooks about the properties of different materials. Various grades of steel, stone, wood and so on. Engineers have to know their strength, density, elasticity, how much they expand and contract in heat, all kinds of things

Now imagine using “encapsulated” building blocks. You see the blocks, they are nice and shiny, and the salesman tells you they are super good and strong. But you have no idea what’s inside them, how they are made, how they behave in different kinds of weather or stress. The engineers would rightfully ask: are you crazy or what?

Unfortunately, software engineers are just like that. Application programmers don’t know what’s happening in their class libraries. Class library writers don’t know what’s happening in the operating system. Systems programmers don’t know what’s happening in the hardware. So you have all these layers of software that were created by people who don’t quite know how the other layers behave. It’s kind of a miracle that software ever works at all.

Let’s look at a classic problem. We have a database with a bunch of stuff. It’s very nicely in 3rd normal form.

In the application layer, we want to handle rather different kinds of data, we have the Rich Domain Model, lots of OO classes, objects, subclasses, methods, properties etc.

Many different frameworks have been invented that perform object-relational mapping between the database and the object-oriented classes. For example, here in Webmedia we use Nhibernate and other similar technologies. So you can do things like “give me all the orders of this customer” by writing “foreach Order in Customer.Orders”. The framework will perform the query for you, and life is good, right?

In reality, things are never simple. The generated queries are often more complex and data-heavy than we absolutely need. Also, it becomes super easy to introduce a bunch of extra queries and create humongous loads on the database.

Let’s look at a case study. This is the default homepage of SharePoint Portal 2003. There’s also SharePoint Portal 2007, which looks a little fancier, but this was the project where I personally worked on performance, that’s why it’s included.
Everything you see here is dynamic, the vertical navigation bars, actions on the left, stuff in the lists etc., people can add and edit the elements in all of these.

The data in the various lists, navigation structure etc is all stored in a SQL database.

This diagram is from more recent times, showing the architecture of MOSS 2007

The main point I want to illustrate here is that there’s the base product, Windows SharePoint Services, and lots of other product teams build their stuff on top of it, essentially doing custom SharePoint development, just like many independent SharePoint solution builders all over the world.

-SharePoint can be thought of as a special kind of object-relation mapper.

It stores everything in a database

Also exposes an object model that lets people query and manipulate different kinds of data (sites, lists, web parts, documents). The object model generates SQL calls, which perform the actual operations.

In order to perform any sort of interesting operation, say copy some documents from one list to another, people often have to call a bunch of small, simple APIs, but all of them tend to generate one sort of query or another

Throughout times, I’ve had to diagnose and profile various SharePoint installations, and there’s a common theme: The developer says, hey, everything works OK on my machine, and all I have is these simple operations, how can they be slow?

Under stress, application behaves erratically, oftentimes pages load very slowly

When looking at SQL, it’s common to see very high CPU/memory usage, and some individual queries look super slow in SQL profiler, but it’s inconsistent. Another thing that we see is tons and tons of queries bombarding SQL server many times per second. What really happens is that when SQL server gets a bunch of requests, it cannot service them all at once, relevant data will be locked more often, and other queries have to wait etc.

This situation is what I call the “Estonian Customs” (”Eesti Toll”) application model.

- Let me tell you a story about Estonian Customs

- As you might know, I recently moved from the United States to Estonia, and had to bring all my household stuff to the country. And I had to take some papers to Eesti Toll in order to prove that I had been living abroad and was now moving to Estonia and all this stuff is my stuff.

I’m using a moving company, and had a guy from the moving company to advise me on what paperwork to bring with me. He has been doing it for 20 years, and he has no idea of what kind of papers might be asked at any time.

So we go in with a big stack of all kinds of documents, the official goes through it, and then asks: but why don’t you have a paper that shows that your car was insured in the US? Um… Because I had no idea it was required? So I call my US insurance company and ask for the appropriate paper to be faxed over and send it to the customs. But then they ask for another paper. And a few days later they ask for another paper, which causes me to context switch all the time and stresses out myself and the whole system.

Now software applications that just keep querying for data are just like that as well. Whenever a new feature or a new step in some algorithm is added, we add some code that calls an API method, which usually translates into a query.

This results in a lot of chattiness, every web page load generates tens of queries against SQL, which can add up to a lot of stress in multiuser scenarios.

Also, it usually results in a lot of redundancy, as multiple API calls can often return overlapping data, or even exactly the same data.

Overall, we end up with a death by a thousand cuts – no single query is too bad, but at some point we will add the straw that breaks the camel’s back

Now sometimes this approach is OK. If we are simply prototyping, or we know that this particular piece of functionality will never ever have a high load on it, it will be fine. However, it’s also highly dangerous because as soon as someone changes the conditions by adding more users or lifting this functionality to a different area, things will fall apart very quickly.

-Now let’s come back to our SharePoint story – what did the SharePoint org decide to do?

Realizing the query issue, reducing the number of queries became sort of a holy grail

Every query was examined, and we looked into ways of eliminating them.

There are three basic approaches one can take here:

you can see if multiple queries can be combined into one, especially if the data is similar or overlapping

If you have multiple user interface components that consume the same data (for example, multiple web parts), they can issue a joint query, and consume data from the resulting dataset

And the simplest: cache as much data as you can. If the data that you are reading doesn’t actually change more than once a day or even once per hour, chances are that we can use a simple cache for it. Remember: if you ever need to optimize a query, the first question to ask is: do we need this query at all? Eliminating the query is the perfect optimization

Now obviously you need to think about the different invalidation algorithms etc – does your cache expire after a certain time, is it explicitly invalidated when data changes etc.

In the end, we had a sort of query police who had the right to ask difficult questions from everyone that introduced new database hits.

As an end result, SharePoint Portal Server 2003 had only 2 queries to render its homepage (this is the web page I was showing before). One for reading web part and list information (as this is something that can change in real time and thus cannot be cached – but it was all combined into one query), and one for checking if anything had changed in the navigation structure of the portal (if something had changed, the data would be reloaded, but in 99% of the cases it was just a very simple and cheap query).

In comparison, I have had to consult and troubleshoot many custom SharePoint installations where people have 20-30-40 queries to render a single page, and then they complain that SharePoint doesn’t scale.

Now the caveat here is that this can lead to the Doctor’s Office appliation model

-Whenever I used to go to a doctor in the United States, the procedure usually involved a lot of waiting.

-First, I have to wait in the registration line, they take my data

-then, I have to wait in the waiting room, together with a bunch of other people. Sometimes they have chairs for everybody, sometimes they do not (memory pressure!)

-Then somebody asks me to come in and sit down somewhere, and I wait again

-Then a nurse comes and takes my blood pressure, after which I wait again

Then I finally get to see a doctor

The symptoms here are:

The place is full of people, they are being shunted from one stop to another

At every stage, someone performs one little procedure with them

In software, the symptom is that we have built tons of little caches everywhere, which behave like the lines in a doctor’s office

In case of SharePoint Portal, we cached so much data that it created huge memory usage, which obviously wasn’t good

Data ise copied around from one place in memory to another a lot

Now this is much better than dealing with Eesti Toll, but not quite perfect

But in most cases, this will actually be fine, as long as you’re sensible about what kind of data you are caching

Also, due to the nature of software layering (and remember that our themes is “trap of OOP” – Object-Oriented programming makes it very tempting to create lots of layers), you can end up doing caching in all those different layers, and then you wonder what your process is doing with all these hundreds of megabytes of memory.

-Some of the approaches we took in the SharePoint applications to combat this:
-Cut out data transformations and data staging
-Created very highly optimized data paths for common operations. For example, everything is treated as a list in SharePoint, so built-in list rendering was made as fast as possible
-Essentially, we ended up translating the data directly from SQL to HTML, bypassing all of the object model layers.Obviously, there were downsides:
-Many of these codepaths became super complicated – they were efficient, but difficult to understand and maintain
-also, this approach does not work for custom development. If you are writing your own code on top of SharePoint, you are on your own, and have to do your own micro-optimizations.-But this is what I call the Hansabank application model

I recently had a very good experience doing my personal business in Hansabank.
Having just moved back to Estonia, I had to arrange a bunch of stuff, from my Teine Pensionisammas to getting new ATM cards.
The teller had all the relevant information about me, she was competent and technologically empowered to perform all the different procedures.

In software, this is the equivalent of processing all the relevant data in one place
There’s minimal data transfer between components, and data is not just copied from one place to another all the time

Obvious downside: this can get very complex and difficult to maintain, so save this approach for performance-critical areas

Try to think what stages and transformations your data has to go through
You have to pick your application model at the start of the project, as it’s extremely difficult to change afterwards. For example, I’ve seen projects that have been finished with the Eesti Toll model. They get deployed, and obviously the performance will be bad. And then they bring me in and ask for a quick solution how to fix the performance, and I have to tell them that guys, you actually have to rewrite tons of stuff about how you are handling your data.
-Remember also that 90% of performance problems are designed in, not coded in. People sometimes think that Oh, I will write this code, and if the performance is bad, I will optimize my code, and fix it – does not work this way!
Never assume any performance characteristics about any technology, any code that you have written, or any code that anybody else in your team has written. If you haven’t measured its performance, chances are it will be bad. So profile your code, see what is taking up the CPU, what is taking up the memory – knowledge is power.
Also, things usually get worse on their own. You can have a pretty well performing piece of code, but once a bunch of people have added bug fixes and extra features to it, it will usually get a lot slower because they are not thinking about it in a holistic manner. So profile early, and profile often.
And remember to think about all aspects of performance, CPU, memory, I/o, network. Your model choice can shift the bottleneck from one place to another, so you want to know where to invest the effort.

Finally, how to improve your understanding:
Investigate the components you are working with, read their source code if possible
If you don’t have the source, profile the components, examine their behavior
Do NOT become the engineer who built a skyscraper out of materials he did not understand (remember the picture on an earlier slide!)