Source: https://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html

Terence Parr [autor ANTLR rastavljača generatora itd…]

Ovaj članak pojavio se na reddit i news.ycombinator.com.

Dok moj talent leži u softveru, diplomski studiji su bili u računalnom inženjerstvu (projektiranje i izgradnja digitalnih računala). Jedno opažanje uvijek mi se činilo: računalno inženjerstvo činilo se jasnijim od računalne znanosti (softver za izgradnju). Postoji niz pravila za inženjersko projektiranje koje treba slijediti, a inženjerski projekti imaju mnogo veću vjerojatnost da se razviju od softverskih. Da, postoje neki spektakularni inženjerski neuspjesi, ali, empirijski, pouzdan i koristan softver je teže povući. Da bih ilustrirao svoju točku, razmislite o nevjerojatnim svemirskim sondama koje šaljemo kroz solarni sustav. Sama letjelica radi iznimno dobro, često živeći dulje od svog životnog vijeka. Njihov upravljački softver, s druge strane, mora se stalno mijenjati i krpati kako bi misija održavala zajedno. Ne pokušavam reći da je inženjering jednostavan; nije. Moj cilj je jednostavno objasniti zašto je softver teže dobiti pravo od fizičkih građevinskih projekata općenito i zašto je “softversko inženjerstvo” neprikladan izraz.

Časopis Ekonomist (27. studeni 2004. str. 71) navodi procjene Standish grupe

“…30% svih softverskih projekata je otkazano, gotovo polovica je u proračunu, 60% se smatra neuspjehom organizacija koje su ih pokrenule, a 9 od 10 kasni.”

U članku se dalje ističe da, iako je nekoliko velikih infrastrukturnih projekata završeno na vrijeme i po proračunu, na kraju obično dobijete nešto. Morate ući u područje softvera (ili vojske) kako biste potrošili milijarde i ne dobili ništa za to. Najveći razlog za ovaj rasipan otpad leži u tome što, iako djelomično dovršen građevinski ili infrastrukturni projekt s nedostacima može i dalje biti koristan, softver ili radi ili ne. Budući da je softver uistinu teško ostvariti, često završavamo bez ičega (npr. FBI-jeve deponije ugrađene u računalnu reformu, F.B.I.)

Zašto softver za pisanje nije kao inženjering? Odgovor leži u jednoj temeljnoj razlici s dalekosežnim posljedicama: inženjering je ograničen stvarnim, fizičkim svijetom i softver nije. Iako je očigledno, to je ključna razlika koja objašnjava zašto je razvoj softvera teži za dobivanje prava. Sljedećih nekoliko dijelova istražuje ove posljedice.

Inženjerske komponente postoje u stvarnom svijetu

Projekti fizičkog inženjerstva lakše se vizualiziraju i stoga ih je lakše graditi; Važno je da dotaknete komponente i konačni proizvod rukama. Što se dalje udaljavate od Newtonovog pogleda na fizički svijet koji doživljavamo u svakodnevnom životu, to je projekt teži. Kvantna fizika je teška jer se čestice ne ponašaju kao stijene. Teorija struna, najperspektivnija metoda modeliranja kvantne fizike, primarno je teško razumljiva jer se bavi šest ili sedam dodatnih dimenzija izvan uobičajenih triju prostornih dimenzija. Zamislite pokušava dizajnirati i graditi kuću na Calabi-Yau razvodniku (slika desno je 3-D projekcija a).

Softver nema čak ni koncept dimenzije. Moglo bi se reći da nema linija unutar kojih se boje. Barem za inženjerske projekte iznad kvantne razine, nitko ne očekuje da pronađe strukture koje “prkose zakonima fizike”. To ograničava ono što možete fizički izgraditi i kako ga možete izgraditi, ali barem on pruža dobro definiran svijet u kojem će raditi. Eterični svijet softvera nema taj luksuz, ali naši alati postaju sve bolji. Objektno orijentirano programiranje izumljeno je kako bi softver za pisanje postao poznatiji za naše lovačke skupljače; to jest, napraviti softverske komponente svojstvima i ponašanjem poput objekata u stvarnom svijetu.

Inženjerske komponente međusobno djeluju na predvidljiviji način

Inženjerstvo je manje rizično od softvera jer inženjerstvo ima manje interakcija sastavnih komponenti. Iako manje promjene na jednom dijelu konstrukcije automobila mogu lako utjecati na robusnost sudara drugog, bilo bi neobično da projektna pogreška u svjetlu kupole uzrokuje povremene zastoje motora. U projektu izgradnje kuće, morat ćete prilično teško raditi ispiranje WC-a svaki put kad netko zazvoni.

S druge strane, prilikom izgradnje softvera morate biti hipervigilantni kako biste izbjegli te neželjene interakcije. Jedan od razloga zbog kojih mnogi programeri vole čisto funkcionalno programiranje je nedostatak nuspojava – jednostavno ne postoji način da se toalet nehotice ispere kad zvoni zvono na vratima.

Situacija je još gora u jezicima kao što je C++ bez inherentne zaštite od prelijevanja međuspremnika. Udaljeni fragment koda može nenamjerno mijenjati ponašanje cjelokupne aplikacije mnogo lakše. Zapravo, upravo ta slabost koju većina hakera iskorištava. Prouzročivši prelijevanje međuspremnika, napadač može prisiliti program da otvori rupu u svojoj obrani.

Inženjering ima manje temeljnih promjena u dizajnu sredine

Konačni razlog zbog kojeg je softver teže dobiti pravo od inženjerskih projekata odnosi se na promjene u dizajnu sredine. Fizički svijet nije podjednako pogodan kao nebitan svijet softvera i, stoga, klijenti jednostavno imaju niža očekivanja. Kongres ne ide na NASA-u na pola puta i ne zamoli ih da odu na Mars. Većina inženjerskih projekata zapravo može koristiti metodu vodopada: utvrditi funkcionalne zahtjeve, projektirati, implementirati, testirati. Za većinu softverskih projekata, ovo je recept za katastrofu.

Nažalost, promjene u dizajnu srednjeg tečaja događaju se u softveru cijelo vrijeme – svaki put kada korisnik dobije pogled na pokrenut softver. Zapravo, agilna metoda razvoja softvera izravan je odgovor na sve promjenjive zahtjeve dizajna. Od programera se traži da prihvate promjenu kao priliku. Ipak, stalne promjene u dizajnu ometaju razvojne napore i programeri moraju stalno prerađivati ​​softver kako bi ga spriječili da postane zapetljani, neodrživi nered.

Možda ćete pitati zašto, ako je softver je tako teško dobiti pravu, avioni ne padaju s neba. Ispostavilo se da to povremeno i loše softver je često krivac; npr gledati s električnim sustavom daljinskog upravljanja teških putničkih zrakoplova 320 sudar. Većinu vremena, međutim, hardverski softver za kontrolu zrakoplova, automobila i medicinskih uređaja radi kako se očekuje. Razlog povećane pouzdanosti je trostruki. Prvo, u pitanju su životi i ljudi su vjerojatno oprezniji. Drugo, od razvijatelja softvera se ne traži da mijenjaju softver iz temelja tijekom razvoja. Na primjer, propelerski zrakoplov ne postaje mlazni zrakoplov usred razvoja. Inženjerski tim će početi ispočetka, dok se od softverskog tima obično traži da napravi radikalne promjene u srednjem toku. I konačno, takav se softver bavi kontroliranjem fizičkih uređaja i počinje stjecati neke od prednosti koje se pružaju projektima fizičkog inženjeringa.

Je li razvoj softvera znanost?

Dakle, ako razvoj softvera nije kao inženjering, što je to? Zovemo disciplina računalne znanosti, ali nisam siguran da termin je potpuno prikladno bilo. Vi svibanj podsjetiti na stari vic: „Ako je disciplina‘znanost’u naslovu, vjerojatno nije.” Po mom mišljenju, znanost o otkrivanju i opisuje fizikalne pojave pomoću znanstvene metode. Merriam-Webster opisuje znanstvenu metodu kao:

“Načela i procedure za sustavno traženje znanja koje uključuje prepoznavanje i formuliranje problema, prikupljanje podataka kroz promatranje i eksperimentiranje, te formuliranje i testiranje hipoteza.”

Taj opis smacks ispravljanje pogrešaka više od samog čina pisanja softvera. Računalna znanost o izgradnji stvari kao što su inženjering, ali bez luksuza alatni okvir i komponente uzeti iz fizičkog svijeta. Nitko nije razrađen pouzdane i učinkovite postupke za izgradnju velikih komada softvera kao što su inženjeri učinili za fizičke projekt. Kao Alan Kay kaže, softver je „inženjering svojevrsno… ali samo vrši silu”. Razgovor s Alan Kay:

“Ako pogledate softver danas, kroz objektiv povijesti inženjeringa, to je svakako nekakav inženjering – ali to je vrsta inženjeringa koju ljudi bez koncepta luka nisu učinili. Većina softvera danas je vrlo slična egipatskom piramida s milijunima cigli nagomilanih jedna na drugu, bez strukturalnog integriteta, ali samo od strane grube sile i tisuće robova.”

Pisanje softvera više je umjetnost nego inženjerska disciplina

Pisanje softvera najsličnije je pisanju romana romana. Pisanje romana također je čin stvaranja u neograničenom i eteričnom mediju s nekoliko dobro uspostavljenih pravila gradnje. Poznato nam je dobro pisanje kad ga vidimo, ali teško je podučavati. Pisanje iskustva i povratne informacije boljeg pisca (kodera) je najpouzdaniji način da postanete dobar pisac (koder). Bez dobro shvaćenog procesa, softver će ostati više umjetnost nego znanost. Pojam “softversko inženjerstvo” više je cilj nego što zapravo pišemo softver.