Šampionski proces rada bio je prvenstveno određen temeljnim zahtjevom gazde Dodonija i njegovog namjesnika Žakra na svaki projekt, a koji je glasio: "Napravite to što brže moguće, sve ostalo nije bitno."

Analiza zahtjeva - igra pokvarenog telefona počinje

Ova početna faza koja bi po svakoj logici trebala biti temeljita i precizna i bez koje nema smisla ići u dalje faze projekta, u šampionima je shvaćana kao nužno zlo koje treba što prije obaviti i onda ići kodirati.  Glavni junaci ove faze bili su Žakro i Erich jer su u većini projekata jedino oni dolazili u dodir s klijentom. Preciznije, Erich bi osobno komunicirao s klijentom dok bi Žakro u većini slučajeva to radio e-mailom ili telefonom na svom osebujnom engleskom ("Hello, Mr. Miller, nice to meet you ON the phone", jedan od citata).

Tijek gubljenja informacije u tom kanalu može se najbolje opisati ovako:

• Erich sluša klijentove zahtjeve. Pritom Erich ne pozna tehnologiju niti mogućnosti kako bi se konkretni problem mogao riješiti niti moguće alternative. On samo zna da u Zagrebu ima tim šampiona koji će ispuniti sve, pa i najperverznije želje, pa što koštalo da koštalo.
• 10-20% informacija se gubi jer Erich ne shvaća sve zahtjeve ali ne pita ponovno jer šampionski analitičar sve skuži iz prve. Pitati je sramota.
• Ako Erich zatim telefonira Žakru i objašnjava mu zahtjeve klijenta, novih 20-40% informacija se gubi jer Žakro ne shvaća sve zahtjeve ali ne traži od Ericha da pita klijenta jer je to sramota.
• Druga varijanta je da Erich, umjesto telefonskog seksa sa Žakrom, pošalje klijentove zahtjeve u dokumentu na dembelijskom jeziku. Tada se odmah 20% informacija gubi jer prevoditeljica ne vlada dembelijskim tehničkim terminima. Daljnjih 20% se gubi jer Žakro ne shvaća zahtjeve ali ne pita Ericha jer se boji.
• Ono malo točnih informacija što je preostalo, Žakro deformira do krajnosti kada pokuša objasniti developerima što treba raditi i što ustvari klijent hoće. Šum na kanalu se dodatno pojačava ako i Erich paralelno komunicira s developerima.

Rezultat takve briljantne analize su najčešće Žakrovi nemušti dokumenti i potpuno odsustvo bilo kakve funkcionalne specifikacije po kojoj bi razvojni tim točno znao što treba napraviti i na temelju koje bi mogao krenuti u sljedeću fazu projekta.

Još gora posljedica takve anti-analize su bile procjene vremena i okvirni datumi isporuke koji nisu imali nikakve veze sa stvarnošću već ih je Žakro sipao iz rukava vodeći se glavnim motom: "Bitno je da je Erich zadovoljan i da ga uvjerimo da ćemo to napraviti tako brzo." Nekad bi Žakro kod procjena pozvao u pomoć Stinkya ali za ovog se sve dalo napraviti u "tri linije koda" pa on sigurno nije mogao spriječiti sulude procjene i rokove. Drugi koji su možda bili realniji ili konzervativniji u procjenama vremena nisu bili konzultirani u toj raboti. 

Planiranje - čemu to služi?

Dok bi nešampioni inzistirali da se nakon stabiliziranja funkcionalne specifikacije definira i dokumentira arhitektura rješenja i dizajn aplikacije, pravi šampion bi to naravno s gnušanjem odbio i odmah krenuo na kodiranje. Šampionsko planiranje je kao i cijeli proces bilo određeno temeljnim motom: "Napraviti što brže kod. Sve ostalo je samo gubitak vremena."

Šampioni su ovu fazu brzo obavili i to u svojoj glavi, bez ikakve dokumentacije. Evo kako je to izgledalo po segmentima (vi koji radite po nekakvim pravilima i standardima, budite ljubomorni što se toga niste sjetili)

• Arhitektura? Uzet ćemo kostur prijašnje aplikacije, iskopirati cijeli kod, promijeniti što je novo i to je to. Monolit i copy-paste metoda. Razmišljati o nekom novom, boljem rješenju? Neeeee. Nema vremena. Klijent već čeka prvu verziju koju mu je Erich podatno obećao.
• Konvencije kodiranja? Svatko neka radi kako najbolje zna, po mogućnosti neka kopira Stinkya. Ili Maddoga. Pa ima li ljepšeg i razumljivijeg nazivanja varijabli od x, xx, xxx?
• Rizici? Nema rizika, MI SMO ŠAMPIONI. Sve ćemo da rešimo.
• Procjena vremena? Zadan je fiksni datum isporuke uz mogućnost da se funkcionalnosti samo povećaju. Ni u ludilu smanjivati funkcionalnosti nauštrb kvalitete. Što isporučene funkcionalnosti uopće ne rade, koga briga?
• Design specifikacija? Svaki šampion ima potpunu umjetničku slobodu u dizajniranju ekrana ili formi. On slobodnom voljom odlučuje da li će forma imati toolbar ili ne, ili da li će buttoni biti na desnoj ili na lijevoj strani. Jedino se kod ikona mora paziti da se zadovolji Žakrov ukus, čovjek je imao upravo perverznu potrebu za ikonama, funkcionalnost je mogla biti potpuno pogrešna, ali morala je postojati ikona.

Kodiranje - "ctrl-c" sim, "ctrl-v" tam

Šampionsko produciranje hrpe bugova koje bi netko uz dosta mašte nazvao razvoj softvera karakterizirali su sljedeći bitni elementi:

• Masovna primjena copy-paste metode. Dijelovi koda iz starih aplikacija su se jednostavno kopirali i prilagođavali bez ikakve kritičke analize ili pokušaja popravljanja. Za to jednostavno "nije bilo vremena".
• Izbjegavanje bilo kakvih gotovih algoritama i design patterna
• Šampionska originalnost - ako kojim slučajem nešto nije bilo moguće iskopirati iz starog koda, onda bi svatko po svom nahođenju i inspiraciji izmislio svoj algoritam za neki problem. Tako su nastajali Stinkyeva for-petljica, Rudijeva tree univerzalna klasa i error handler i sl. o kojima ste mogli čitati u pričama o njihovim autorima.
• Odsustvo bilo kakvog dijeljenja koda ili stvaranja biblioteke zajedničkih klasa ili funkcija. Iako su koristili Source safe, šampioni su s gnušanjem odbijali koristiti njegovu Share funkciju gdje se isti fajl dijeli među više projekata. Svaki šampionski projekt je imao svoj skup univerzalnih funkcija koje su napadno sličile jedna drugoj i koje su naravno nastale kopiranjem iz jednog projekta u drugi. Naknadna promjena neke od tih funkcija bi se naravno trebala provesti zasebno u svim projektima, ako bi se to nekome dalo.
• Nedostatak code reviewa i ostalih postupaka povećanja kvalitete. U šampionima nitko nikad nije revidirao tuđi kod ili pokušavao promijeniti loše običaje kodiranja da bi se povećala kvaliteta i smanjio broj bugova. Dapače, ako bi netko to i pokušao, izazvao bi gnjev onog tko je isproducirao smeće jer nitko ne smije dovesti u pitanje znanje šampionskog božanstva, ta šampioni sve znaju i nikada ne griješe. Žakro kao šef koji je jedini mogao to napraviti nije to ni znao niti mu se dalo raditi, uostalom jedino važno je bilo da se kod napravi i kako-tako radi. To što takvo smeće može samo izazvati želučane smetnje u onoga tko ga bude jednom održavao i ubiti svaku volju i motiv za rad, o tome se nije razmišljalo.

Istini za volju, treba priznati da se nakon Stinkyevog odlaska iz firme puno više pažnje počelo posvećivati kvaliteti koda, čak se u nekim projektima koje su vodili Bojan ili Bartol pokušalo primijeniti i 3-tier arhitekturu i voditi redovna praćenja koda, ali se pod pritiskom rokova i šampionskog znanja brzo od toga odustalo. Naime, nesretni bi voditelj projekta ubrzo shvatio da će, ako bude ustrajao na reviewima i provjeri kvalitete, skoro cijelo radno vrijeme potrošiti na objašnjavanje Stinkyevim učenicima Rudiju i Maddogu zašto nešto ne valja i kako to napraviti bolje. Kad bi vidio da ga oni uopće ne slušaju i rade po svom, mogao bi birati između dvije opcije: obrisati njihovo smeće i sam napisati sve iznova, uz sve regularne poslove, ili odustati od praćenja kvalitete. S obzirom da nitko nije bio lud da u šampionima provodi cijele dane i noći koji nikad neće biti plaćeni, kvaliteta je prva žrtvovana na oltar šampionizma. Kao mnogo puta dotad.

Testiranje i isporuka

Način šampionskog testiranja i isporuke ukratko je opisan u šampionskom manifestu. Gotovo svi Dodonijevi projekti, od vodećeg Dampa pa do manjih, slijedili su predvidljivi uzorak koji se može sažeti u nekoliko natuknica:

• Kod ne testira nitko osim programera koji ga je radio i eventualno Žakra
• Ako neki drugi developer uoči neki bug, to se ignorira, osim ako Žakro eksplicitno naredi da se bug ispravi. Čak štoviše, onaj tko je pronašao bug dobiva ljute poglede i mržnju šampiona koji je bug napravio uz komentare: "Ma nije moguće, daj još jednom pogledaj, kod mene radi!"
• Ne postoje test cases tj. testira se kaotično i prema individualnoj inspiraciji. Budući da ne postoji funkcionalna specifikacija, nitko tko nije radio na projektu ne zna ni kako bi ni što testirao
• Evidencija bugova se ne vodi kroz neki prikladni alat kao npr. Bug collector već isključivo kroz nepismene Word dokumente koje je favorizirao Žakro. Iako se većina developera zapalila za Bug collector kojeg je pokušavao uvesti Bojan, Žakro je neprestano minirao službeno uvođenje tog alata uz labavu ispriku da onda on mora duplo pisati jer ne može klijentu poslati report iz bug collectora već mora prepisivati u Word. Naravno, pravio se da ne zna da dotični alat ima sasvim solidni reporting.
• U planovima se nikad ne rezervira vrijeme za integracijsko testiranje jer se pretpostavlja da ako svakom šampionu radi njegov dio na njegovom stroju, onda će kad se svi dijelovi ujedine, sve isprve proraditi. Ta šampioni ne greše!
• Testira se obično sat vremena prije isporuke, u petak popodne i to tako da se napravi setup i pokuša instalirati na testnom stroju. Ako se aplikacija uspješno instalira, onda Žakro prođe par minuta kroz najvažnije ekrane i ako se ništa ne sruši, proglašava se spremnim za isporuku i šalje se klijentu ili Erichu mailom. Ako nešto kod setupa fali, onda Stinky otvori setup.lst u notepadu i ručno promijeni i izhakerira ono što je potrebno dok stvar ne proradi. Nakon što pošalju instalaciju u Dembeliju, svi se rasprše doma i čekaju ponedjeljak da dođe bug lista. I tako ponovo u novi ciklus.     

Post-mortem analiza projekta

Ova faza u normalnoj organizaciji služi učenju na greškama i diskusiji na koji način poboljšati određene segmente rada da se te greške ne bi ponavljale. U šampionskoj organizaciji se ova faza smatra herezom, osim ako se ne svede na neumjerenu samohvalu, busanje o prsa i parole tipa: "super smo to napravili, svi smo šampioni, ajmo dalje". S obzirom da zbog kvalitete svog rada ni uz najbolju volju šampioni nisu mogli izgovarati takve fraze i da je većina projekata kasnila i bila aljkavo izvedena, njihova analiza je uz prešutno odobravanje većine šampiona jednostavno preskakana.