Ha az építészek úgy építenének, ahogy a programozók programoznak, egyetlen harkály egész városokat dönthetne romba.
Nem működik? Nyugi, ez a normális…
Minden nap megtörténik – néha naponta többször is. Épp elintéznék valamit mobilon. Utánanéznék valaminek. Vásárolnék valamit a weben. De a dolgok nem úgy sikerülnek, ahogy terveztem, vagy ahogy logikus és kézenfekvő lenne. Az utamba áll a technológia. Vagyis, dehogy. A technológiával semmi baj nincs, békében élek a mosógépemmel és a mikrosütőmmel. Ellenben a programkódba öntött meggondolatlanság, a sebtében, felelősség nélkül összetákolt kód, aminek szoftver a neve, nos az csúnyán keresztbe tud tenni.
A minap egy családtagom nyomtatni akart egy drótnélküli, szkennelésre is alkalmas eszközzel. Mivel a családban engem látnak legtöbbször úgy a billentyűzet előtt ülni, mint akiről látszik, hogy nem teljesen fogalmatlan (pedig ha tudnák …), sajnos engem hívott fel hogy segítséget kérjen. Kissé tartok ezektől a hívásoktól. Természetesen általában fogalmam sincs, mi lehet egy adott probléma oka – csak próbálgatok, guglizok és értelmezem a történéseket. Lényegében azt csinálom, amit az XKCD kiváló posztja javasol. Ez alkalommal egészen bizarr volt a probléma. Az eszköz szkennelni tudott, nyomtatni nem. Ha semmi sem működött volna, akkor azonnal a nyomtató-gép kapcsolat lett volna az első számú gyanúsított … de hát a szkennelés ment. Abban biztos voltam, hogy a drótnélküli működés a szükségesnél több szoftvert próbál futtatni. Ilyenkor ugyanis a nyomtató egy ad-hoc wifi hálózatot készít (felesleges szoftver no 1), amihez a számítógép csak a nyomtatás idejére kapcsolódik egy „intelligens” hálózat-választó program (felesleges szoftver no 2) segítségével. Megkértem a kétségbeesett user-t, hogy egy pillanatra feledkezzünk el a drótnélküli nyomtatás nyújtotta kényelemről, és használjuk kábelt. Két percen belül működött a eszköz. Szuper! Ami még furcsább, a történtek után a kábel használata nélkül is. Természetesen fogalmam sincs róla, miért.
Egy átlagos napon a telefonomon 30-40 db applikáció (szoftver) lesz frissítve. Ez eufemizmus – a frissítések általában hibajavítások, mintegy alátámasztandó, hogy egy átlagos telefonon, egy átlagos napon több tucatnyi szoftver működik hibásan. Egy konok nyomtató, vagy egy ügyetlen Youtube alkalmazás bosszantó, de korántsem súlyos probléma. Azonban szoftvert egyre több helyen használnak. Fontos „döntéseket” bíznak rájuk, egyre gyakrabban. Egy Toyota Camry (szó szerint) fékevesztett gyorsulásba kezd. Egy Tesla belecsapódik egy, az útját keresztező teherautóba. A vezetők mindkét esetben az életükkel fizettek. Az első esetben a szoftvervezérlésű pedálok hibás programozása lehetett az ok, a másodikban a keresztező teherautó rakterének sima, fehér oldalát nézte vélhetőleg út menti hirdetőtáblának egy szenzor. És, ha már tényleg a legsúlyosabb esetekre koncentrálunk, említsük meg a Boeing átesésgátló szoftverének, az MCAS-nak a szerepét 346 ember halálában. A gépek elkezdtek gyilkolni.
Miért lett ilyen a világ?
A „hagyományos” mérnöki tudományok anyaggal dolgoznak. Határa van annak, hogy milyen terhelést visel el egy kötőelem, hogy egy csavart mekkora nyomatékkal lehet megszorítani. Olvadáspont, nyírófeszültség, hőmérséklet, súrlódás, rugalmassági modulus – mind ismerős fogalmak. Ma már nem úgy építünk hajót, mint a 17-ik században. Ismerjük az anyagot és a korlátait. Pontosan ezek azok a korlátok, ami miatt a mérnökök nem építhetnek akármilyen magas épületet, vagy akármilyen támaszközű hidat.
A szoftver nem ilyen – korlátlanul rugalmas (vagyis, annak látszik). Lényegében bármi, ami elképzelhető, meg is valósítható. A szoftver majdnem tiszta absztrakció, tetszőleges bonyolultságú elképzelés leképezhető benne. És ez okozza a problémákat. Ha valami nagyon bonyolult, akkor igen könnyű hibát véteni benne. Ha az absztrakciók egymásra rakódó rétegei meghaladnak egy kritikus mennyiséget, hirtelen nagyon nehéz lesz belátni, hogy a kód megfelelően tükrözi-e az elképzeléseinket.
Márpedig a szoftverek szeretnek bonyolultak lenni. Miért is? Mert túlságosan csábító a lehető legtöbb tudást, funkciót belépjük építeni. Hiszen egyrészt a szoftver anyaga, a kód -rugalmassága lévén- ezt lehetővé teszi, másrészt meg lehet, hogy valakinek pont erre a funkcióra lesz szüksége – és ki küldene el egy értékes vevőt?! A végeredmény: nagy és bonyolult rendszerek, melyeknek a legnagyobb része csak nagyon ritkán van használva.
A probléma okainak másik csoportja a motivációkban keresendő. Mindenki látott már szoftver-licencszerződést, nem? Még ha nem is olvasta el …. Segítek – egy ilyen licencszerződésben általában a felelősség mindennemű hárítása van elegáns (és hosszú!) jogi nyelvezetű mondatokban megfogalmazva. Meglepően sok szerződés megy el addig, hogy a szoftvert „megtekintett állapotban” bocsátja rendelkezésre, mindenféle célnak való megfelelőség vállalása nélkül. Hát, így már nem nehéz belátni, miért is csekély a motiváció egy helyes program megalkotására. Hiszen úgysem történik semmi, ha nem sikerül …
Mit lehet tenni?
Annak ellenére, hogy mekkora fejlődés ment végbe a számítástechnikában, a programozás alapvetően nem sokat változott. A programok továbbra is lényegében szövegszerkesztővel készülnek, és némi ellenőrzés után gépi(es) fordítással nyerik el végső formájukat. Lényegében ugyanazzal a módszerrel készülnek a mai, több millió soros programok, mint régebben a pár ezer sorosak. Valóságos recept a katasztrófára.
Ezen absztrakciós probléma természetesen régóta ismert. Az egyik megoldása az absztrakció tagolása lehet. Ha sikerülne magasabb szintű absztrakciókban gondolkodni, akkor az egymásra rakodó gondolati rétegek száma kisebb lehetne, egymástól való függésük pedig átláthatóbb lenne. Az A380 repülőgép kódjait jelentős részben egy kódgenerátor segítségével készítették el. A programozó magasabb szintű elemekkel foglalkozhat, megspórolva ezzel a bonyolultság jókora részét. Mivel már eleve csak a magasabb szintű tervet tudja alakítani, nem áll fenn annak a veszélye, hogy kísértést érezne az alacsonyabb szintű viselkedés megváltoztatására.
Igazából a motivációs probléma is megoldható – jogi eszközökkel. Miért kellene hagyni a szoftveriparnak, hogy megússzák a tisztességes garanciavállalást? A szoftverek gépek, és a társadalmunkban lényegében minden eladott gépre kötelező egyfajta vállalást, a célnak való megfelelést garantálni. Miért kerülhet bele egy szoftver licenc-szerződésbe a
A <jól ismert óriásvállalat> ezúton, a helyi jogszabályok által megengedett legnagyobb mértékben kizárja a forgalmazhatóságra, az adott célra való megfelelőségre és a jogbitorlás-mentességre vonatkozó bármiféle vélelmezett szavatosságot.
kitétel? Úgy vélem, ideje megváltoztatni ezt a gyakorlatot. Ha a szoftveripar nem hajlandó erre magától, akkor a törvényalkotás fogja kikényszeríteni, és az fájni fog.
Ezt a posztot részben saját tapasztalat, részben a Wired cikkje ihlette. A kép forrása a Freshtrup blog.