Zašto razvoj postaje sporiji kako vreme prolazi?
Verovatno ste u nekom filmu ili video klipu sa zanimljivostima videli sceni gde nesvakidašnji traktor za sobom vuče neobičnu prikolicu dok mu prednji točkovi lebde u vazduhu, a iz izduva kulja suluda količina dima. Nešto ovakvo:
U pitanju je tractor pulling, motosport gde se fabrički opremljeni ili modifikovani traktori takmiče u povlačenju tereta. Pobeđuje onaj koji u svojoj klasi najdalje odvuče teret. Prosto…
Ne baš. To što vuku nije obična prikolica. U pitanju su sanke, poseban uređaj koji je tako konstruisan da povećava opterećenje što se dalje vuče. To se postiže tako što se masa sa zadnjeg dela sanki prebacuje napred kako se sanke kreću i sve više zariva veliki raonik na prednjem delu sanki u zemlju. To spuštanje raonika značajno povećava opterećenje iako same sanke ni u jednom trenutku nisu postale teže:
Autor: Royalbroil. Licenca: CC BY-SA 3.0.
Ukratko, sanke čine da stvari postaju teže kako ih vučemo napred. Baš ovu osobinu je Robert Martin uporedio sa sudbinom tipičnog softverskog projekta u tekstu Kornjača i zec. U njemu je iznesena realnost mnogih softverskih projekata. U startu krećemo brzo, sa modernim alatima, neopterećeni raznoraznim vrstama “dugova” (arhitekturalni, tehnički, slabo korišćene mogućnosti, manjak testova i automatizacije itd). Kako vreme prolazi naša sposobnost da menjamo i proširujemo softver lagano opada, dok u jednom trenutku nemamo osećaj kao da za sobom vučemo planinu. Kada znamo da je kraj? Kada kapituliramo i odlučimo se na prepisivanje.
Princip je sličan kao i gore opisane sanke.
Svojim svakodnevnim odlukama da stavimo brzinu razvoja i komfor ispred kvaliteta prebacujemo masu sa kraja “sanki” ka raoniku napred i usporavamo projekat, do momenta dok nas te odluke ne ukupaju u mestu.
Pisanje testova, refaktorisanje, rad u parovima, stalna integracija, automatizacija, unapređenje arhitekture, uklanjanje retko korišćenih mogućnosti, uprošćavanje itd, sve su to aktivnosti koje drža masu nazad, dalje od raonika. Ljudi često to ne vide, već traže krivca za usporenje drugde:
nedovoljno ljudi na projektu,
zastareo stack,
nepogodan framework (“Eh da nam je sada Framework X, sve bi bilo lakše”),
nemotivisan tim, nedostatak predanosti, talenta ili znanja među ljudima,
ljudi koji su otišli su za sobom ostavili nered koji ne možemo da rešimo
i tako dalje i tako dalje. Lepeza objašnjenja koje menadžement vidi kao uzročnike problema je široka, ali su oni često predstavljaju zakasnele simptome, ne i korene problema, a neretko su samo nemaštovito zamišljeni.
Možda je za neke projekte prekasno da bismo ih povratili u neko zdravo i održivo stanje. Tu je pitanje koliko možemo da pomognemo jer traba dobro vagati napor potreban da se ljudi osveste po pitanju bitnosti kvaliteta i dovedu sistem u zdravije stanje u odnosu na očekivani povrat investicije.
Pored takvih projekata postoje mnogi mladi i/ili zdravi projekti, plus svi projekti koje tek treba da započnemo, koje valja sačuvati od gore-opisane sudbine. Svaki put kada se pomene pitanje kvaliteta i brzine neka su vam na umu sanke i ka čemu davanje prednosti brzini na uštrb kvaliteta vodi.
Kvalitet i brizana nisu zaraćene strane. Toyota je odavno uvidela da je kvalitet osnova brzine. Samo brzina, bez kvaliteta, je kratkoročno slatka, ali dugoročno pogubna. Valjalo bi time da se pozabavim u zasebnom tekstu. Ovaj se već odužio.
