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".