Ingineria programării poate părea la o primă privire superficială un domeniu de-a dreptul obsedat de măsurare și control. Și cum niciodată nu mi s-a părut că exercitarea controlului e vreo virtute sau aduce prea multe beneficii, am fost mai mult decât încântată să citesc aceeași părere exprimată de unul dintre fondatorii ingineriei programării și unul dintre foștii promotori ai nevoii de măsurare și control. Dar am fost suprinsă atunci când am realizat că unii au luat articolul respectiv drept un atac sau o denigrare a ingineriei programării ca disciplină. Cred că au rămas la acea primă și superficială privire asupra domeniului de a ajuns la o asemenea concluzie. Sau sunt prea atrași de potențiala plăcere a unei bătăi în lumea cercetării...
Oricum ar fi, articolul cu pricina mie mi se pare ceva excepțional, uneori prin implicații și idei secundare poate chiar mai mult decât prin ideea principală. Ingineria programării oricum a început de ceva vreme să se reorienteze în problema asta și sunt sigură că articolul poate fi doar un catalizator pentru o reorientare mai rapidă și nicidecum elementul generator. Dar articolul ridică problema controlului la un mod mai general și arată că e benefică doar atunci când nu e prea mult de câștigat. Iar întrebarea este: de ce ne apucăm de atât de multe lucruri în care avem nevoie de control? Și de ce simțim până la urmă atâta nevoie de a controla? A avea un control e una, dar a exercita controlul devine cu totul altceva.
În plus, articolul e un model de recunoaștere a unei greșeli. Dar despre partea asta vă invit să citiți pe Voxpublica.
Comments feed: RSS 2.0
Oricât ar lua unii drept un atac ideea asta, exemplele date în articol sunt cel puțin grăitoare (mai ales în cazul proiectelor Google).
Sunt două aspecte care mi se pare că influențează ingineria software în direcția controlului (de multe ori excesiv):
1.Ideea (greșită, după mine) că proiectarea software nu diferă prea mult de alte domenii ale ingineriei. Mi se pare mult mai ușor să bagi un produs palpabil într-un ciclu de proiectare-asamblare, tocmai din cauza faptului că principiul „simplicity favors regularity” nu aplică prea bine la soft (oricât ar încerca să introducă programarea orientată pe obiecte chestia asta).
2.E mult mai ușor pentru un programator să gândească că producția software se poate face algoritmic, după niște pași stricți. Uneori merge, alteori nu. Un mic exemplu: Ubuntu a avut parte de ambele experiențe în ciclul de release-uri „o dată la șase luni”. Cei de la Debian au renunțat recent la a impune deadline-uri pentru versiunile lor majore. Să nu vorbesc de ce a ieșit când s-a lansat KDE 4.
Poate că mă găsesc prea mult în sfera celor care consideră că programarea nu trebuie forțată sub nici o formă, dar sunt de acord cu zicala de pe site-ul Wordpress: code *is* poetry, more or less. Iar pe partea de more aș adăuga că poezia făcută la comandă n-a sunat niciodată extraordinar. :)
Ceea ce spui la 1 e, daca vrei, intr-un fel ideea la care s-a ajuns intr-un final: ca nu face nici un bine nimanui sa se "transplanteze" ingineria din alte domenii la software. Dar nu pentru ca ar fi dificil (asta e doar un obstacol de depasit pentru cercetare, nu o invalidare in sine - altfel n-am mai face decat lucruri simple), ci pentru ca nu se merita.
La 2 gresesti. Majoritatea programatorilor prefera sa considere scrisul de soft mai asemanator cu scrisul de poezii decat cu...matematica si in mod sigur prefera sa nu aiba nici o...fortare (intre altele pentru ca e mai cool :) ). Ideea gresita daca vrei a fost in a alege strict una dintre parti, in cazul controlului excesiv partea algoritmica in detrimentul celei poetice. Dar adevarul este ca poezia si matematica se intalnesc ades...
Si ca simplu exemplu, pana si la poezie exista metrici, ritm samd...si folosesc. E drept ca nu sunt poate esentialul, dar fara ele schioapata poezia, indiferent de idee. Da, nu e musai sa le masori ca sa le nimeresti cum trebuie si poetii mari sigur le nimeresc. Dar le nimeresc nu pentru ca le ignora sau desconsidera, ci pentru ca si le-au insusit deja la un nivel la care nu mai au nevoie sa se gandeasca la ele. Si in programare e la fel: in momentul in care anumite tehnici (fortare cum spui tu) sunt insusite, devin naturale...
Viziunea programarii drept activitate boema e frumoasa, dar nu mai tine din pacate. Si in realitate tot ceea ce se cere nu e boemie desavarsita ("nu trebuie fortata sub nici o forma") ci doar un pic de libertate, o echipa sudata si o problema reala de rezolvat.
Ah, si controlul vine de cele mai multe ori dintr-o cauza simpla: e garantia ceruta in schimbul platii. Ceruta uneori chiar de noi ca societate, inclusiv de noi cei care cu alte ocazii programam si n-am vrea control...
Cred că mai degrabă aș face analogia între regulile unei poezii și cele impuse de un anumit limbaj de programare. Altfel, diferența e că poezia satisface o cerință practică mai rar sau deloc (aceea de „a-l mulțumi pe rege” - lucru mai rar observabil în ziua de azi), pe când rolul de bază programelor este unul practic (sau ar trebui să fie în multe cazuri).
Caz în care, într-adevăr, programarea ca și activitate pur boemă nici nu își mai are rostul (probabil trebuia să adaug la „nu ar trebui forțată sub nici o formă” și „într-o lume ideală”). Chiar și așa, acea libertate contează destul de mult și este și ceea ce face din companii precum Google afaceri de succes. Și prin „libertate” nu înțeleg neapărat eliminarea deadline-urilor. Chiar și un pic mai mult timp pentru brainstorming poate însemna mai multă libertate.
Sunt de acord. În același timp, aș ține cont de faptul că „metrica” ingineriei software, menționată în articol, tinde în anumite cazuri să fie simplificată atât de mult încât programele să fie văzute doar ca și cheltuieli și generatoare de venituri pe termen scurt. Moment în care cei cu adevărat pasionați de meserie preferă să se refugieze în proiecte de mai mică anvergură, dar care aduc o satisfacție personală mai mare.
Totuși, stau și mă gândesc: dacă acum 30 de ani, cu mijloacele de atunci, se putea pune în practică o idee genială cu câteva calculatoare într-un subsol, nu văd de ce nu s-ar putea face același lucru și astăzi, folosind mijloacele zilelor noastre, având la dispoziție un apartament și câteva PC-uri. Mă gândeam doar; eu zic că totuși se poate (dacă există organizare, nervi suficient de tari și resurse financiare la început mici).