Vivi pledeaza pentru “olimpici“ si pana la un punct ii dau dreptate. Sunt categoric pentru recunoasterea competentelor si mi-as dori ca toti sa inteleaga ca un programator de calitate (nu neaparat olimpic) le poate aduce mai mult decat unul de duzina. Sunt insa cateva aspecte problema, foarte viabile, pe care softistii dealtfel capabili, ce trec direct de pe bancile facultatilor la companii ca Google sau Microsoft, nu le vad:

(1) “Cowboy programming” e modul de dezvoltare rapida (“quick and dirty“) a unui proiect, in care documentatia si arhitectura de sistem sunt neglijate constant in favoarea controlului total lasat pe seama unui programator foarte capabil. Programatorul “poseda” (“owns“) partea de proiect, iar cand aceasta devine tot mai stufoasa, se mizeaza in continuare pe abilitatea lui de a naviga printre breakpoints si a fixa bresele. Din pacate, exista intotdeauna o limita dincolo de care complexitatea devine imposibil de controlat, iar bug-urile si side-effect-ele apar ca ciupercile. Iar daca vreun alt programator sau echipa iau in primire mai tarziu acea bucata de proiect, a intelege ce-a facut geniul acolo e de la bun inceput un cosmar.

(2) Prin vest s-a produs deja o mare schimbare in genul de skill-uri pe care le cauta piata la programatori. Nu se mai cauta doar softisti inzestrati in arta programarii, ci mai degraba profesionisti cu o intelegere complementara a modelelor de business si gestionarii unui proiect. Vor softisti care sa complementeze algoritmica (prin care erau obisnuiti in facultate si la olimpiade) cu intelegerea constrangerilor bugetare de proiect si-a strategiilor de business din “the real world“. Ca prea adesea programatorii propun solutii de implementare geniale, ignorand principiul “keep it simple” sau alternative viabile (hardware, alte platforme, reuse) care-ar salva multi bani companiilor, cu efecte similare la punerea in practica a proiectelor.

(3) Lumea de afaceri se plange tot mai des ca marile companii, dezvoltatoare de platforme si middleware, nu-s destul de realiste si n-au destula intelegere a nevoilor reale din mediul business. Aproape orice noua versiune a unui produs (pretinde ca) reduce din complexitate, pentru a introduce de fapt si mai multa complexitate la alt nivel. Sau baga puzderie de noi “features” (mult prea multe complet nefolositoare), cand ignora in intregime use-case-uri de baza. Luati ca exemplu imediat perfectionarea bazelor de date de-a lungul anilor, cand nu avem nici la ora aceasta o query SQL standard prin care sa se extraga direct o pagina de rezultate din lista intoarsa de inregistrari. E un use-case folosit atat de frecvent, dar implementatorii se vad nevoiti sa reinventeze de fiece data roata.

(4) Multor programatori tineri, oricat ar fi de inzestrati la rezolvarea algoritmica a unor probleme, le lipseste initial privirea de ansamblu (“the big picture“) a unui proiect. Si nu ma refer strict la partea de software, ca tocmai aici e greseala. Unii nu vor sa considere faptul ca un proiect software trebuie combinat, pe cat posibil, si cu solutii hardware (daca acestea se justifica prin economii bugetare, la rezultate functionale similare) sau de alta natura. Ori fac recomandari pur subiective si preferentiale de sisteme, limbaje, componente, solutii, cand ar trebui sa lase deoparte “ce le place” sau “ce cunosc” ei de fapt, si sa dea dovada de mai multa responsabilitate.

Problema majora a celor mai multe sisteme de pe piata nu vine de la ineficienta algoritmilor, ci de la lipsa unor arhitecturi scalabile. E foarte greu si foarte scump sa restructurezi un proiect, odata ce ai pornit cu o anumita modularizare functionala, odata ce ai ales un anumit tip de cache sau gen de procesare. Mai grav, cam orice sistem trebuie oricum revizuit peste 4-5 ani, sa tii pasul cu competitia. Si-n multe cazuri e din pacate nevoie sa rescrii totul, de la zero. Putini tin cont si de durata de viata a unui sistem si investesc nejustificat de mult intr-un algoritm (mai mult din placere) ce se va dovedi oricum depasit in numai cativa ani.

(5) O statistica dinainte de 2000 arata ca cca 90% din toate proiectele de software isi triplau costurile, fata de estimarile initiale. Problema vine in parte de la programatori, care adesea nu stiu sa estimeze corect cat le-ar lua implementarea unui anumit algoritm. Diferenta de mentalitate intre un manager ne-tehnic (orientat business) si un programator capabil este urmatoarea: primul va inmuti orice estimare initiala de timp cu 3, iar al doilea va plusa pe un challenge aplicat asupra lui insusi si va miza pe cat de repede poata sa vina cu solutia. Genul acesta de “pariuri cu sine insusi” e foarte costisitor pentru mediul de afaceri, ca cele mai multe challenge-uri nu reusesc.

(6) Olimpicii neglijeaza adesea costurile de intretinere (maintenance) ale unui proiect. Asta ca cel mai adesea sunt implicati in R&D, maintenance-ul fiind lasat mai apoi pe mana altora, considerati “mai putini capabili”. Si totusi, costurile cele mai mari ale unui proiect (cu cateva ordine de marime fata de cat a costat initial dezvoltarea) vin de la intretinere. Vina este frecvent a genialilor care nu s-au preocupat de documentarea codului, de-o modularizare usor de inteles si upgrade-at, de faptul ca e nevoie ca si alte persoane sa le inteleaga mai apoi codul sursa si algoritmul.

• WordPress-ul si puterea pe mana idiotului
• Vizitatori recenti
• Proiecte novatoare
• Prietenul, cel mai bun spammer al tau
• Patente din orice