In primele luni in care am lucrat ca programator am avut parte
de un test interesant. Se punea problema lansarii unui proiect
software, iar conducatorul de proiect venit de la “centru” (CTCE,
pentru cine-si mai aminteste) si seful meu direct (in calitate de
beneficiar) s-au retras intr-un birou si au discutat vreme de vreo
doua ore cerintele pe care aplicatia trebuia sa le satisfaca.
Probabil s-a ajuns la o neintelegere cu privire la termene, pentru
ca seful m-a chemat, mi-a expus pe scurt problema, dupa care m-a
intrebat in cat timp apreciez eu ca se poate realiza. Aplicatia imi
parea simpla, mi-am facut o socoteala si am dat verdictul: o
saptamana. Stupoare. Pana la urma s-a convenit la sase luni si a
fost randul meu sa raman mirat.
Diferenta de estimare venea din abordare: in vreme ce eu
consideram dezvoltarea de software mai degraba un mestesug, oamenii
de la “centru” il considerau un soi de industrie. Adica un proces
cu o metodologie stricta, cu o planificare riguroasa, cu etape care
se succedau si toate celelalte detalii care ma duceau cu gandul la
banda de montaj din “Timpuri noi” (Chaplin, 1936). Pentru a-mi
confirma mie insumi ca n-am facut o gafa majora, am realizat in
cinci zile un prototip functional pe cerintele date, dupa care am
colaborat la procesul standard care, intr-adevar, a durat ceva mai
mult de o jumatate de an.
Partea buna a procesului de tip industrial este ca lasa in urma
lui multa documentatie si se poate realiza cu programatori
mediocri, care primesc specificatii detaliate, fara sa aiba nevoie
de imaginea de ansamblu. In felul acesta, oricine poate fi inlocuit
oricand, de pilda pentru a ajuta la un alt proiect. Insa nici acum,
dupa atatia ani si proiecte, nu stiu cine a avut dreptate. Este
dezvoltarea de software un proces de tip industrial sau este un soi
de mestesug high-tech? E mai rentabil sa lucrezi cu programatori
foarte buni sau sa “depersonalizezi” munca?
Mi-am pus din nou aceasta problema dupa ce am regasit blogul
“Joel on Software”, unde aceste intrebari sunt mereu discutate.
Joel Spolsky a lucrat cativa ani la Microsoft si a condus echipa
care a realizat programul Excel, asadar cunoaste la modul practic
cum functioneaza marea industrie de software. Cu toate acestea,
cand a parasit Microsoft si a fondat firma Fog Creek Software,
formula pe care a adoptat-o s-a rezumat la patru obiective, ce
decurg unele din altele: sa creeze cele mai bune conditii de munca,
astfel incat sa atraga cei mai buni programatori, care sa realizeze
cel mai bun software, iar de aici sa vina profitul. Convingerea sa
este ca programatorii foarte buni sunt cheia intregului edificiu,
fiindca cinci programatori mediocri nu vor realiza niciodata (iar
Joel accentueaza acest “niciodata”) un soft de calitatea celui
realizat de un programator foarte bun, asa cum cinci Salieri nu vor
produce Recviemul lui Mozart nici daca ar lucra 100 de ani.
Comparatia ii apartine si nu este intamplator ca se refera la
arta, care implica viziune, inspiratie, dar si mestesug stapanit la
perfectie. Exista insa si explicatii mai pragmatice, cum ar fi
“Legea lui Brooks”, care spune ca adaugand mai multi programatori
la un proiect intarziat nu vei obtine decat o intarziere si mai
mare. Evident, un singur proiectant cu mare productivitate nu va
avea problemele de coordonare si de comunicare pe care le are o
echipa, mai ales cand se adauga oameni noi. Pana la urma, Joel
considera ca programatorul bun este mai degraba un designer, ceea
ce aduce si putina arta in ecuatie, deci implicit si mestesug.
Daca acceptam varianta mestesugului, cum se explica faptul ca
exista o industrie de software (si exista cu adevarat), in vreme ce
dezvoltarea de software nu este un proces industrial? Mitul
eficientei metodologiilor riguroase, de tip banda de montaj, a fost
spulberat de modelul de dezvoltare practicat in multe proiecte open
source (“bazarul”), care abandoneaza orice rigoare cu exceptia
celei privind calitatea codului. La fel de haotice par la prima
vedere noile metode de dezvoltare reunite sub numele de “programare
agila”, in care mai important este raspunsul rapid la schimbari
decat urmarea unui plan, iar programul trebuie sa fie functional
cat mai repede.
Pana la urma, cred ca am avut dreptate cand am estimat la o
saptamana un proiect care avea sa dureze o jumatate de an. Daca
primesti feedback foarte devreme nu risti sa dezvolti doua luni
intr-o directie gresita. Este un principiu al bazarului: “Release
early, release often”.