Archive for February, 2008

Feb 25 2008

Programmeerija produktiivsus

Published by Targo under Programmeerijad, Põhialused

productivity.jpg 

- 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.

vending.jpg

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

 maslow.gif

“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

handsaw.jpg chainsaw.jpg 

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

sweatshop.jpg

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

knowledge.jpg

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

glass.jpg

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

freedom.jpg

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.

No responses yet

Feb 20 2008

Tarkvaratootmise põhiteoreem II

Published by Targo under Põhialused

(Vaata esimest osa siin.)
Kõigepealt veelkord tarkvaratootmise põhiteoreemi sõnastus:

Vea parandamise hind kasvab aja möödudes. 

houseofcards.jpg

  • Näide 5: Programmeerija Priit läheb kuuks ajaks puhkusele, aga klient nõuab, et programmi kohe-kohe paar muudatust tehtaks. Peeter teeb asja ära, annab üle, aga siis selgub, et mingid teised asjad on samal ajal katki läinud. Klient Kustav poetab mürgiseid märkusi, kus võrdleb programmeerijate tööd kaardimaja ehitamisega.
  • Metoodiline lahendus 1: Iga programmeerija kirjutab koos koodiga ka piisava hulga automatiseeritud unit teste, mis tagavad igas olukorras keerulisema funktsionaalsuse toimimise. Kui kellelgi teisel on vaja programmis parandusi ja muudatusi teha, kontrollib ta, kas unit testid endiselt töötavad, ja tal on võimalik viga kohe parandada. Testide kirjutamine võtab muidugi lisaaega, aga see tasub end peaaegu alati ära, eriti kui on tegemist pikema projektiga, mille kallal töötab palju inimesi. Unit testingust asjana iseeneses ja pikemate/suuremate projektidega seotud iseärasustest kirjutan kunagi hiljem veel pikemalt.
  • Metoodiline lahendus 2: ettevõte peaks koodi kirjutamisel kasutama ühtseid standardeid, mis võimaldavad inimestel üksteise koodi paremini mõista ja täiendada.

ratwheel.jpg

  • Näide 6: Kustavil on kombeks alatasa mitmesuguseid väikesi täiendusi nõutada. Priit korraldab asjad tavaliselt kiiresti ära ja annab asjad üle. Kustav ei ole aga sellegipoolest rahul, kord crashib üks vorm, kord teine, ja talle jääb üleüldiselt kehv tunne. Samuti kulub Priidu ajast 30% esialgsete paranduste tegemisele ning 70% paranduste järel parandamisele.
  • Metoodiline lahendus: defineerida hulk teste, mis kontrollivad programmi põhiomaduste korrektse töö. Erinevates organisatsioonides kutsutakse neid erinevalt, ma kasutan siin ja edaspidi nimetust Build Verification Test (BVT). Ilma BVT-de töötamiseta ei tee ükski programmeerija check-ini ja kliendile ei näe samuti kunagi midagi mis poleks sellest sõelast läbi käinud. BVT-de automatiseerimise korral on nende kasutamisele kuluv ajakulu mõõdetav minutites, tühine aeg võrreldes tühja töö ja vaimunärimisega, mis kaasneb paranduste parandustele paranduste tegemisega.
  • Näide 7: aastal 1999 kontrollisid tuhanded ettevõtted kogu maailmas paaniliselt oma infosüsteeme, et ennetada Y2K probleemi. Tihti oli tegu süsteemidega, mille esialgsed loojad olid ammu pensionil ja hallihabemelistele Cobolihäkkeritele maksti ränka raha lihtsalt koodi ülevaatamise eest. Kui vigu leiti, oli tihti tegemist olukorraga, kus kood jooksis juba tuhandetel arvutitel üle maailma ja paranduste installeerimine põhjustas kalleid tööseisakuid. Sellest, kas Y2K oli tegelikult probleem või ei, on palju vaieldud, aga lugu illustreerib hästi asjaolu, et viga (konkreetses süsteemis), mille parandamine oleks aastal 1976 võtnud tunni, võttis nüüd tuhandeid inimtunde.

Loo üldine moraal on see, et tarkvarategemise igas etapis peab toimuma kvaliteedikontroll, mis tuleb teha võimalikult kiiresti, siis kui inimestel on asjad veel korralikult meeles, dokumentatsioon pole kusagile ära kadunud ega moraalselt vananenud. Kvaliteedikontrollist läbi lipsanud vead (olgu nad siis vead kliendi soovides, spetsifikatsioonis, disainis, koodis või kasutajajuhendis) põhjustavad üldjuhul selle, et järgmise etapi töö on tehtud valesti ning tuleb uuesti teha, mis ei mõju enamasti kellegi tujule hästi.
Tegelikult kõik väga elementaarne jutt ja paljud ehk küsivad, miks ma sellele ruumi raiskan: ühelt poolt on põhiteoreemi teadvustamine vajalik selleks, et mõista teemasid, millest hiljem juttu tuleb, teiseks aga toimub tarkvaratööstuses selle epideeminiline eiramine.

Miks põhiteoreemi eiratakse? Tihti on asi selles, et inimesed ei tea, millised metoodikad eksisteerivad asjade paremini korraldamiseks. Kui nad teavad, on nad tihti liiga laisad selleks, et neid ellu viia (ja peavad hiljem mitu korda rohkem tööd tegema, kui põhiteoreemi tagajärgede likvideerimiseks läheb).
Pahatihti juhtub ka, et inimesed leiavad, et nende töö on nii hea, et mingit kvaliteedikontrolli pole vajagi. Mul on olnud õnn töötada koos mõnede maailma tasemel inseneridega ning peamine, mis nende tegevuses silma torkab, on see, et nad panevad tohutut rõhku kvaliteedi tagamisele ning otsivad alati võimalusi selleks, et keegi nende tööd üle saaks vaadata. Aga sellest tuleb ka juba kord eraldi teema.

Lisalugemiseks veel põhiteoreeme: http://en.wikipedia.org/wiki/Fundamental_theorem

2 responses so far

Feb 17 2008

Tarkvaratootmise põhiteoreem I

Published by Targo under Joostes Marss, Põhialused

bug_cost.jpg

Tarkvaratootmise põhiteoreem on ambitsioonikas pealkiri, aga tegemist on niivõrd fundamentaalse asjaoluga, et väiksemat nimetust pole ka mõtet kasutada. Pealegi, kui pokkeril võib oma põhiteoreem olla, olgu siis ka tarkvaral.
Sõnastus siis:

Vea parandamise hind kasvab aja möödudes.

Lihtne ja elementaarne, eks? Samas on praktiliselt kõik ebaõnnestunud tarkvaraprojektid võimalik taandada põhiteoreemi mingis vormis eiramisele ja enamik tarkvarametodoloogiaid tegelevad põhiteoreemi tagajärgede pehmendamisega.
Enamik tarkvaraga tegelejaid mõistab seaduspärasuse olemust intuitiivselt, kuid ei pruugi taibata selle täit ulatust. Näiteks programmeerija ei pruugi mõista, et juba analüüs ja disain, millel tema kood põhineb, on vigased ja nende parandamiseks tuleb suur osa koodist ümber kirjutada. Projektijuht ei taipa jällegi, et väga tähtis on värskelt kirjutatud koodile kohe ka mõned testid kirjutada, et vead saaksid parandatud, kui programmeerija peas kõik veel värskelt meeles on. Kasutajapoolsest mittetaipamisest saab juba eraldi artikli kirjutada :)

Sõna “maksumuse” definitsioonist: Tarkvara maksumuse all pean ma üldjuhul silmas inimtundide arvu, mis sellesse on pandud, olgu siis analüüsi, kodeerimise, parandamise, testimise või muuna. Efektiivne projektihaldamine minimiseerib seda tegelikku maksumust ja püüab ülesande lahendada minimaalse energiakuluga. See kehtib nii vaba kui ka kommertstarkvara puhul. Hind, mida tegelikult kliendilt küsitakse, on juba teine teema.

Kõige hullemad näited tarkvaratootmise põhiteoreemi eiramisest on enamasti seotud tellija vajaduste puuduliku tundmaõppimisega.

  • Näide 1: Kurikuulsamaid näiteid ebaõnnestunud tarkvaraprojektidest oli FBI Virtual Case File süsteem. 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.
  • Näide 2, natuke lähemalt: analüütik Albert (nimed ja muud konkreetsed faktid siin ja edaspidi muudetud, kuid põhinevad sellegipoolest tõestisündinud seikadel) Eesti tuntud tarkvarafirmast Joostes Marss vestles klient Kustaviga Hulkuvate Kasside Riiklikust Inspektsioonist, et luua infosüsteem kasside nummerdamiseks. Kustav oli igati asjalik ja pädev, rääkis, et on vaja seda ja seda, joonistas isegi tahvlile skeeme jne, aga Albert ei pannud mitte kõike juttu kirja, vaid eeldas, et oh, see on kõik lihtne, teeme ära. Projektijuht Joosep oli äsja lõpetanud majanduskooli ega tulnud selle peale, et Alberti tööd üle vaadata. Programmeerija Peeter aga, ilma konkreetse spetsifikatsioonita peale selle, et “see on kõik lihtne, tee ära”, oli aga teisel arvamusel lihtsusest ja loodu sarnases kliendi joonisega nagu raudteejaam lennujaamaga, pealtvaadates nagu sarnane, aga olemuselt midagi hoopis muud. Eesti riik on õnneks leplik ja asi tehti suurema pahanduseta ringi (ringitegemise kulu siis ka sarnane raudteejaama lennujaamaks ümber ehitamise kuluga). Parandamise hind oleks võinud olla mitu suurusjärku väiksem, kui analüütiku viga oleks korraliku projektijuhtimise poolt kinni püütud ja Albert kliendi juurde tagasi saadetud korralikke märkmeid tegema enne, kui Peeter ridagi koodi oleks jõudnud kirjutada.
  • Metoodiline lahendus mõlema näite puhul: spetsifikatsioonide ülevaatamine, milles osalevad nii kliendi- kui ka tööettevõtjapoolsed projektijuhid, lõppkasutaja ja tehniliste teostajate esindajad.

Muidugi pole analüütikud ainsad, kes vigu teevad, programmeerijate elus võib pisikesi näiteid põhiteoreemi rakendamisest leida igal sammul:

  • Näide 3: Peeter kirjutas just uue protseduuri ja vajutas nuppu Compile. Samal ajal küsis teine programmeerija, Priit, temalt, mis vahe on SendMessage‘il ja PostMessage‘il. Seletuse lõpetanud, leidis Peeter, et kompilaator oli leidnud tema koodist kolm viga, kuid kuna värskelt kirjutatud kood oli Peetri lühiajalisest mälust välja uhutud, kulus tal lisaks veel kümme minutit, et meelde tuletada, mida ta ennist oli tegemas ja vead parandada. Näide on eelmistega võrreldes mikroskoopiline, aga kui selliseid väikesi segajaid, mis takistavad programmeerijal vigade kohest parandamist, tuleb päevas ette palju, kahaneb tema produktiivsus mitukümmend protsenti.
  • Metoodiline lahendus: töökeskkond, kus programmeerijal on võimalik vaikselt keskenduda, ja töökultuur, kus inimestel on kombeks lihtsatele küsimustele ise kiirelt MSDNist vastuseid leida.

mad-dog.gif persiankitty.jpg

  • Näide 4: Priit leiab, et tema kirjutatav uus hulkuvate kasside andmebaasipäring teeb enamvähem sedasama, mis hulkuvate koerte päring, ja teeb kiire copy/paste. Päring on aga keeruline ja ühes kohas jääb “koer” kogemata “kassiga” asendamata, tekitades olukorra, kus varjupaigas pannakse marutaudis rotveiler Raudhamba asemel magama hoopis pärsia kass Viktooria, kellele omanik järgmisel päeval järele pidi tulema. Lisaks tarkvaraparandusega seotud kulule oleme jõudnud kahjudeni muudes valdkondades.
  • Metoodiline lahendus: iga rida koodi vaadatakse kellegi teise poolt üle. Tihti juhtub, et kui inimene vaatab omaenda kirjutatud teksti, libiseb ta detailidest alateadlikult üle, aga teisele inimesele torkab kohe silma, kuhu koer on maetud. Koodiülevaatusele kulunud aeg: 30 minutit, vea parandamisele kulunud aeg: 3 minutit. Vea parandusele ja kliendi juures paigaldamisele kulunud aeg, kui ülevaatust ei toimunud: mitu inimpäeva, halvemal juhul veel palju rohkemgi, pluss kohtukulud. (Loomulikult on ka vahepealsed võimalused, kus viga tuleb testimises välja, aga ka siis on testimise+vea raporteerimise+diagnoosimise+parandamise kulu kõvasti suurem kui esialgne 33 minutit.)

(järgneb)

One response so far

Feb 14 2008

Sissejuhatuseks

Published by Targo under Isiklik

photo109894-full.jpgMinu nimi on Targo Tennisberg, alates 1991. aastast tegelenud tarkvaraloomisega ning alates 1996. aastast sellega ka endale leiba teeninud, algul 100% programeerijana, hiljem ka teisi inimesi juhendades/juhtides.

Alates 1999. aastast kuni tänaseni (2008 veebruar) olen töötanud Microsoft Corporationis, praeguse ametinimetusega Senior Development Lead, ja juhin siin üht arendajate tiimi. Nüüd aga paistab, et olen kodumaale tagasi pöördumas ning kuna pesnionile minna on veel vara, töötan edaspidi juba koos Eesti tarkvarainimestega.

Siia kavatsen kirjutada oma mõtteid tarkvarast nii konkreetselt kui ka üldiselt, kes seda teevad, kuidas tarkvara valmib, mida selle juures silmas pidada jne, nii isiklikust kui ka targemate inimeste kogemusest lähtudes. Absoluutse tõe monopoli hetkel veel ei evi ja kutsun kõiki huvitatuid kaasa rääkima ning soovi korral ka vastu vaidlema.

3 responses so far