November 26th, 2007 Alex
Citind despre problemele sau succesele altora am dat de părerea lui Dragoș Manac din Alergii de Business [1] …
Google isi imparte oamenii tehnici in echipe mici, pentru a atinge maximul de eficienta … In Romania nu prea exista profesionisti. Noi nu suntem foarte buni, dar castigam mult din faptul ca ceilalti sunt foarte slabi (in general) … Echipele sunt mereu mari. Multi oameni, multi vizionari, multi vanzatori, multi vorbitori, multi sustinatori, putini tehnici. Putini si slabi - flancati de tehnicul-ajuns-in-management, cu idei rasfirate si neclare despre ce inseamna business-ul si ce inseamna IT-ul, cu nicio idee de project management, cu nicio idee de lucru structurat/in echipa, cu multe decrete si pareri …
Aici e o mică eroare de logică … problema nu prea există doar în România. Problema s-a extins în toate subdomeniile industriei IT, de la armată la corporațiilor multinaționale și la startup-urile pline de speranță, indiferent de locație (SUA, Canada, Elveția, România), deși unele locații sunt clar mai avantajate decât altele.
În cazul în care nu sunteți documentați, industria software se află în criză, prima oară afirmația făcându-se în mod oficial la o conferință sponsorizată de NATO în 1968 [2] (deși Dijsktra a afirmat același lucru mai devreme). Toată lumea se află în delir deoarece complexitatea software-ului crește exponențial în timp ce numărul de programatori crește doar în progresie aritmetică. De unde și dorința companiilor de a angaja cât mai mulți programatori, de unde și pretențiile de studii/experiență din ce în ce mai mici. Motiv pentru care înainte de spargerea balonului din 2000 editori de HTML ajunseseră să fie plătiți cu sume absolut obscene.
Datorită pregătirii slabe a personalului s-au ivit diverse efecte secundare: cum ar fi inventarea de metodologii și unelte proiectate pentru scalabilitatea la nivel de personal … dezvoltare asemănătoare trecerii de la manufactură la industrie care s-a făcut înlocuind nevoia de oameni pricepuți cu linii de producție automatizate de roboți industriali și cu forță de muncă brută și ieftină.
Cât despre birocrație și “design by comitee” … este peste tot, inclusiv la Google (într-o măsură mai mică sau mai mare). Este natural: deși cele mai excepționale design-uri și invenții sunt provenite din gusturile unui singur om (judecând analizând istoria), companiile în general nu riscă resurse fără să-și asigure un ROI … și pentru un singur om (sau pentru o echipă mică de oameni) poate fi o responsabilitate mult prea mare. La Adobe, cel puțin la departamentul unde lucrez, participă la design-ul proiectului multe departamente interesate de proiectul nostru. Iar ședințele pot fi chiar neproductive câteodată deoarece fiecare are ideile proprii despre necesitățile rezolvate de proiect … dar este un fapt al vieții de inginer și-l accept ca atare.
Și chiar mă deranjează când se generalizează problema la România: problema este peste tot și este de substanță. Într-adevăr, mulți candidați ce participă la interviuri sunt extrem de nepregătiți … lăutari cum ar zice unii. Și într-adevăr, mulți oameni vor o slujbă de inginer software doar deoarece se plătește bine. Dar am întâlnit și o grămadă de oameni deștepți, bine pregătiți și puși pe fapte mari, iar câțiva dintre ei îmi sunt colegi.
Problema cu industria software este că nu este o industrie. Termenul aproape că este un oximoron. Nu putem momentan aplica soluțiile folosite în alte industrii în principal deoarece problemele rezolvate sunt de multe ori probleme noi (sau probleme vechi cu parametrii de funcționare noi - e.g. port-uri pe alte platforme, optimizare de resurse, etc…).
Problemele sunt următoarele:
- făcând abstracție de timp și de bani care sunt oricum omniprezente peste tot, nu există limitări fizice ale proiectelor, singurele limitări fiind date de propria noastră imaginație
- metafora cărămizilor LEGO nu se poate aplica în ingineria software, și ne facem rău singuri dacă tot încercăm
- avem foarte puține adevăruri absolute, cunoștințele din informatică fiind foarte imperative (asemenea rețetelor de bucate) și evident apar probleme atunci când lucrăm la rețete noi
Ne place să afirmăm că ingineria software este o inginerie, dar de fapt ingineria software este momentan o artă.
Să standardizezi practici în ingineria software este ca și când i-ai spune unui pictor: dacă folosești tipurile astea de pensule și culorile astea și ai voie să folosești doar linii de grosimea asta și doar unghiuri care sunt multiplu de 30 de grade: atunci pictura va fi mai de calitate și va fi gata într-o lună.
Și chiar există picturi limitate la forme geometrice simple și la un număr mic de culori.
Problema este că nu poți exprima orice vrei cu astfel de limitări, și dacă “industria picturilor” le-ar fi avut probabil că picturile din Capela Sixtină [3] a lui Michelangelo n-ar mai fi existat.
Însă puțini artiști celebri au ajuns pe culmile succesului fără să studieze reușitele și greșelile altor artiști. Când vorbim de industria software suntem total la polul opus: repetăm aceleași greșeli încă odată și încă odată, generație de genereție. Iar când simțim nevoia să luăm o pauză și să ne reflectăm la ce am greșit ajugem să implementăm practici ce par a fi funcționat (pentru alte proiecte) de-a dreptul orbește, fără să ne gândim la motivele pentru care o facem.
Așa cum spune Alan Kay - software-ul azi este construit mutând cărămizi prin truda a mii de sclavi, când evoluția sa ar trebui să fie mult mai organică. Putem învăța extrem de multe de la natură … nu există sisteme mai complexe decât cele construite organic prin teoria evoluției lui Darwin și dacă vreți o dovadă uitați-vă în oglindă. Este greu de imaginat cum ar putea fi corpul omenesc vreodată construit prin cărămizi LEGO și cu toate astea încercăm cu disperare să aplicăm cu dârzenie aceleași metafore din alte industrii … visul oricărui manager, să iei componente și să le combini într-un mod previzibil, on-time și on-budget.
Desigur, există tone de metodologii de dezvoltare, vorbind atât de implementare, cât și de managementul echipei sau de dezvoltarea design-ului. Însă nimic nu este dovedit a funcționa decât pentru clase restrictive de probleme.
Sunt multe de scris pe această temă, mult mai multe decât pot intra în dimensiunea limitată a unui articol de blog, și cu siguranță mult mai multe decât poate reproduce un mic “hacker wannaber”.
O carte de referință ce dezbate pe larg acest subiect este Dreaming in Code [4], de Scott Rosenberg, o incursiune în lumea proiectului Chandler, un proiect extrem de ambițios care a avut parte de toate resursele necesare - programatori și designeri talentați, timp, bani și suficientă atractivitate pentru a atrage colaboratori externi. Au crezut că ei sunt mai speciali, au crezut că proiectul lor este diferit, au crezut că au învățat din greșelile altora. Și deși proiectul a născut proiecte paralele și o grămadă de idei revoluționare, din 2003 și până în prezent proiectul se află într-o perpetuă versiune de preview.
Somewhere, someone’s fist is pounding the table again. Why can’t we build software the way we build bridges?
Astfel de cărți merită citite. Altfel suntem blestemați să retrăim ziua de azi la infinit [5].
Referințe
[1] Alergii de Business [dragosh.bloghost.ro]
[2] Software engineering: raport [wikipedia.org]
[3] Capela Sixtină [wikipedia.org]
[4] Dreaming in Code [dreamingincode.com]
[5] Groundhog Day [imdb.com]
Posted in management, rant | 2 Comments »
Întreruperile de la locul de muncă produc scăderea drastică a randamentului.
Se întâmplă același lucru când te concentrezi pe o sarcină … reții tot felul de detalii, fără conexiuni evidente, și atunci când încerci mai multe soluții, în mintea ta se construiește un arbore, unde frunzele sunt soluțiile finale posibile, iar nodurile non-terminale sunt soluții parțiale. În cazul în care nu merge ceva, trebuie să te întorci la o idee precedentă. Plus că apar mini task-uri, sau erori la care trebuie să te întorci. Doar n-o să petreci câte 2 minute să creezi intrări în Bugzilla (sau whatever) pentru orice detaliu la care trebuie să te întorci, mai ales dacă trebuie să te întorci în următoarea jumătate de oră.