Šampionsko vođenje projekta
Šampionsko programiranje

DAMP fact sheet

DAMP je bila glavna aplikacija firme, trkaći konj u kojeg se najviše ulagalo i od kojeg je gazda Dodoni očekivao najveću zaradu. Trebala je to biti "light" verzija MS Projecta posebno prilagođena Dembelijskom tržištu. Erich bi često običavao reći da je većini klijenata MS Project prekompliciran i da se ne snalaze u gomili njegovih mogućnosti pa da im treba ponuditi nešto jednostavnije a što će ipak pokriti sve njihove zahtjeve.

Prvu verziju DAMP-a je naručila jedna velika Dembelijska firma i kad je Bojan došao u Dodoni, klijent je već naveliko koristio aplikaciju. Iz priča kolega moglo se naslutiti da je DAMP ustvari bio razlog zašto je Dodoni zaposlio nove ljude i počeo rasti. Prije DAMP-a u Dodoniju su radili samo Žakro, Patrik i Maddog kao stalni zaposlenici. Bio je to prvi veliki, pravi i ozbiljni projekt od kojeg se puno očekivalo.

Očekivanja su jedno a realnost drugo

Na Erichovu nesreću, velika očekivanja i optimizam nisu dovoljna da neki projekt uspije. Koliko god se on zavaravao i ulagao novac u razvoj tog čuda, DAMP je bio promašaj koji nije imao šanse da postane uspješan i profitabilan projekt iz najmanje nekoliko razloga.

Šampionsko vođenje projekta

Kao prvo, voditelj projekta je bio Žakro. I dok se za neke ljude može reći da sve što taknu pretvaraju u zlato, kod Žakra i vođenja projekata je bilo upravo obrnuto. Na DAMP-u su došle do izražaja sve njegove project managerske "vrline":

• Loša i površna analiza zahtjeva u duhu krilatice "Klijentu treba čitati misli, sramota je pitati a junaštvo pretpostavljati."
  Ako na kraju nastane hrpa koda kojeg treba baciti i pisati iznova, nema veze, teret će snositi programeri. U većini slučajeva se analiza zahtjeva svodila na prijevod originalnog klijentovog dokumenta s Dembelijskog na hrvatski i onda iščitavanje i pogađanje što klijent ustvari želi. Ako je klijent bio tehnički potkovan i smisleno sročio svoje želje, još je postojala i neka šansa da konačna aplikacija bar malo ocrtava njegove zahtjeve. Međutim, kako većina klijenata nije takva, već u dosta slučajeva i ne zna što želi, konačni produkt je znao biti nešto što nije imalo veze sa poslovnim potrebama klijenata. Nisu bili rijetki Dodonijevi projekti koji su kod prvog predstavljanja klijentu izazivali komentare: "Pa to uopće nije ono što smo tražili!" Naravno, nepotrebno je i reći da je u svima njima analizu zahtjeva radio Žakro.
   
• Potpuno neznanje planiranja softverskog projekta.
  Žakro se nije mučio s njemu nepotrebnim aktivnostima koje bi logično trebale uslijediti nakon analize zahtjeva kao što su npr. pisanje funkcionalne specifikacije, verifikacija specifikacije od strane klijenta, pisanje projektnog plana s detaljnim aktivnostima i inicijalnom procjenom vremena, pisanje dokumenta s opisom arhitekture i sl. On bi, kad bi mislio da je shvatio bar ugrubo što klijent zahtijeva, jednostavno pozvao glavnog developera buduće aplikacije (u slučaju DAMP-a, Stinkya) u malu sobicu za sastanke i onda bi njih dvojica razglabali što treba napraviti. Rezultat tog razgovora ne bi bio nikakav dokument ili ne daj bože prototip aplikacije, već bi ubrzo nakon toga počela produkcija koda. Ružnog, prljavog, zlog, Visual Basic spaghetti koda.
   
• Nerealno procjenjivanje vremena potrebnog za izradu aplikacije.
  Najgora posljedica Žakrovih i Stinkyevih sastanaka u maloj sobici je bila što su oni iz nje izašli sa gotovom procjenom vremena i konačnim datumima isporuke koje su onda komunicirali Erichu. Naravno da je procijenjeno vrijeme izrade bilo smiješno malo i da u njega nisu bili uračunati planiranje, dizajn, debug, testiranje, code review, kontrola kvalitete i izrada instalacije, već samo i isključivo kodiranje. Da stvar bude još gora, kada su došli do faze da izračunato vrijeme podijele na ljude, onda bi Žakro primijenio čuvenu metodu "Koliko Kineza toliko zida" pa bi kalkulirao: "Imamo 100 čovjek dana, trojicu programera, znači to je za 33 dana gotovo!" Iz toga bi izračunali deadline za isporuku kojeg bi Erich shvatio kao sveto pismo i kao takvo ga javio klijentu.
  Za prvu verziju DAMP-a koja je isporučena još prije Bojanovog dolaska, Žakro je često znao govoriti da je imala totalno nerealni datum isporuke ali za to je prenio odgovornost na Ericha, koji je zadao čvrsti datum i od njega nije odustajao. Taj prvobitni nerealni datum mu je uvijek služio kao izlika zašto je DAMP kodiran zbrda zdola i zašto nema nikakve dokumentacije. "Dobili smo rok za koji smo znali da ga ne možemo stići ali smo dali sve od sebe i na kraju smo postigli više nego što smo očekivali" samozadovoljno je znao govoriti Žakro o stvaranju prve verzije DAMP-a. Da, postigli ste to da ste stvorili čudovište koje bi trebalo zaklati i pisati sve ispočetka, mislio je u sebi Bojan kad je slušao te tirade.
   
• Nedostatak bilo kakvog praćenja napretka i trenutnog stanja projekta kao i kontrole koda.
  Kada bi netko došao u Dodoni sedam dana prije važnog datuma isporuke, ne bi po ničem zaključio da se sprema nešto takvo. Neki bi programirali, neki surfali, Stinky bi se dopisivao preko ICQ-a, Maddog bi surfao i glasno komentirao, Žakro bi se pretvarao da piše dokumente i svi bi se pokupili doma u 4. Kao da je sve u najboljem redu i da se sve stiže.
  Naravno da je u većini slučajeva bilo obrnuto i da je projekt debelo kasnio, ali ni Žakro ni Stinky si to nisu htjeli priznati. Čak i ako su naslutili da im vrijeme izmiče, oni bi se zavaravali da će kao nekim čudom u zadnjih par dana sve stići i da će sve biti u redu. Tipična kontrola napretka je u Dodoniju izgledala ovako – Žakro bi sazvao sastanak svih developera i onda svakog pitao koliko je napravljeno i koliko još ima posla. Svi redom od Stinkya do Rudija bi rekli da samo što nije gotovo, ma 90% posla je napravljeno i sad treba još samo neke sitnice napraviti i to je to. Žakro naravno ne bi provjeravao je li to istina jer se vjerojatno bojao da bi otkrio da posla ima puno više i da se neće sve stići pa mu je bilo lakše zavaravati se. Onda bi svi sretni i zadovoljni i puni optimizma otišli sa sastanka i nastavili dalje vrijedno i marljivo pretvarati se da rade.
  I tako je bilo do zadnjeg dana prije roka kad se, o užasa, shvatilo da kod uopće nije gotov, da je pun bugova, da se aplikacija ruši i da ni teoretski više nije moguće klijentu isporučiti upotrebljivu verziju proizvoda. Tada bi se prišlo krpanjima, ušlo bi se u beskonačnu code-debug-test spiralu i kada bi Žakru prvi put sve proradilo, napravio bi setup i slao u Dembeliju. To bi se obično događalo u petak popodne, u zadnji tren. U ponedjeljak ujutro bi počeli ljuti i uzbuđeni pozivi od gazde Dodonija da klijent javlja da aplikacija ne radi i e-mailom bi došla bug lista. Vješti demagog i političar Žakro bi tad uvjeravao Ericha da su on i klijent u krivu i da većina bugova uopće nisu tako strašni, da ima par sitnica, ali da je većina stvari napravljena i da se sve stiglo. Što je najgore, uvijek bi na kraju uspio uvjeriti sugovornika da nema razloga za paniku i život bi dalje tekao normalnim tokom, bugovi bi se ispravili, gazda bi se kod klijenta malo brukao, stvoreni bi bili novi bugovi koji bi čekali sljedeći release i sve bi opet bilo po starom, do sljedeće isporuke.
  • Neučenje na greškama i nedostatak bilo kakve realne post-mortem analize projekta
  Tipično za Žakra kao i za njegovu desnu ruku Stinkya je bilo da nisu učili na greškama. Zašto? Pa jednostavno zato što oni nisu priznavali da griješe. Pametnom čovjeku bi bila dosta jedna loša procjena vremena i datuma isporuke da odluči da si to više ne može dozvoliti i da drugi puta treba pomnije planirati i češće pratiti napredak projekta. Međutim, njih dvojica su uvijek nanovo ponavljali iste greške. Glavni razlog za to je što jednostavno nisu imali dovoljno znanja i stručnosti da bi mogli raditi drugačije i kvalitetnije, ali su nažalost imali položaj i moć da odlučuju da će sve biti po njihovom. Bilo je upravo groteskno gledati njihovo samozadovoljstvo kada bi neki projekt bio isporučen. Umjesto da se stide što su klijentu poslali smeće puno bugova, što su tjerali ljude da rade u nerealnim rokovima, pod stresom a nekad i prekovremeno i vikendom, što su kršili sva dobra pravila vođenja projekta i programiranja, oni bi mislili da su izvojevali herojski pothvat, da su genijalci, zvali bi na piće, čestitali si, smješkali se od uha do uha. Na sastancima po završetku neke faze projekta sve je vrvilo od samohvala i optimizma, o greškama i krivim procjenama se jednostavno nije smjelo govoriti, tko je pokušao pokrenuti takvu raspravu bio bi odmah optužen da je pesimist, da sve gleda crno, da se ne raduje uspjehu tima, potcjenjivali bi njegovo znanje i stručnost, ukazivali bi samo na njegove greške itd. U toj ulozi se u početku najčešće nalazio Bartol, ali ni Bojan nije bio pošteđen njihovih napada.

Šampionsko programiranje

Drugi razlog neuspjeha DAMP-a, osim što ga je vodio nekompetentni project manager, je bio taj što većina ljudi koji su ga programirali nisu imali dovoljno znanja i iskustva da bi stvarali ozbiljnu poslovnu aplikaciju. Da stvar bude gora, oni to nisu ni shvaćali.

• Monolitna arhitektura
  Prvu verziju DAMP-a su stvarali Patrik, Maddog i vanjski suradnik Dražen pod budnim Žakrovim okom. Bojan nije nikad saznao tko je od njih najodgovorniji za "istočni grijeh" DAMP-a, monolitnu arhitekturu kod koje je sav kod zbijen u VB forme, preciznije u event procedure. Bilo je nešto malo modula, pokoja klasa ali 90% koda je bilo u formama. Patrik i Dražen nisu bili izgubljeni slučaj kao Maddog, dapače djelovali su kao ljudi koji znaju programirati i koji bi bili u stanju napraviti bolju arhitekturu ali ostaje misterija zašto su krenuli lakšim putem. Da li je Žakro inzistirao na takvoj jednostavnoj i prljavoj arhitekturi jer je nju jedino shvaćao? Da li ih je prisilio da tako rade jer je rok bio kratak pa se išlo na "quick and dirty"? Sva ta pitanja su Bojanu ostala bez odgovora jer nitko nije rado pričao o prvim danima DAMP-a, kao da su se svi stidjeli tih vremena, nešto kao vojnici koji su u ratu činili zločine pa ih muči savjest i ne vole kad ih pitaš o tome.
   
• Pristup bazi po principu "kako mi se digne"
  Monolitna arhitektura u DAMP-u nije bila jedini grijeh te aplikacije. Još veći kaos i neznanje su vladali u području komunikacije s bazom podataka. Kad je Bartol došao u firmu kao database developer i prvi puta pogledao bazu DAMP-a na SQL serveru, postavio je jednostavno pitanje: "A gdje su vam triggeri i stored procedure?" Dobio je samo začuđene poglede, u stilu: "A što je to?" Ljudi su se vjerojatno naučili raditi u Clipperu i Accessu i nisu se trudili previše shvatiti što je SQL server i kakve naprednije mogućnosti nudi u odnosu na baze njihove mladosti. Od mnogih grijeha u radu s bazom spomenimo samo najveće:
   
  • VB kod je bio preplavljen hardkodiranim SQL queryima koji su bili raštrkani po event procedurama formi.
  • DAMP je na početku svog rada otvarao connection prema bazi i držao ga otvorenog do kraja rada aplikacije keširanog u globalnoj varijabli.
  • Kod otvaranja recordseta se uglavnom koristio server-side cursor tipa Keyset koji je Janus GridEx jedini mogao učitati. Disconnected recordset je bio nepoznanica a unbound grid svetogrđe.
  • Parametri recordseta su se koristili nekonzistentno, bez razmišljanja o posljedicama, kako se autoru koda u tom trenutku svidjelo i nitko se nije trudio da se situacija unificira i sredi. Tako je negdje bio keyset, negdje dynamic kursor, negdje se koristio optimistic locking, negdje pessimistic itd.
    Kasnije je Bartol sredio bazu, uveo triggere i probao nagovoriti VB šampione da migriraju querye iz koda u stored procedure ali to je išlo jako sporo tako da je još dugo DAMP imao sve gornje pobrojane grijehe.
     
• Konzistentnost i code convention - zabranjeni pojmovi.
  DAMP nije imao nikakav code convention tako da je svaki autor unosio u kod svoj rukopis. Jedini zajednički convention svim autorima je bio "programirati brzo, prljavo, koristiti copy-paste metodu i ni u kojem slučaju ne komentirati kod".
  Također, nije se nikad diskutiralo o načinu implementacije pojedinih dijelova tako da je svatko mogao napraviti rješenje kako mu se prohtjelo. To je pružalo ljudima neograničene mogućnosti eksperimentiranja i DAMP je bio školski primjer nekonzistentne aplikacije. Što je najgore, ta nekonzistentnost nije postojala samo interno u kodu već i u samom korisničkom sučelju. Tako su neke forme imale buttone na lijevoj strani, neke na desnoj, neke su imale navigacijske recordset buttone, neke ne, neke su bile modalne, neke ne i tako unedogled. Na to je najčešće ukazivao Bartol ali je u većini slučajeva bio napadan i ismijan od Žakra i Stinkya.
  Kao i u vanjskom sučelju, DAMP je i interno vrvio od šarolikih i maštovitih rješenja koja su očito bila rezultat autorovog učenja Visual Basica i programiranja uopće. Imao je DAMP i ocx kontrolu za pretraživanje, izdvojeni dll za aktiviranje stavki menija i toolbarova ovisno o korisnikovim pravima, na nekim formama su se koristile MS Forms 2.0 kontrole a na drugim obične VB kontrole itd. Kada bi se source DAMP-a otvorio u VB razvojnoj okolini, toolbox sa referenciranim kontrolama bi zauzeo cijeli ekran po visini. Također, ako bi se pogledali svi vanjski dll-ovi na koje se referencirao projekt, čovjek bi se mogao samo uhvatiti za glavu. Neke od tih kontrola i referenci se možda više i nisu koristile, ali nitko se nije trudio počistiti smeće. Valjda je svakom bilo jasno da bi jedino smisleno čišćenje bilo obrisati sav DAMP kod i početi sve ispočetka.