Ljudi se dele na dve grupe: oni koji umeju reći “ne” i oni koji ne umeju. Kad je reč o muško-ženskim odnosima, srpski jezik raspolaže zgodnim izrazom za pripadnice lepšeg pola koje spadaju u drugu grupu – radodajke. E, kad su u pitanju programeri, stvari se unekoliko komplikuju…

Na prvi pogled zvuči jako čudno, ali ljudi izgleda vrlo često zaboravljaju ovu naizgled jednostavnu jednosložnu rečcu. Iako većina maloletne dece njome jako dobro vlada (“Ne boraniju!”, “Ne te patike od tri hiljade, nego ove od pet!”), pošto postanu projekt menadžeri i programeri, ista ta deca naprasno izgube sposobnost upotrebe reči “ne”. Prisetite se koliko ste puta doživeli situaciju da klijent pita “A može li taj vaš program ABC da radi XYZ?”, i dok vama ruke još nisu stigle do glave za koju ste krenuli da se hvatate, vaš menadžer je već izgovorio “Moći će!”. Poučeni neprijatnim iskustvom, već znate odgovor na sledeće klijentovo pitanje: “A može li to do kraja meseca?”.

No, tema ovog teksta neće biti menadžeri sa govornom manom, već oni koji su potencijalno još veći problem – programeri koji ne znaju reći “ne”. Dok se neodmerenost menadžera i može kompenzovati angažovanjem dodatnih resursa (“E, momci, imate li još nekog ko je dobar sa PHP-om?”), pomeranjem rokova (“Znate, glavni projektant nam je prekjuče preminuo!”) i, na kraju krajeva, surovim prekovremenim radom (“Bojim se da ćemo_svi_ ovog meseca morati da uložimo nešto dodatnog napora…”), neodmerenost programera je znatno suptilnija i nama, ostalim programerima, potencijalno donosi više glavobolje. Evo zašto.

Programer koji ne zna reći “ne” je po pravilu i vorkoholik – posao zauzima centralno mesto u njegovom životu. Pored toga, obično gaji osećaj da je baš on onaj Odabrani, a posao koji mu je dat presudan za sudbinu firme. Zato, iz najbolje namere, on uvek preuzima na sebe svaki zadatak koji menadžer poželi, ma kako nemoguć on bio. Nema preispitivanja odluka koje dolaze “odozgo”, nema pokušaja da se specifikacija ili rokovi prilagode realnom stanju stvari, a menadžeri tehnički edukuju u pravcu realnijeg sagledavanja mogućnosti – sve može! Uzgred, možda primetite da su ovakvi ljudi idealni vojnici – slepo slede naredbe i vrlo su odgovorni i uporni u njihovom sprovođenju, često nimalo ne štedeći sebe. Zapravo, kombinacija ovog vojničkog arhetipa i često destruktivnih posledica po kôd i okolne ljude bude asocijaciju na u poslednje vreme aktuelne bombaše-samoubice.

Mala digresija – upravo se setih priče o Aliji Sirotanoviću: stariji čitaoci se verovatno sećaju nasmejanog rudara sa stare novčanice. U pitanju je bio role-model radnika-udarnika Titove Jugoslavije. Skroman u životu i bolesno predan na poslu, svakodnevno je obarao (i dizao) norme, dok su ostali rudari naokolo baldisavali od umora, pokušavajući da prate njegov tempo. Anegdota kaže da je Alija jednom prilikom, tokom Titove posete rudniku, na Titovo pitanje šta bi hteo da mu socijalistička Jugoslavija pokloni za požrtvovanost, zatražio – samo jedan novi kramp, jer mu se stari već bio skroz pojeo.

Da se vratimo mi našem programeru – udarniku. Nakon što je prihvatio na sebe sav posao koji mu se nudio i pristao na najtešnje moguće rokove, on počinje da kodira. E, tu dolazi do problema. Nova funkcionalnost koja treba da se razvije nije planirana unapred, postojeći model softvera se ne proširuje promišljeno (jer se nema vremena za to, a i nije obuhvaćeno dugoročnim planom razvoja). Ma kako dobar i efikasan programer bio, zbog kratkih rokova i nedostatka vremena za projektovanje, on pribegava prljavim metodama - “copy-paste inheritance” i “quick’n’dirty one-time fixes”, jer se nema vremena da se funkcionalnosti zajedničke sa postojećim delovima kôda izdvoje u posebne klase i metode – kôd se množi i raste, nove se funkcionalnosti dodaju na najnelogičnija mesta, identifikatori – klase i metode – dobijaju na brzaka smišljena imena, naknadne promene na kôdu se na njih ne odražavaju, komentara naravno nema i ono što ostaje je suvi pakao.

Naravno, posle par neprospavanih noći naš udarnik je završio obećanu funkcionalnost – sve radi i mušterija je zadovoljan. Nakon završenog projekta, naš veseli menadžer već podrazumeva da su jednokratno pisane funkcionalnosti već deo samog proizvoda i bez razmišljanja ih nudi i drugim mušterijama. Programerima ostaju tri mogućnosti:

  1. Da traže dodatno vreme ne bi li novu funkcionalnost integrisali u postojeći proizvod kako treba. Osim što će to vreme teško dobiti (hajde sad ti objasni menadžeru zašto ti treba vreme za nešto što već postoji), za integraciju će biti potrebno ogromno vreme, verovatno istog reda veličine kao ono koje je programer-udarnik utrošio.
  2. Da traže dodatno vreme ne bi li novu funkcionalnost napisali ispočetka, ali ovaj put uz temeljito projektovanje i proširivanje postojećeg modela, bez stotina istih linija kôda u tri različite metode i bez pravopisnih grešaka u imenima klasa. Za ovo je potrebno značajno vreme, ali treba razmisliti i o ovoj opciji – programeri mnogo radije pišu kôd ispočetka nego što tumače i ispravljaju tuđi.
  3. Da ostave kôd kakav jeste – drugim rečima zavuku problem pod tepih i čekaju trenutak kad će tempirana bomba eksplodirati. Trajno usvajanje ove politike je siguran način da skroz-naskroz upropastite svoj softverski proizvod: svaka iduća izmena trajaće sve duže i duže (ako sad hoćemo da ispravimo bag u uskladištenoj proceduri A, moraćemo da ga ispravljamo i u copy-paste-ovanim procedurama A1, A2 i A3, pisanim “na brzaka”, pogodite od strane koga). U jednom trenutku vreme potrebno za ispravke postaće besmisleno dugačko i vama će se najviše isplatiti da bacite ceo proizvod kroz prozor, odete u planinu i čuvate ovce.

Osim poražavajućeg osećaja da ispravljate tuđe greške i poražavajućeg osećaja da radite isti posao koji je neko pre vas već radio, ispravljanje tuđih “herojskih podviga” sa sobom nosi i rizik da menadžeri obrnuto percipiraju vaše uloge u proizvodnji i udarnika vide kao onog efikasnog, koji gura proizvod napred, a ostale kao one ko manje-više ne rade ništa i stalno nešto zakeraju.

Verovatno se na kraju pitate šta se može uraditi po pitanju programera koji ne znaju reći_ne_. Naravno, zapošljavanje logopeda (ili psihologa?) iz naslova neće puno pomoći – spremnost za samoubilačke akcije svako od nas donosi (ili ne donosi) od kuće i takve navike se ne menjaju lako. Bojim se da se, iz ugla kolega programera, malo toga može učiniti. Menadžer je, sa druge strane, taj koji može preduprediti posledice jurišanja na projekat – pre svega dobrim poznavanjem kôda i okvirnog vremena potrebnog za određenu funkcionalnost, ali i tešnjom saradnjom i stalnom konsultacijom sa svim stručnijim programerima (obično vođama timova) pri raspodeli zadataka – kratak sastanak sa pitanjem “šta mislite kako da dodamo funkcionalnost XYZ u program ABC” je sasvim dovoljan da se nađe najbolje rešenje i izbegnu moguće zamke_mogu-ja-to-šefe_ pristupa.