Design şi cercetare

Ianuarie 2003, Paul Graham
Romanian Translation
(originally - Design and Research)

(Acest articol este derivat dintr-un discurs ţinut în toamna lui 2002 într-o întâlnire a NEPLS.)

Vizitatorii acestei ţări sunt deseori surprinşi să afle că americanii adoră să înceapă o conversaţie întrebând "ce mai faci?" Niciodată nu mi-a plăcut această întrebare. Rareori am avut un răspuns potrivit pentru ea. Dar cred că am rezolvat în sfârşit problema. Acum, când cineva mă întreabă ce fac, mă uit direct în ochii lor şi spun "Designuiesc un nou dialect de Lisp." Recomand acest răspuns celor cărora nu le place întrebarea aceasta. Conversaţia se va schimba imediat către alte subiecte.

Nu consider că fac cercetare în limbajele de programare. Doar designuiesc unul, în acelaşi mod în care cineva ar putea designui o clădire sau un scaun sau un nou font. Nu încerc să descopăr nimic nou. Doar vreau să fac un limbaj în care să fie bine să programezi. În anumite feluri, această presupunere face viaţa mult mai uşoară.

Diferenţa dintre design şi cercetare pare a fi o întrebare a noului comparativ cu binele. Designul nu trebuie să fie nou, dar trebuie să fie bun. Cercetarea nu trebuie să fie bună, dar trebuie să fie nouă. Cred că aceste două drumuri converg la vârf: cel mai bun design depăşeşte predecesorii folosind idei noi, şi cea mai bună cercetare rezolvă probleme care nu doar sunt noi, dar şi merită rezolvate. Deci în final ţintim către aceeaşi destinaţie, doar că o abordăm din direcţii diferite.

Astăzi voi vorbi despre cum arată acest scop din spate. Ce se face diferit atunci când tratăm limbajele de programare ca o problemă de design în loc de una de cercetare?

Cea mai mare diferenţă este că te axezi mai mult pe utilizator. Design-ul începe prin a întreba, pentru cine se rezolvă problema, şi ce doresc ei de la ea? Un arhitect bun, de exemplu, nu începe prin a crea un design pe care apoi să îl impună utilizatorului, ci prin studierea utilizatorilor ţintă şi descoperirea a ceea ce au nevoie.

Observă că am spus "ce au nevoie", nu "ce îşi doresc". Nu vreau să dau impresia că lucrul ca un designer înseamnă lucrul ca un bucătar, care face orice îi comandă clientul. Această tendinţă variază de la un domeniu la altul în artă, dar nu cred că există vreun domeniu în care cea mai bună muncă este realizată de către oameni care doar fac exact ce li se spune de către clienţi.

Clientul are mereu dreptate în sensul în care măsura designului bun este dată de cât de bine merge pentru utilizator. Dacă faci o nuvelă care plictiseşte toată lumea, sau un scaun în care e oribil să stai, ai făcut o treabă proastă, punct. Nu există nici o apărare în a spune că nuvela sau scaunul sunt designuite în concordanţă cu cele mai avansate principii teoretice.

Şi totuşi, a face ceva care să meargă pentru utilizator nu înseamnă doar să faci ce îţi spune utilizatorul. Clienţii nu ştiu care sunt toate posibilităţile, şi deseori se înşeală în legătură cu ceea ce vor cu adevărat.

Răspunsul acestui paradox, cred, este că trebuie să designuieşti pentru utilizator, dar trebuie să designuieşti ceea ce acesta are nevoie, nu doar ce acesta spune că vrea. Se aseamănă cu meseria de doctor. Nu poţi doar să tratezi simptomele pacienţilor. Când un pacient îţi spune simptomele, trebuie să îţi dai seama ce e în neregulă cu el cu adevărat, şi să tratezi acel lucru.

Această focalizare pe utilizator e un fel de axiomă din care majoritatea practicilor pentru un design bun pot fi derivate, şi în jurul căreia majoritatea problemelor în design se axează.

Dacă designul bun trebuie să facă ce vrea utilizatorul, cine este utilizatorul? Când spun că designul trebuie să fie pentru utilizatori, nu vreau să implic ca designul bun ţinteşte să fie cel mai mic numitor comun. Poţi să alegi orice grup de utilizatori doreşti. Dacă designuieşti o unealtă, de exemplu, poţi să o designuiesti pentru oricine de la începători la experţi, şi ceea ce este design bun pentru un grup s-ar putea să fie design prost pentru altul. În concluzie, trebuie să alegi un grup de utilizatori. Nu cred că poţi vorbi măcar de design bun sau prost decât în referinţă cu nişte utilizatori ţintă.

E foarte probabil să obţii un design bun dacă designerul se află printre utilizatorii ţintă. Când designuieşti ceva pentru un grup care nu te include, tendinţa e să designuieşti pentru oameni pe care îi consideri mai puţin sofisticaţi decât tine, nu mai sofisticaţi.

Acest lucru e o problemă, deoarece uitatul în jos la utilizator, chiar şi benevol, pare să corupă inevitabil designerul. Suspectez că foarte puţine proiecte de locuinţă în SUA au fost designuite de arhitecţi care se aşteptau să locuiască în ele. Acelaşi lucru se observă în limbajele de programare. C, Lisp şi Smalltalk au fost create pentru uzul propriilor designeri. Cobol, Ada, şi Java, au fost create pentru ca alţi oameni să le folosească.

Daca crezi că designuieşti ceva pentru idioţi, şansele sunt să nu designuieşti ceva bun, chiar şi pentru idioţi.

Chiar dacă designuieşti ceva pentru cei mai sofisticaţi utilizatori, totuşi, designuiesti tot pentru oameni. E diferit în cercetare. În matematică nu alegi abstracţii deoarece e uşor pentru oameni să le înţeleagă; alegi orice face demonstraţia mai scurtă. Cred că acest lucru este adevărat pentru ştiinţe, în general. Ideile ştiinţifice nu sunt făcute pentru a fi ergonomice.

In artă, lucrurile stau foarte diferit. Designul se axează pe oameni. Corpul uman este un lucru ciudat, dar când designuieşti un scaun, pentru asta faci designul, şi nu există cale de ocolire. Orice artă trebuie să se adapteze la interesele şi limitările oamenilor. În pictură, de exemplu, toate celelalte lucruri fiind egale, o pictură cu oameni în ea va fi mai interesantă decât una fără. Nu e doar un accident al istoriei faptul că picturile minunate ale Renaşterii sunt pline de oameni. Dacă nu ar fi fost, pictura ca mediu nu ar fi avut prestigiul pe care îl are.

Fie că îţi place sau nu, limbajele de programare sunt de asemenea pentru oameni, şi suspectez că creierul uman este la fel de neîndemânatic şi ciudat precum corpul uman. Anumite idei sunt uşor de înţeles pentru oameni, iar altele nu sunt. De exemplu, se pare că avem o capacitate foarte limitată de a lucra cu detalii. Acest fapt face limbajele de programare o idee bună în primul rând; dacă am putea fi atenţi la detalii, am programa în limbajul de asamblare.

Reţine, de asemenea, că limbajele nu sunt în primul rând o formă pentru programele terminate, ci un concept în care programele trebuie să fie dezvoltate. Oricine în artă ar putea să îţi spună că ai dori medii diferite pentru două situaţii. Marmura, de exemplu, este un mediu drăguţ, de durată, pentru ideile terminate, dar unul foarte inflexibil pentru dezvoltarea noilor idei.

Un program, ca dovadă, este o versiune finisată a unui copac care în trecut a avut starturi false peste tot. Deci testul unui limbaj de programare nu este doar cât de curat va arăta programul final, dar cât de curată a fost calea către versiunea finală. O alegere de design care îţi dă programe finale elegante s-ar putea să nu îţi dea un proces al designului elegant. De exemplu, am scris câteva macrouri de definire a macrourilor pline de apostroafe pe mai multe nivele care acum arată ca mici bijuterii dar pentru care am petrecut ore de încercări şi nereuşite urâte, şi, sincer, tot nu sunt pe deplin sigur că sunt corecte.

Deseori ne purtăm ca şi cum testul unui limbaj este cât de bine arată versiunea finală în el. Pare aşa de convingător când vezi acelaşi program scris în două limbaje, şi o versiune e mult mai scurtă. Însă când problema aceasta este considerată din punct de vedere al artei, ea apare mai rar. Nu vrei să ajungi cu un limbaj de programare precum marmura.

De exemplu, e un mare câştig în dezvoltarea software-ului existenţa unui mediu interactiv, ceea ce în Lisp se cheamă bucla read-eval-loop. Şi când ea există cu adevărat, ea are efecte reale asupra designului limbajului. Ea nu ar funcţiona bine, de exemplu, într-un limbaj în care trebuie să declari variabilele înainte de a le folosi. Când doar tipăreşti expresii în buclă, vrei să fii în stare să setezi x la o anumită valoare iar apoi să începi să faci diferite lucruri cu x. Nu vrei să declari tipul lui x, la început. S-ar putea să contrazici ambele premise, dar dacă un limbaj trebuie să aiba o buclă pentru a fi convenabil, şi declaraţiile obligatorii de tip sunt incompatibile cu bucla, atunci nici un limbaj care face declaraţiile de tip obligatorii nu ar putea fi convenabil când se programează în el.

În practică, pentru a obţine un design bun trebuie să te aproprii, şi să rămâi aproape de utilizatorii tăi. Trebuie să calibrezi ideile tale constant asupra utilizatorilor, mai ales la început. Unul dintre motivele pentru care nuvelele lui Jane Austen sunt aşa de bune este faptul că le citeşte cu voce tare familiei sale. De aceea niciodată nu se înneaca în descrieri indulgente artistice ale peisajelor, sau în filozofie pretenţioasă. (Filozofia există acolo, dar ea e întreţesută în interiorul poveştii în loc de a fi pusă acolo ca o eticheta.) Dacă deschizi o nuvelă "literală" medie şi îţi imaginezi citind-o cu voce tare prietenilor tăi ca ceva ce ai scris tu, vei vedea ce fel de povară este tipul acesta de scrieri pentru cititor.

În lumea software-ului, această idee e cunoscută sub principiul "Mai prost e mai bine". De fapt, sunt mai multe idei mixate în conceptul "Mai prost e mai bine", ceea ce reprezintă motivul pentru care lumea înca se mai ceartă daca mai prost e cu adevărat mai bine sau nu. Dar una din ideile principale în acest mix este că dacă construieşti ceva nou, ar trebui să aduci un prototip în faţa utilizatorilor cât mai devreme posibil.

Alternativa ar putea fi numită strategia Hail Mary (o pasă lungă la sfârşitul unui meci, aruncată în disperare, cu puţine şanse de reuşită). În loc de a scoate un prototip rapid, şi de a-l îmbunătăţi gradual, încerci să creezi produsul complet, final, într-o lungă încercare. Din câte ştiu, aceasta este o reţetă pentru dezastru. Multe companii tinere, fără de număr, s-au auto-distrus în acest fel în timpul exploziei Internet-ului. Nu am auzit de nici un caz în care a reuşit.

Ceea ce oamenii din afara lumii software s-ar putea să nu realizeze este că principiul "Mai prost e mai bine" se regăseşte în artă. În desen, de exemplu, ideea a fost descoperită în timpul Renaşterii. Acum aproape orice profesor de desen îţi va spune că modul corect prin care poţi obtine un desen precis nu este să te mişti greoi în jurul conturului unui desen, deoarece erorile se vor acumula şi vei observa că sfârşitul liniilor nu se întâlnesc. În schimb, ar trebui să desenezi rapid câteva linii, aproximativ în locul corect, după care să îmbunătăteşti gradual această schiţă iniţială.

In majoritatea domeniilor, prototipurile au fost realizate în mod tradiţional din materiale diferite. Fonturile care trebuiau tăiate în metal au fost iniţial concepute cu o pensulă pe hârtie. Statuetele care trebuiau făcute în bronz erau modelate în ceară. Modelele de tapiţerie erau desenate pe hârtie, cu cerneală. Clădiri care trebuiau construite în piatră erau testate mai întâi în lemn, pe o scară mai mică.

Ceea ce a făcut pictura în ulei aşa de atrăgătoare, când a devenit populară prima dată în secolul al cincisprezecelea, a fost faptul că puteai să faci versiunea finală a produsului din prototip. Puteai face un desen preliminar dacă doreai, dar nu erai obligat să îl respecţi; puteai lucra la detalii, şi chiar să faci schimbări majore, pe măsură ce terminai pictura.

Poţi face acest lucru în software de asemenea. Un prototip nu trebuie să fie doar un model; poţi să îl finisezi într-un produs final. Cred că ar trebui să faci mereu lucrul acesta, când este posibil. Îţi permite să valorifici noile perspective pe care le obţii de-a lungul drumului. Dar poate chiar şi mai important, e bun pentru moral.

Moralul e cheia în design. Sunt surprins că oamenii nu discută mai mult despre el. Unul dintre primii mei profesori de desen mi-a spus: dacă eşti plictisit când desenezi ceva, desenul va arăta plictisitor. De exemplu, presupune că vrei să desenezi o clădire, şi decizi să desenezi fiecare cărămidă individual. Poţi face asta dacă vrei, dar dacă te plictiseşti la jumătatea drumului şi începi să faci cărămizile mecanic în loc de a le observa pe fiecare în parte, desenul va arăta mai rău decat dacă doar ai fi sugerat cărămizile.

A construi ceva prin îmbunătăţirea graduală a unui prototip e bun pentru moral deoarece te ţine în priză. În software, regula mea e: mereu să ai cod funcţional. Dacă scrii ceva pe care ai putea să-l testezi într-o oră, atunci ai o răsplată imediată care să te motiveze. Acelaşi lucru este adevărat şi în artă, şi în particular în pictura în ulei. Majoritatea pictorilor încep cu o schiţă ambiguă şi o îmbunătăţesc gradual. Dacă lucrezi în felul acesta, atunci în principiu nu trebuie niciodată să termini ziua cu ceva care arată ca nefinisat. Într-adevăr, există chiar o zicală printre pictori: "O pictură nu e niciodată finalizată, doar te opreşti să lucrezi la ea." Această idee va fi de asemenea familiară pentru oricine a lucrat în software.

Moralul este un alt motiv pentru care este dificil să designuieşti ceva pentru un user nesofisticat. E dificil să rămâi interesat în ceva care nu îţi place ţie. Pentru a face ceva bine, trebuie să te gândeşti, "wow, e minunat," nu "ce piesă de rahat, acei proşti o vor adora."

Designul înseamnă realizarea de lucruri pentru oameni. Dar nu doar utilizatorul e om. Designerii sunt oameni de asemenea.

Tot acest timp am vorbit despre "designer". Designul trebuie de obicei să fie sub controlul unei singure persoane pentru a fi bun. Şi totuşi se pare că este posibil ca mai mulţi oameni să colaboreze într-un proiect de cercetare. Aceasta mi se pare una dintre cele mai interesante diferenţe între cercetare şi design.

Au fost numeroase instanţe de colaborare în artă, dar majoritatea au semănat mai degrabă ca o împreunare a moleculelor decât ca o fuziune nucleară. Într-o operă e ceva obişnuit ca o persoană să scrie textul şi alta muzica. Iar în timpul Renaşterii, călători din nordul Europei erau deseori angajaţi pentru a face peisajul din fundal pentru picturi italiene. Dar acestea nu sunt cu adevărat colaborări. Ele sunt mai degrabă exemple precum zicala lui Robert Frost, "garduri bune fac vecini buni". Poţi pune una lângă alta instanţe de design bun împreună, dar în cadrul fiecărui proiect individual, cineva trebuie să deţină controlul.

Nu spun că designul bun cere ca o singură persoană să se gândească la toate aspectele. Nu e nimic mai valoros decât sfatul unei persoane în care aveţi încredere. Dar după ce discuţia a luat sfârşit, decizia referitor la ce trebuie făcut trebuie să aparţină unei singure persoane.

De ce cercetarea se poate face prin colaborări şi designul nu? Aceasta este o întrebare interesantă. Nu ştiu răspunsul. Poate, dacă designul şi cercetarea converg, cea mai bună cercetare este de asemenea cel mai bun design, şi de fapt nu poate fi făcută în regim de colaborare. O grămadă dintre cei mai faimoşi oameni de ştiinţă au lucrat singuri. Dar nu ştiu suficient pentru a spune că e un pattern aici. S-ar putea să fie pur şi simplu faptul că mulţi oameni faimoşi de ştiinţă au lucrat când colaborarea era mai puţin întâlnită.

Oricare ar fi povestea în ştiinţe, colaborarea cu adevărat pare să fie foarte rară în arte. Designul realizat de un comitet este sinonim cu designul prost. De ce? Există vreun mod în care putem depăşi această limitare?

Înclin să cred că nu există-- că designul bun cere un dictator. Un motiv este că designul bun trebuie să fie tot dintr-o bucată. Designul nu este doar pentru oameni, dar şi pentru oameni individuali. Dacă designul reprezintă o idee care încape în capul unui individ, atunci ideea va încăpea de asemenea în capul utilizatorului.