Kriza 1968: Sastanak u bavarskoj šumi

Garmisch-Partenkirchen, listopad 1968. Alpsko sunce, snijeg već sjeda na vrhove, hotel diše na bavarski način — drveni balkoni, miris smreke, konobar koji ti nudi pivo prije nego što stigneš baciti pogled na jelovnik. Razglednica, čista i uredna, baš onakva kakvu bi poslao kući mami s natpisom „stigao živ i zdrav”. Račun plaća NATO — da, onaj vojni savez, ali ovaj put ne šalje tenkove nego znanstvenike, jer je itekako zainteresiran da mu softver u raketama i radarima radi kako treba. Sve zvuči kao skijaški izlet za dosadne birokrate koji su odlučili spojiti posao i planinski zrak.

Samo što unutra, u konferencijskoj dvorani gdje je zrak gušći od dima cigareta nego od kisika, pedesetak ljudi iz jedanaest zemalja sjedi s izrazima lica kakve imaš kad ti mehaničar kaže da je s autom „gore nego što sam mislio”. Nisu tu na skijanju. Tu su zato što je nešto, negdje između bušenih kartica i magnetnih vrpci — u to doba to su bili mediji za unos i pohranu podataka, ono što danas radi tvrdi disk ili USB stick, samo što je bušena kartica papir s rupicama koje računalo „čita” kao nule i jedinice, a magnetna vrpca izgleda i radi kao traka iz starog kasetofona, samo puno veća i sporija — i beskonačnih redova koda, krenulo po zlu. Svi to znaju, samo nitko dosad nije to izgovorio naglas, pred kolegama, pred šefovima, pred cijelom strukom.

Godina je 1968. — ista godina u kojoj će, u San Franciscu, jedan čovjek stajati na pozornici i mišem pomicati kursor kao da to ništa ne znači, kao da je budućnost već stigla i samo čeka da je pokupiš. Ovdje, u Bavarskoj, nitko ne demonstrira budućnost. Ovdje ljudi priznaju da sadašnjost ne funkcionira.

Dvije strane istog novčića, bačenog u zrak iste godine: na jednoj strani čarolija Douglasa Engelbarta — onog čovjeka s pozornice iz prošlog poglavlja koji je upravo izumio miš i s njim obećanje da će računala jednog dana raditi za nas; na drugoj strani gomila umornih inženjera koja ne zna kako isporučiti ni ono što računala već danas obećavaju. Engelbart i njegov miš — na jednoj strani planine. Ovi ljudi, s planinskim vidikom kroz prozor koji nitko ne gleda — na drugoj.

Riječ koju još nitko nije formalno izgovorio visi u dvorani kao magla ispod planinskog vrha — čeka da je netko uhvati, imenuje, stavi u naslov: „kriza softvera” (software crisis). Dvije riječi kojima će se, ukratko, zvati ono što se dešava kad projekt kasni, budžet se prelijeva kao lonac na štednjaku, a gotov sustav puca po šavovima od grešaka koje niko nije stigao uloviti. Dvije riječi koje će, kad izađu iz te dvorane, žuljati struku sljedećih šezdesetak godina — i, spojler, žuljaju je i danas, dok ti čitaš ovo na uređaju čiji softver je, budimo iskreni, opet u kašnjenju.

Šezdesetih se vjerovalo da je računalo čarobni štapić. Kupiš mainframe — ogromno, skupo centralno računalo veličine ormara ili cijele sobe, kakvim su se tada služile samo velike institucije poput banaka, sveučilišta i vlada, jer si obični smrtnik takvu igračku nije mogao priuštiti — zapošljiš par ljudi s naočalama i kravatom, i za šest mjeseci imaš sustav koji vodi banku, avionsku kompaniju ili lansiranje rakete. Papir je to podnosio. Stvarnost, po običaju, nije.

Do 1968. gomila je projekata već pokazala da papir laže. Ne jedan, ne dva — desetci velikih sustava, naručenih s jasnim rokom i jasnim budžetom, kasnili su godinama i trošili triput više novca nego što je ugovoreno. Vojska je naručivala sustave za vođenje i kontrolu koji su trebali biti gotovi za šesnaest mjeseci, a stizali su, ako su stizali, za četiri godine — s računom koji je izgledao kao da je netko zaboravio staviti zarez. Avionske kompanije naručivale su sustave rezervacija koji su trebali povezati šaltere u desecima gradova, a dobivale su verzije koje su padale čim bi u istom trenutku dvoje ljudi pokušalo kupiti kartu za isti let.

I nije to bilo zato što su ljudi koji su to radili bili glupi. Bili su, dapače, najbolji koje je struka imala — s doktoratima, s ratnim iskustvom u dešifriranju i balistici, s onim tipom samopouzdanja koje ide uz pripadnost eliti koja je upravo pobijedila u svemirskoj utrci. Problem je bio dublje od pameti. Problem je bio što nitko, baš nitko, nije znao kako se procjenjuje koliko će trebati vremena da se napiše nešto što još nikad nije napisano — a to je, priznajmo, dosta veliki problem kad ti upravo taj netko obećava vojsci da će sustav biti gotov za šesnaest mjeseci.

IBM je to upravo bolno naučio na projektu OS/360 — operativnom sustavu za njihove mainframeove iz šezdesetih — projektu koji je, istina, uspio, ali s cijenom koju IBM nikad nije javno priznao u punom iznosu. Pet tisuća ljudi na jednom operativnom sustavu, budžet koji je nadmašio ono što je Amerika trošila na neke svemirske programe, i knjiga napisana kao posthumna ispovijed čovjeka koji je vodio taj cirkus — Fred Brooks i njegov »Mitski čovjek-mjesec«, koji je iz te agonije izvukao pouku da dodavanje ljudi na kasni projekt kasni projekt samo još više. Ako je to bio uspjeh, pomisliš, kako uopće izgleda neuspjeh?

E, to je upravo pitanje koje je 1968. počelo tištati cijelu industriju odjednom, a ne samo IBM. Jer OS/360 nije bio iznimka. Bio je normala, samo najskuplja i najvidljivija verzija normale.

To je jaz koji je 1968. već bio bolno vidljiv, samo ga još nitko nije imao pravo ime za njega. Postojali su izvještaji, interni memorandumi, poneka gnjevna pisma menadžmentu — ali nije postojala riječ koja bi to sažela u nešto što se moglo staviti na naslovnicu, na dnevni red, na razglednicu konferencije. Ljudi u odijelima i kravatama znali su da nešto ozbiljno ne valja, ali su to i dalje zvali „problemima s rokovima” ili „privremenim kašnjenjima”, kao da je riječ o zakasnjelom vlaku, a ne o strukturnom problemu cijele profesije.

Zanimljivo je koliko je dugo trebalo da netko naglas izgovori ono što je svima bilo pred nosom. Ne zato što su bili slijepi — nitko koji je gledao proračune OS/360-a nije mogao biti slijep na to — nego zato što priznati problem znači priznati da struka koju su izgradili, struka u koju su uložili karijeru, možda nema temelje kakve su mislili da ima. A to je, priznajmo, teže progutati nego bilo kakvo kašnjenje u isporuci.

Trebao je doći poziv — formalan, uglađen, s pečatom NATO-a u zaglavlju (da, baš onog vojnog saveza; ispada da je i vojska shvatila da im projekti kasne i pucaju po šavovima, pa su odlučili platiti da netko konačno kaže naglas što se događa) — da se skupina tih ljudi konačno nađe na jednom mjestu i izgovori riječ koju su svi već mjesecima šaptali po koridorima. Mjesto su odabrali dobro: dovoljno lijepo da uljepša neizbježno, dovoljno izolirano da nitko ne pobjegne prije nego što stvar bude izgovorena do kraja.

Zamisli konferenciju na kojoj ljudi ne dolaze prodavati sebe. Nema slajdova s uzlaznim krivuljama, nema startup predstavljanja, nema nikoga tko govori kako mu je proizvod „promijenio način na koji svijet razmišlja o softveru”. Upravo to se dogodilo u Garmischu — i baš zato je ostalo upamćeno pedeset i osam godina kasnije, dok su tisuće drugih konferencija otišle u zaborav zajedno s hotelskim jelovnicima na kojima su bile najavljene.

NATO je pozvao pravu ekipu: preko pedeset stručnjaka iz jedanaest zemalja, ljudi koji su u tom trenutku bukvalno pisali softver za rakete, banke, telefonske centrale i svemirske programe — dakle ljudi koji su iz prve ruke znali kako izgleda ono što će konferencija nazvati »krizom softvera«: projekti koji kasne mjesecima, budžeti koji cure kao rešeto i sustavi puni grešaka koje isplivaju baš kad ih nitko ne treba. Nisu se svi međusobno poznavali, ali svi su prepoznali istu stvar na licima drugih čim su ušli u salu — onaj pogled čovjeka koji zna da mu je projekt u kasnini, samo ne zna hoće li to priznati javno.

I onda je netko priznao. Pa drugi. Pa treći. Zbornik s te konferencije (da, postoji, da, možeš ga danas pročitati kao PDF i osjećati se prepoznato) čita se kao da ga je netko napisao jučer na Hacker Newsu nakon lošeg sprinta (to je, ukratko, dvotjedni rok u kojem programerski tim mora isporučiti dogovoreni dio posla — a kad ne stigne, atmosfera je otprilike kao u Garmischu '68.). Jedan je učesnik rekao da grade sustave koji su »nepouzdani, isporučeni kasno i prekoračuju budžet«. Drugi je dodao da je programiranje »umjetnost, ne znanost« — i to nije rekao kao kompliment, rekao je to kao dijagnozu problema, jer umjetnost se ne planira, ne procjenjuje i ne kontrolira. A ti znaš, ili ćeš znati, koliko upravo to boli menadžera koji mora obećati datum isporuke.

Ono što danas nedostaje na konferencijama — pa i na sastancima s klijentima, pa i na godišnjim retrospektivama u vlastitoj firmi — jest baš ta razina iskrenosti. U Garmischu se nitko nije branio da je kriza tuđa. Nitko nije rekao da je njegov timski proces drukčiji, da je njegov projekt izuzetak, da je kod njega sve pod kontrolom pa se ovo odnosi na kolege iz druge zgrade. Priznali su, gotovo kolektivno, da je problem sistemski — da nije riječ o lošim programerima, nego o lošem razumijevanju onoga što programiranje uopće jest kao aktivnost velikih razmjera.

To je bio pravi uspon priče, ne pad. Jer prije nego riješiš problem, moraš imati pedesetak vrlo pametnih ljudi u istoj sobi koji su spremni reći: da, mi ne znamo što radimo, i to nas plaši. Edsger Dijkstra je bio tamo (naravno da je bio tamo, on je bio na svakoj konferenciji gdje je trebalo nekome reći u lice da je u krivu), a bilo je i inženjera iz zrakoplovne industrije koji su govorili stvari koje bi danas prošle nezapaženo na bilo kojem „standup meetingu” (kratkom jutarnjem sastanku tima, obično stojeći, na kojem se svi ukratko izvijeste tko radi što): da specifikacije nikad nisu gotove kad se kod počne pisati, da je testiranje naknadna misao, da se komunikacija između tima koji piše i tima koji naručuje gubi negdje na putu kao pošta bez markice.

Ključna razlika prema današnjim panelima na kojima se priča isto to: u Garmischu nitko nije imao gotov odgovor koji se prodaje. Nitko nije stajao na pozornici s certifikatom u ruci govoreći „mi smo riješili baš taj problem, dođite na naš webinar”. Bila je to soba puna ljudi koji su tek shvatili razmjere problema i pošteno rekli — nemamo pojma kako se ovo zove, ali nazovimo ga nekako, jer imenovanje je prvi korak prema tome da ga barem pokušaš dograbiti.

Sad, ono što ćeš danas naći u svakom udžbeniku, u svakom nazivu radnog mjesta, na svakoj pozivnici za posao na LinkedInu — »softversko inženjerstvo« (engl. »software engineering«) — nije izmišljeno kao opis stvarnog stanja stvari. Izmišljeno je kao udarac šakom o stol. Friedrich Bauer, koji je smislio naziv konferencije, kasnije je priznao da je riječ »inženjerstvo« ubačena namjerno, provokativno, skoro pa sarkastično. Poruka nije bila „mi smo inženjeri, evo naše discipline” — poruka je bila: trebali bismo biti inženjeri, a nismo ni blizu, pa da vidimo koliko nas boli kad to izgovorimo naglas.

I bolilo je. Zamisli da radiš neki posao — bilo koji, građevinu, elektroniku, avijaciju — i netko ti na vrata stavi natpis s nazivom struke za koju svi znaju da je nemaš. Elektroinženjer ima proračune, tablice, norme koje, ako ih prekršiš, netko pogine — i to se zna unaprijed, provjerljivo, brojkama. Programer 1968. ima osjećaj. Ima instinkt. Ima „valjda će raditi” i noć bez spavanja prije demonstracije. Nazvati to „inženjerstvom” nije bio opis stanja — bio je zadatak iz domaće zadaće, napisan na ploči veličine cijele industrije.

E sad, evo stvari koju treba razumjeti da bi cijela rasprava imala smisla, a ne da zvuči kao svađa oko riječi za riječ. Inženjerstvo, u svakom drugom polju, znači da postoje ograničenja fizike koja se ne pregovaraju. Most se sruši ako pogrešno računaš opterećenje, i to nije mišljenje — to je Newton koji te ne pita za dopuštenje. Softver, u principu, nema tu vrstu ograničenja. Možeš napisati kod koji je logičko čudovište, koji krši svako pravilo dobrog ukusa, i on će i dalje raditi, možda čak i dobro, sve dok jednog dana ne prestane. Fizika ti ne kaže odmah da si pogriješio. Kaže ti to godinama kasnije, na »produkciji« — tako se u branši zove trenutak kad se program stvarno pokreće za prave korisnike, a ne samo u sigurnom testnom okruženju — i, dakako, u tri ujutro.

Zato je diskusija koju je pokrenuo Garmisch bila, u srži, filozofska: je li softver uopće nešto što se može inženjerski projektirati, s nacrtima prije građenja i provjerljivim proračunima — ili je po prirodi bliže pisanju romana, gdje ideja i realizacija rastu zajedno, kroz iteraciju, kroz osjećaj, kroz „sad ovo zvuči bolje”? Neki od najpametnijih ljudi na tom skupu tvrdili su da je tražiti inženjersku disciplinu u softveru kao tražiti od pjesnika da poštuje statiku. Drugi su tvrdili — i ovi su, budimo pošteni, na kraju uglavnom pobijedili u praksi — da je ta romantika luksuz koji si mogao dopustiti dok su tvoji programi bili igračke, a ne sustavi koji vode banke i rakete.

I tu, prijatelju, upada jedna stvarčica koju ćemo detaljnije secirati kasnije u ovoj knjizi, u poglavlju gdje ćemo doslovno otvoriti taj leš na stol i pogledati mu u crijeva: pitanje je li softversko inženjerstvo ikad zapravo postalo inženjerstvo, ili je ostalo zanat koji se samo tako oblači za posao. Ostavimo to tamo gdje mu je mjesto — reći ćemo samo da je odgovor kompliciraniji i neugodniji nego što bi struka htjela priznati, i da ćemo se u to poglavlje vratiti s puno više zloće.

Ono što je bitno zapamtiti iz 1968. jest da je sama etiketa „softversko inženjerstvo” bila aspiracija, ne opis, i da je to svima u toj dvorani bilo poprilično jasno već onda. Nitko nije izašao iz Garmischa misleći »sad smo mi inženjeri«. Izašli su misleći »ajme, koliko posla imamo da to i postanemo«. Pedesetak godina, tisuće metodologija, milijuni sati konferencijskih panela kasnije, ta rečenica se — začudo — nije puno promijenila. Samo je iznos posla postao veći, a broj ljudi koji tvrde da su ga već obavili — nažalost, još veći.

Dobro, dijagnozu imaš: softver kasni, softver puca, softver je skuplji od hardvera na kojem radi. Cijela ekipa u Garmischu sad radi ono što inženjeri rade kad im se sruši most — traže rješenje koje se može ponoviti, umnožiti i staviti u priručnik. Ako je građevinarstvo prije stotinu godina prošlo kroz istu fazu — od majstora koji u glavi zna koliko cigli treba, do statike, normi i papira koji netko mora potpisati prije nego što se zgrada digne — zašto softver ne bi mogao istim putem? Pa je konferencija, sasvim logično, počela nabacivati recepte.

Prvi recept, kao što smo vidjeli: formalne metode. Nema debagiranja u tri ujutro, nema pucanja u produkciji, nema onog telefonskog poziva koji te budi. Samo dokaz, čist kao teorem u geometriji. Edsger Dijkstra i ekipa — inače legenda struke, čovjek po kojem se danas zove poznati algoritam za pretragu najkraćeg puta — ovo su shvaćali ozbiljno, ne kao usputnu foru: vjerovali su da je programiranje zapravo grana matematike koja je nekako zalutala među inženjere.

Drugi recept, i ovaj je onaj koji te treba zaboljeti malo više: komponente. Kao što smo već spomenuli, McIlroy je na konferenciji sanjao industriju masovno proizvedenih softverskih dijelova — katalog blokova koje samo uzmeš s police i sastaviš, umjesto da svaku liniju pišeš od nule.

Zvuči poznato? Trebalo bi. Upravo si to opisao — onaj isti npm, pip, Maven Central, cargo i sličnu ekipu koje smo već upoznali. McIlroy je to vidio 1968. Trebalo je proći dobrih tridesetak godina i cijela internetska infrastruktura da se ta ideja stvarno ostvari u obliku koji poznaješ danas. On je zamislio dućan; svijet mu je dao alat za dostavu tek kad je imao gdje dostavljati.

Komponente su propale iz drugog razloga, prizemnijeg i, iskreno, ljudskijeg. Nije postojala infrastruktura da se te komponente pronađu, distribuiraju, verzioniraju, plate ili — ono najgore — da se provjeri da onaj blok koji si preuzeo od nekog stranca u drugoj tvrtki uopće radi ono što tvrdi da radi. Nije bilo interneta u smislu u kojem ga zamišljaš, nije bilo standardiziranih formata, nije bilo ni zajedničkog jezika između strojeva iz različitih fabrika. McIlroy je nacrtao kartu grada koji još nije bio sagrađen. Ceste, struja, poštanski sustav — sve je to falilo. Ideja je čekala civilizaciju koja bi ju mogla nositi.

Pa što ostaje s konferencije, ako oba velika recepta — matematika koja štiti od grešaka i tržnica koja štedi vrijeme — u tom trenutku padnu na testu stvarnog svijeta? Ostaje ono najneugodnije od svega: spoznaja da problem nije tehnički. Nije nedostajalo pameti u Garmischu, ni ideja, ni ambicije. Nedostajalo je — i ovo je rečenica koja će te pratiti kroz ostatak ove knjige — nešto puno dosadnije. Disciplina, organizacija, i vrijeme da svijet stigne do ideje koja ga je već čekala.

I sad, gotovo šezdeset godina kasnije, možemo napraviti nešto što oni u Garmischu nisu mogli — pogledati unatrag i vidjeti cijeli film, ne samo jednu scenu. Pa krenimo redom. Šezdesetih i sedamdesetih dijagnoza je bila: kod je špageti, nitko ne zna što radi funkcija petsto redaka dalje, treba disciplina. (Funkcija je, ako nisi siguran, samo imenovani blok koda koji radi jedan konkretan zadatak — zamisli ga kao gumb na aparatu za kavu s natpisom „Espresso”: pritisneš ga, dobiješ espresso, i ne moraš znati kako aparat unutra mljevi zrno.) Krivac broj jedan zvao se goto — naredba koja je programu dopuštala da bez reda i najave skoči na bilo koji drugi dio koda, kao da ti netko dok čitaš knjigu odjednom kaže „sad idi na stranicu 340”, pa odande na stranicu 12, i tako unedogled, dok priča ne postane nemoguća za pratiti. Lijek: strukturirano programiranje. Goto se proglašava zlom, uvode se petlje i funkcije kako ih danas znaš, i na trenutak — samo na trenutak — svijet izgleda spašen.

Onda osamdesete i devedesete. Nova dijagnoza: strukturirano programiranje je super za male programe, ali kad ih spojiš tisuću, opet je kaos, samo uredniji kaos. Lijek: objektno orijentirano programiranje. Enkapsulacija, nasljeđivanje, apstrakcija — sad će klase (zamisli ih kao kalupe za objekte, recimo kalup „Vozilo”) modelirati stvarni svijet: enkapsulacija znači da kalup sakriva svoje unutarnje mehanike i drugima pokazuje samo dugmiće koje smiju pritisnuti, nasljeđivanje znači da novi kalup, recimo „Auto”, može naprosto preuzeti sve što već ima kalup „Vozilo” i dodati svoje osobine bez da se sve piše iznova, a apstrakcija znači da te uopće ne mora zanimati kako je nešto napravljeno — dovoljno je znati što radi, kao kad vozač auta ne mora znati kako radi motor da bi pritisnuo papučicu gasa. Sad će se kod ponovno koristiti, sad je gotovo. Ako si ikad sjedio na satu gdje ti netko crta dijagram Auto nasljeđuje Vozilo, znaš da si upravo prisustvovao ovom trenutku povijesti, samo trideset godina kasnije i s puno manje entuzijazma.

Devedesete prelaze u dvijetisućite, i dijagnoza se mijenja opet: problem nije jezik, problem je proces. Vodopadni model, gdje se sve specificira unaprijed pa se šest mjeseci kasnije isporuči proizvod koji nitko više ne želi, proglašava se krivcem. Lijek: Agile (jednostavno rečeno, filozofija „radimo u malim koracima i prilagođavamo se usput, umjesto da sve planiramo unaprijed i onda se molimo”). Isti oni sprintovi i stand-upovi od kojih smo krenuli, samo sad službeno uvedeni kao doktrina; iteracije znače da se proizvod gradi u malim, ponavljajućim koracima, a ne u jednom velikom skoku; a „fail fast” je ideja da je bolje brzo otkriti grešku i naučiti iz nje nego je skrivati mjesecima. Manifest agilnog razvoja iz 2001. čita se skoro kao dvanaest teza zakucanih na vrata katedrale, s istom energijom kao Garmisch — grupa ljudi koja kaže: dosta nam je, ovo ne radi, mora postojati bolji način.

I tu dolazimo do onoga što je Garmisch, u svojoj tihoj panici, zapravo prvi naslutio, a što šezdeset godina alata i metodologija nije uspjelo opovrgnuti: možda „kriza softvera” nije kvar u sustavu koji čekamo da se popravi. Možda je to samo iskreno ime za ono što softver jest. Gradiš nešto nevidljivo, za ljude koji ne znaju točno što žele, u vremenu koje im nikad nije dosta, s alatima koji su uvijek jednu generaciju iza problema koji rješavaju. To nije kvar. To je posao.

Svaka generacija inženjera dođe do istog otkrića, obično negdje oko tridesete godine karijere, kad prvi put isporuči nešto na vrijeme i shvati da je to bila iznimka, a ne pravilo. Onda izmisli novu riječ za istu staru nadu — strukturirano, objektno, agilno, a sad valjda i „AI-native” — i krug se zatvori. Za pedeset godina netko će pisati poglavlje o tome kako je 2025. bila godina kad su svi mislili da će prompt riješiti ono što nije mogao ni goto s početka poglavlja, onaj isti koji je generacijama programera ostavio u amanet čuveni pojam „kod od špageta” — zamršen, nemoguć za pratiti, spoj koji se raspada čim ga povučeš za jednu nit.

Zato Garmisch nije zaboravljena konferencija u alpskom hotelu koju spominjemo iz pijeteta prema starim gospodinima u odijelima. Garmisch je trenutak kad je struka prvi put iskreno rekla svoje ime, i to ime, začudo, i danas piše na vratima svake firme koja kasni s isporukom. Samo što se sad to zove sprint retrospective — sastanak na kraju radnog ciklusa gdje tim raspravlja što je pošlo po zlu — a ne kriza. Zvuči ljepše. Boli isto.