Tokom dva dana koliko je trajala trećа CodingSerbia konferencija slušao sam vrlo zanimljiva predavanja relevantnih stručnjaka i što je mnogo važnije, imao sam jedinstvenu priliku da direktno popričam sa njima.
Na mene je najjači utisak ostavio uvodni keynote govor “How Conway’s Law is eating your job“ od Pitera Hintjensa (Pieter Hintjens).
U svom uvodnom predavanju, Piter je kroz povlačenje paralela između zakona fizike i zakonitosti koje vladaju u timu i generalno razvoju softvera, dao jedno fascinatno viđenje načina na koje možemo da razvijamo softver i organizujemo tim developera.
Hintjens nas uči da se na pravljenje softvera mogu primeniti standardni zakoni fizike i prirode uopšte i, ukoliko ignorišemo ovu neobičnu činjenicu, naš rad se lako može raspasti poput loše napravljenog mosta.
Na primer, tu je Drugi Njutnov (Newton) Zakon koji govori o inerciji, primenjen na upravljanje timom on može da glasi: “Što je tim masivniji, to je njegova inercija veća i potrebna je veća sila da ga pomerimo”. U praktičnom smislu, ukoliko pokušavamo da promenimo veliku kompaniju od nekoliko hiljada zaposlenih potrebna nam je ogromna sila (novac/vreme/energija). Ukoliko želimo da utičemo na tim od par ljudi, obično je dovoljno jedno veče ubeđivanja uz nekoliko piva. 🙂
Dakle, ukoliko vam je potrebna fleksibilnost i brza promena uz mala ulaganja, nemojte je tražiti u velikim timovima. Sa druge strane stabilnost i robusnost ćete teško postići u malom timu.
Možemo da nastavimo sa Trećim Njutnovim Zakonom o akciji i reakciji – “Kada gurnete tim on vas odgurne nazad.”
Da malo karikiramo – ako pokušate da promenite kompaniju od deset hiljada ljudi, bićete otpušteni. Piter doduše kaže da ovo ne važi ako ste CEO (direktor) – u tom slučaju ćete dobiti veliki bonus i onda ćete biti otpušteni. 🙂
Zaključak je da ukoliko imate veliki tim koji želite da promenite kako bi radio nešto potpuno drugačije, verovatno je isplativije jednostavno kreirati novi tim od nule.
Tu je dalje moj omiljeni “Zakon” i zaključak koji iz njega proizlazi – Marfijev (Murphy) Zakon: “Ukoliko nešto može da pođe naopako, poći će naopako. I to u najgorem mogućem trenutku, na najgori mogući način”.
Piter na osnovu toga tvrdi, i ja se potpuno slažem sa njim, da su greške ne samo očekivane, već i neizbežne.
Zaključak je: nemojte pokušavati da izbegnete greške već ih prigrlite. Tačnije – nemojte pokušavati da napravite softver koji nema grešaka, već softver koji će se oporaviti kada do greške dođe.
Sledeća Piterova analogija koja mi se dopala je bazirana na Murovom (Moore) zakonu koji kaže da se moć hardvera duplira svake dve godine. To praktično znači da softveri pravljeni pre dve godine danas rade na značajno drugačijoj hardverskoj arhitekturi od one za koju su bili projektovani. Što dalje može da se interpretira tako da zapravo niko ne razume u potpunosti kako neki sistem/softver zaista funkcioniše. Uključujući i one koji su ga pravili.
Poslednji zakon koji želim da izdvojim iz Hintjensovog keynote-a je Konvejev (Conway) zakon. Ovaj zakon se ponekad posmatra kao šaljiv i neozbiljan, ali ga je zapravo još 1968. godine formulisao programer Melvin Konvej (Melvin Conway) kao ozbiljan pokušaj da se opišu socijalne interakcije. Ovaj zakon kaže da organizacije koje proizvode sisteme, te sisteme neumitno dizajniraju kao kopije svojih komunikacionih struktura.
Ukratko – struktura softvera će imitirati strukturu tima koji ga je razvijao, stoga se trudite da vaš razvojni tim bude efikasan, distribuiran i paralelizovan jer će takav biti i vaš softver.
U razgovoru sa Piterom, nakon njegovog govora, dotakli smo se i teme konkretnog organizovanja timova, gde je izneo svoje viđenje jednog načina dobrog organizovanja tima – kreirajte male nezavisne timove i module koji po Actor modelu primaju poruke i samostalno donose mikroodluke, i po potrebi prosleđuju poruke dalje ili kreiraju nove male timove/module. Uvek treba imati u vidu da čim imate više od jednog čoveka – vi imate tim. Svaki tim je jedinstven i potpuno se menja ako dodate novog čoveka. Ukoliko timovi kreiraju softverske module po ovom konceptu, potrebno je da svakom modulu omoguće pristup drugim timovima/developerima kroz API. Time se dalje promoviše pozitivna selekcija, jer drugi developeri mogu da iskoriste i unaprede već gotove module i tako naprave nešto što originalnim dizajnom nije bilo moguće/predviđeno.
Na samoj konferenciji sam odslušao još niz zanimljivih predavanja koja imaju potencijal da promene naš način razmišljanja i pristup problematici kojom su se bavili. Ali više o tome u sledećem blog postu.
