De ce scrierea de software nu este ca ingineria

Sursă Originală: https://parrt.cs.usfca.edu/doc/software-not-engineering.html

Terence Parr [autor al generatorului de parser ANTLR etc …]

Acest articol a apărut pe reddit și news.ycombinator.com .

În timp ce talentul meu este în software, studiile mele au fost în inginerie informatică (proiectarea și construirea calculatoarelor digitale). O observație ma lovit întotdeauna: ingineria calculatoarelor părea mai simplă decât informatica (software-ul de construcție). Există un set de reguli de proiectare de proiectare care urmează să fie urmărite, iar proiectele de inginerie sunt mult mai probabil să funcționeze decât proiectele software. Da, există unele eșecuri spectaculoase de inginerie, dar software-ul empiric, fiabil și util este mai greu de tras. Pentru a ilustra punctul meu de vedere, luați în considerare sursele uimitoare de spațiu pe care le trimitem în întregul sistem solar. Nava spațiale lucrează foarte bine, trăind adesea mult timp după viața de proiectare. Software-ul lor de control, pe de altă parte, trebuie să fie constant modificat și patch-uri în zbor pentru a menține misiunea împreună. Nu incerc sa spun ca ingineria este usoara; nu este. Scopul meu este de a explica de ce software-ul este mai greu de obținut decât proiecte fizice de construcție în general și de ce “ingineria software” este un termen necorespunzător.

Revista The Economist (27 noiembrie 2004, p. 71) citează estimările Grupului Standish că” 

… 30% din toate proiectele software sunt anulate, aproape jumătate au peste buget, 60% sunt considerate eșecuri de către organizațiile care le-au inițiat și 9 din 10 vin târziu ” .

Articolul continuă să sublinieze că, deși puține proiecte de infrastructură mari sunt finalizate la timp și la buget, de obicei obțineți ceva în cele din urmă. Trebuie să intrați în domeniul software-ului (sau al militarilor) pentru a cheltui miliarde și a nu obține nimic pentru asta. Cel mai mare motiv pentru această pierdere risipită constă în faptul că, în timp ce o clădire parțial finalizată sau un proiect de infrastructură cu defecte poate fi în continuare util, software-ul funcționează sau nu. Deoarece software-ul este greu de obtinut, deseori ne sfarsim cu nimic (de exemplu, FBI se opreste la reparatia computerului , FBI se confrunta cu un nou compromis in retehnologizarea calculatoarelor ).

De ce scrierea de software nu este ca ingineria? Răspunsul constă într-o singură diferență fundamentală cu ramificații profunde: ingineria este constrânsă de lumea fizică reală, iar software-ul nu este. În timp ce este evident, aceasta este diferența crucială care explică de ce dezvoltarea software-ului este mai greu de obținut. Următoarele secțiuni explorează aceste ramificații.

Componentele de inginerie există în lumea reală

Proiectele de inginerie fizică sunt mai ușor de vizualizat și, prin urmare, mai ușor de construit; heck, de fapt, puteți atinge componentele și produsul final cu mâinile. Cu cât te afli mai departe de viziunea Newtoniană asupra lumii fizice pe care o trăim în viața de zi cu zi, cu atât proiectul este mai dificil. Fizica cuantică este dificilă deoarece particulele nu se comportă ca niște pietre. String teoria, metoda cea mai promițătoare de modelare a fizicii cuantice, este în primul rând dificil de înțeles, deoarece se referă la șase sau șapte dimensiuni suplimentare dincolo de cele trei dimensiuni obișnuite. Imaginați-vă că încercați să proiectați și să construiți o casă pe un distribuitor Calabi-Yau (imaginea din dreapta este o proiecție 3D).

Software-ul nu are nici măcar conceptul de dimensiune. S-ar putea spune că nu există linii în care să se coloreze. Cel puțin pentru proiecte de inginerie deasupra nivelului cuantic, nimeni nu se așteaptă să găsească structuri care “sfidează legile fizicii”. Acest lucru limitează ceea ce puteți construi fizic și cum îl puteți construi, dar cel puțin oferă o lume bine definită în care să lucrați. Lumea eterică a software-ului nu are acest lux, dar instrumentele noastre se îmbunătățesc. Programarea orientată pe obiecte a fost inventată pentru a face software-ul de scriere mai familiar pentru creierul nostru de culegători de vânători; adică să facă componente software cu proprietăți și comportamente ca obiectele din lumea reală.

Componentele inginerice interacționează în moduri mai previzibile

Ingineria este mai puțin riscantă decât software-ul, deoarece ingineria are mai puține interacțiuni componente. În timp ce modificările minore ale unei părți a structurii unei mașini pot afecta cu ușurință robustețea de accident a altui, ar fi neobișnuit ca un defect de proiectare în lumina domului să provoace blocuri intermitente ale motorului. Într-un proiect de construcție la domiciliu, va trebui să lucrați destul de mult pentru a face o spălare la toaletă de fiecare dată când cineva a sunat la ușa de la ușă.

Când construiți software-ul, pe de altă parte, trebuie să fii hipervigilant pentru a evita aceste interacțiuni nedorite. Unul dintre motivele pentru care mulți programatori, cum ar fi programarea funcțională pură, este lipsa de efecte secundare – pur și simplu nu există nicio modalitate de spălare a toaletei în mod inadecvat atunci când soneria sună.

Situația este și mai proastă în limbi precum C ++ fără protecție inerentă a tamponului. Un fragment fragmentat de cod poate modifica neintenționat comportamentul aplicației globale mult mai ușor. De fapt, această vulnerabilitate particulară exploatează majoritatea hackerilor. Prin provocarea unei suprapuneri de tampon, un atacator poate forța programul să deschidă o gaură în apărarea sa.

Ingineria are mai puține modificări fundamentale de proiectare la jumătatea distanței

Ultimul motiv pentru care software-ul este mai greu de obținut decât proiectele de inginerie se referă la schimbările de proiectare la jumătatea drumului. Lumea fizică nu este la fel de maleabilă ca lumea nesubstanțială a software-ului și, prin urmare, clienții au pur și simplu așteptări mai mici. Congresul nu merge la NASA la jumătatea unui lună și le cere să meargă pe Marte în schimb. Majoritatea proiectelor inginerești sunt capabile să utilizeze metoda de proiectare a cascadei: să determine cerințele funcționale, să proiecteze, să implementeze, să testeze. Pentru majoritatea proiectelor software, aceasta este o rețetă pentru dezastru.

Din păcate, schimbările de design la jumătatea drumului se întâmplă tot timpul în software-ul – de fiecare dată când clientul obține o privire asupra software-ului care rulează. De fapt, metoda de dezvoltare a software-ului agil este un răspuns direct la cerințele de design mereu în schimbare. Programatorilor li se cere să accepte schimbarea ca o oportunitate. Totuși, modificările constante ale designului împiedică eforturile de dezvoltare, iar dezvoltatorii trebuie să refacă în mod constant software-ul pentru a nu-l împiedica să devină o mizerie încurcată și neîncetată.

S-ar putea să întrebați de ce, dacă software-ul este atât de greu pentru a avea dreptate, avioanele nu cad din cer. Se pare că fac uneori și software-ul rău este de multe ori vinovatul; de exemplu, urmăriți un accident rutier Airbus 320. De cele mai multe ori, însă, software-ul de control al hardware-ului pentru avioane, mașini și dispozitive medicale funcționează conform așteptărilor. Motivul creșterii fiabilității este de trei ori. În primul rând, sunt în joc vieți și oamenii sunt mai atenți. În al doilea rând, dezvoltatorii de software nu sunt rugați să modifice software-ul în mod fundamental în timpul dezvoltării. De exemplu, un avion antrenat de elice nu devine avion de reacție în mijlocul dezvoltării. O echipă de inginerie ar începe de la început, în timp ce o echipă de software este de obicei cerută să facă schimbări radicale în mijlocul fluxului. Și, în sfârșit, astfel de software-uri se ocupă cu controlul dispozitivelor fizice și încep să câștige unele dintre avantajele oferite de proiectele de inginerie fizică.

Este dezvoltarea de software o știință?

Deci, dacă dezvoltarea de software nu este ca ingineria, ce este? Noi numim disciplina informatica, dar nu sunt sigur ca acest termen este complet potrivit fie. Puteți aminti vechea glumă: “Dacă o disciplină are” știință “în titlu, probabil că nu este.” În opinia mea, știința este despre descoperirea și descrierea fenomenelor fizice folosind o metodă științifică . Merriam-Webster descrie metoda științifică ca fiind:” 

Principii și proceduri pentru urmărirea sistematică a cunoștințelor care implică recunoașterea și formularea unei probleme, colectarea datelor prin observație și experiment și formularea și testarea ipotezelor ” .

Această descriere dă greșelile de depanare mai mult decât actul scris al software-ului. Știința informatică are în vedere construirea de lucruri precum ingineria, dar fără luxul unei cutii de scule și a componentelor preluate din lumea fizică. Nimeni nu a elaborat proceduri fiabile și eficiente pentru construirea unor bucăți mari de software, pe care inginerii le-au făcut pentru proiectul fizic. După cum afirmă Alan Kay, software-ul este “un fel de inginerie … dar doar o forță brute”. O conversație cu Alan Kay :” 

Dacă vă uitați la software-ul de astăzi, prin intermediul obiectivului istoriei ingineriei, este cu siguranță o inginerie de un fel – dar este genul de inginerie pe care oamenii fără conceptul de arc a făcut. Majoritatea software-ului de azi este foarte mult ca un egiptean piramidă cu milioane de cărămizi așezate una peste alta, fără integritate structurală, ci doar prin forță brută și mii de sclavi ” .

Software-ul de scriere este mai mult o artă decât o disciplină de inginerie

Software-ul de scriere este cel mai asemănător cu scrierea unor romane de ficțiune. Scrierea românilor este, de asemenea, un act de creație într-un mediu neconstruit și eteric, cu câteva reguli de construcție bine stabilite. Cunoaștem o bună scriere când o vedem, dar e greu de învățat. Experiența scrisă și feedback-ul de la scriitori mai buni (coderi) este cel mai fiabil mijloc de a deveni un scriitor bun (coder). Fără un proces bine înțeles, software-ul va rămâne mai mult o artă decât o știință. Termenul “inginerie software” este mai mult un obiectiv decât modul în care scriem software-ul.