Înainte să scriem o singură linie de cod, desenăm sistemul. Casete pentru locurile unde se întâmplă munca, săgeți pentru locurile unde datele trec dintr-o mână în alta și un semn în fiecare punct unde o persoană face manual ceea ce ar trebui să facă o mașină. Pare lent. Este cel mai rapid lucru pe care îl facem în tot proiectul.
Codul este un loc scump în care să gândești
Codul te forțează la o sutimă de decizii mărunte înainte să înțelegi forma problemei: denumiri, tipuri, granițe de fișiere, cazuri limită. Iei aceste decizii prea devreme și rămâi legat de o structură aleasă cât încă erai confuz. Un desen îți arată tot sistemul dintr-o privire — ieftin, pe o singură pagină — și îl poți rearanja înainte ca ceva să fie fixat în software.
Majoritatea problemelor de software sunt, de fapt, probleme de desen
Defecțiunea care costă o companie o săptămână rareori e o greșeală de tastare. Sunt două sisteme care nu au fost niciodată gândite să comunice, un număr introdus de două ori care nu se potrivește cu el însuși, un pas care merge doar pentru că o anumită persoană își amintește să îl facă în fiecare vineri. Nimic din toate astea nu apare la un code review. Toate apar în momentul în care încerci să desenezi fluxul și săgețile refuză să se conecteze.
Un desen este o conversație
Când punem o schemă în fața persoanei care chiar conduce operațiunea, se întâmplă ceva util: poate arăta cu degetul spre ea. „Nu așa funcționează.” „Ai uitat aprobarea aici.” „Raportul ăsta merge la doi oameni, nu la unul.” Nu poți obține acest feedback dintr-un cod, pentru că oamenii care au răspunsurile nu citesc cod. Citesc imagini ale propriei munci și le corectează instant.
Ce prinde desenul înainte să devină scump
Introducerea dublă a datelor. Integrarea de care depind toți și pe care nu o deține nimeni. Ritualul manual de export-reformatare-reimport care mănâncă discret o după-amiază pe săptămână. Raportul care există doar pentru că un sistem nu putea vorbi cu alt sistem. Pe hârtie, acestea sunt ieftin de văzut și ieftin de reparat. În producție, sunt motivul pentru care un proiect întârzie.
Apoi programăm — și merge repede
Odată ce desenul e agreat, codul devine aproape mecanic. Nu există surprize de arhitectură, pentru că arhitectura este chiar lucrul despre care ne-am contrazis deja pe hârtie. Deciziile interesante au fost luate cât încă erau ieftin de schimbat. Ce rămâne este execuția, iar execuția este partea la care ne pricepem.
De aceea fiecare studiu de caz de pe acest site a început ca o schiță înainte să devină un sistem. Dacă operațiunea ta pare ținută laolaltă cu foi de calcul și scotch, primul lucru pe care îl vom face nu este să îți dăm o ofertă. Este să o desenăm — și să îți arătăm unde stă de fapt fricțiunea.
