Hogyan változott a szoftverfejlesztés az elmúlt kb. 30 évben?

Nagyjából 30 évvel ezelőtt még nem nagyon volt internet (1993 április 30-án indult el a “World Wide Web”).  A cégeknek jó esetben volt egy belső hálózata, ami az egyes munkatársak gépeit kötötte össze, és így egy központi szerverre dolgozhattak. A felhasználók gépein külön-külön telepített programok futottak, ezek oldottak meg minden fontos feladatot, a központi gépet – ha volt – pusztán adattárolásra (adatbázisként) használták. Ha nem volt belső hálózat, akkor jellemzően volt „a gép”, amin az összes adatot tárolták, és ahhoz álltak sorba a munkatársak, ha meg akartak nézni, fel akartak vinni valamit. (Pár éve még találkoztam egy működő ilyennel, akkor akarták leváltani). A grafikus felületek még eléggé gyerekcipőben jártak, jellemző volt a karakteres képernyő („DOS-os felület”). A számítógép sokáig az asztali PC-t jelentette DOS/Windows operációs rendszerrel, nem voltak sem hordozható kütyük, és nem voltak elterjedtek a felhasználói gépeken más operációs rendszerek sem (MacOS vagy Linux/UNIX). A szoftverek – mai szemmel – egyszerűbbek voltak, könnyebben el lehetett mondani, hogy mit szeretne az ügyfél, és ha a szoftverfejlesztő technikai készségei kiterjedtek arra, hogy tudott programozni és ismert egy-két programozási nyelvet, akkor szuper, naprakész tudású szakembernek számított.  Nagy kérdések voltak, hogy hogyan tudom a megfelelő gépi lépéssort kiválasztani, megalkotni ahhoz, hogy a feladatot el tudjam végezni: pl. hogyan sorrendezzem az adatokat a lehető leggyorsabban, ha „sok” adat van. (A sorrendezés az, amikor pl. van egy halom könyvünk a könyvespolcon és szeretnénk szerző neve szerinti növekvő ABC-sorrendbe tenni a polcon, vagy számítógépes környezetben amikor az Intézőben név, dátum vagy méret szerint szeretnénk a sorrendet. Ennek eléréséhez megvannak a különféle módszerek. Érdemes kipróbálni is: vegyünk elő 10 papírkönyvet, keverjük össze, rakjuk ki az asztalra egymás mellé, és rakjuk sorba úgy szerző vezetékneve szerinti növekvő ABC-sorrendbe. A könyvek sorrendezésekor a megengedett változtatás az, hogy két könyvet felcserélünk egymással az asztalon. Figyeljük meg, milyen módszert használtunk.). Manapság sok algoritmus már készen rendelkezésre áll. Ha Pascalban dolgoztunk nagyon régen, akkor egy sorrendezést magunknak kellett megírni (hiszen rá sem kereshettünk más megoldásaira, mert az internet sem volt még elterjedt), és ha ügyesek voltunk, akkor ezt utána használtuk a többi programunkban. Sok más ma használt programozási nyelvhez hasonlóan a sorrendezést a Java is beépítetten tartalmazza.  Ezt úgy tudjuk elképzelni, hogy kirakjuk a könyveinket az asztalra összekutyulva, és odahívjuk Duke-ot (a Java programozási nyelv kabalafigurája), aki villámgyorsan megcsinálja a megfelelő sorrendet. Nekünk csak annyit kell neki megmutatni, hogy miket kell rendeznie, és hogy két tetszőleges könyv egymással mi szerint legyen sorbarakva. Ráadásul a Javába beépített sorrendezés a lehetséges nagyon sok lépéssorozat közül a legjobbakból való, sokkal hatékonyabbak, mint amit annak idején a fejlesztők maguknak vélhetően megírtak. És nem a sorrendezés az egyetlen elérhető megoldás a programozáson belül. A Java (és a többi programozási nyelv) beépítetten is tartalmaz nagyon sok magasabb szintű megoldást, de ha ezek nem elegek, akkor az internetről még nagyon sok megoldás letölthető, beépíthető. Ezen a ponton felmerülhet a kérdés, hogy ha ennyi minden megvan, akkor mi a francot csinálnak még mindig a programozók 2024-ben?

• Ha maradunk a példánknál, akkor nyilván nem sorrendezést fognak írni. A megoldások fejlődésével párhuzamosan a problémák is komplexebbek lettek. Egy korábban emlegetett „a gép” rendszerben pl. sokkal másabbak voltak a biztonsági kérdések, mint egy cloudba telepített adminisztrációs rendszernél. „A gép” ha egy zárt ajtó mögött volt, és megfelelő riasztó, biztonsági őr rendelkezésre állt, akkor megtettünk mindent, ami észszerű volt az adott helyzetben. Onnantól kezdve, hogy kikerül valami a publikus internetre, sok olyan feladatunk is van, ami korábban nem: védjük meg az utazó adatokat, védjük meg a valaki más számítógépén tárolt saját adatainkat, szabályozzuk, hogy melyik munkatárs mihez férhet hozzá a munkaállomásán, nehogy olyasmit nézegessen, amire nincs felhatalmazva – hiszen „a gép” esetében ott állt Marika, a titkárnő, és figyelte, hogy Józsi, a gyártásról mit is csinál tulajdonképpen „a gépen”. Szumma szummárum, manapság sok olyan feladatot is el kell végeznünk, amik 30 éve még csak nem is léteztek… és még jó, hogy a sorrendezés manapság már nem probléma, így is van mire figyelni. A megoldások fejlődésével a problémák is bonyolultabbak lettek.
• Eszközt keresnek a problémára… Tegyük fel, hogy szeretnénk ásni egy 1*1*1 méteres gödröt az udvaron. Van otthon kiskanál, nagykanál, kis veteményező ásó, ásó, villa, húsklopfoló, kanál, kalapács, fúró, tipli és csavar… Ezek közül az ásó és nagyon sok verejték lesz a befutó, de ha tovább gondolkozunk, akkor felmerülhet, hogy fogunk egy munkagépet és kiássuk/kiásatjuk azzal. Ha tudjuk használni, akkor gyorsan megvan, bár a munkavégzésre optimális megoldás nem biztos, hogy összességében is az lesz. Szélsőséges esetben magunk akarjuk az egészet elvégezni: elvégzünk egy nehézgépkezelői tanfolyamot, többmillióért veszünk egy munkagépet, kiszállítjuk a helyre, kiássuk a gödröt, aztán elszállíttatjuk a raktárba, ahol majd tárolni fogjuk, míg nem kell még egy gödröt kiásni. Innen nézve az ásó és a verejték már összességében jobb megoldásnak tűnik. (Jó, jó, az ásónál és a gépvásárlásnál még jobb eszköz, ha felbérelünk valakit, aki megcsinálja egy kisebb géppel, de észrevetted, hogy mióta agyalunk már ennek a problémának a kezelésén, és csak egy gödörről van szó?!). Szoftverfejlesztés esetében is vannak hasonló helyzetek: keressünk egy a probléma megoldására valahogyan felhasználható eszközt, ami megoldja a feladatot, nem túl nehézkes, jól illeszkedik a készülő szoftver többi megoldásához, illetve a saját tudásunkhoz… a rendelkezésre álló 416.345 közül.
• Megtanulják használni a megtalált eszközt. Tehát ha végül a gépbeszerzés lett a befutó, akkor legtöbben nem fogunk elrohanni a gépboltba, és venni egy nagymarkolót, aztán majd kitapasztaljuk, mert óriási károkat tudunk vele okozni… Inkább elmegyünk egy nehézgépkezelői tanfolyamra, elvégezzük, ahol megtanítanak bennünket a használatra, a biztonsági kérdésekre, hogy hatékonyan és balesetmentesen tudjunk vele dolgozni. A programozók esetében is ez van: ha megvan az eszköz, meg kell tanulni használni. Ha ez hasonló azokhoz, amiket korábban használtunk, akkor elég lehet a leírását átolvasni. (Ha kezeltünk már markolót, akkor egy új típusnál átolvassuk a gépkönyvet és mehet az ásás). Viszont minél messzebb állunk az adott eszköztől, annál inkább külső segítségre, oktatásra lesz szükségünk (ha még ásó sem volt a kezünkben soha, akkor hasznos elmenni arra a nehézgépkezelői tanfolyamra, mielőtt szétromboljuk az udvart és balesetet okozunk).

• Különféle platformokon oldják meg ugyanazokat a problémákat. 30 éve vagy PC-re fejlesztettek DOS/Windows operációs rendszerre, vagy valamilyen nagygépes rendszerre. Manapság vannak a PC-k (és laptopok) mellett okostelefonok (iOS és Android), kiskapacitású számítógépek (pl. Raspberry Pi), legalább háromféle operációs rendszer (Windows, MacOS, Linux), van több, mint ötféle böngésző (Chrome, Firefox, Edge, Safari, Opera). A nagygépes rendszerek pedig szétomlottak több számítógépre… És akkor a kanyarban fordulnak be a további okoseszközök (fitnesz karóra, okosház, okosautó…). Manapság extra elvárásként adódik a feladatokhoz, hogy minden böngészővel fusson, PC-n minden operációs rendszeren és minden okostelefon-platformon. Kisképernyőn, közepes képernyőn, óriási képernyőn. széthajtható képernyő, L-alakú képeryőn… – és még jól is nézzen ki. Hol van már az, hogy „Nézzen ki jól egy 80*25-ös, standard karakteres képernyőn és működjön a cég AS/400-as szerverével.”?
• Sok esetben – főleg tapasztaltabb fejlesztők és kisebb cégek esetében – ügyféllel egyeztetnek. Megbeszéléseket vesznek részt, kérdéseket tesznek fel, válaszokat hallgatnak meg és jegyeznek le. Ha nagyobb cégnél fejleszt az ember, vagy kevésbé tapasztalt, akkor ez a pont kevésbé hangsúlyos, bár a belső egyeztetés egy kollégával nem nagyon tud kimaradni.
• De továbbra is: Problémákra adnak megoldásokat a rendelkezésre álló eszközök segítségével. Az eszközök közé tartoznak természetesen az adott programozási nyelv(ek) bizonyos verziói is, ezért a konkrét kódolást is az eszközkészlet részének tekintjük, de jellemzően más is van a palettán. A problémák összetettebbek, az eszközök pedig többen lettek és komplexebb megoldást adnak a részfeladatokra, és ahogy így elnézem az elmúlt évtizedeket ez a kettő érdekes módon együtt mozgott: ahogy a megoldások egyre jobbak lettek, úgy lettek a megoldandó feladatok is egyre összetettebbek. Olyan, mintha lenne két gömbünk egymásba téve, ahol a belső a megoldások lehetőségeit, a külső pedig az igényeket szemlélteti, és ez a kettő együtt nőtt egyre nagyobbra, de sosem volt még az, hogy a kettő egymásra simult volna. Azaz továbbra sincs az, hogy ha megbíznak az X bank XIII. kerületi fiókja adminisztrációs rendszerének a kialakításával és bevezetésével, akkor bemegyünk az app generátorba, beállítjuk a színeket, beírjuk a bank nevét, megnyomjuk a generál gombot, átküldjük a megrendelőnek, kiállítjuk a számlát, és besöpörjük a megbízási díjat. Véleményem szerint az igények és a megoldások gömbje sosem fog összesimulni, mert az embernek mindig vannak új ötletei és meglévő problémái, amire megoldásokat szeretne.

Akkor megint egy példa a való életből: egyik ügyfelünk webshopot szeretett volna, amiről annyit mondott meg, hogy „Szeretnék egy olyan webshopot, mint az xy-é”. xy-nak egy bizonyos webshopszolgáltatónál volt bérelt webáruháza, ezt ki tudtuk deríteni. Onnantól kezdve, hogy összegyűjtöttem a „legyen olyan webshopom, mint xy-é” „specifikációval” kapcsolatos tisztázandó kérdéseket a webáruház elindulásáig majdnem két hónap telt el intenzív munkával. (És akkor az ominózus mondat elhangzásától már eltelt jó sok idő). Pedig ez „csak” egy webáruházszolgáltató kész termékének a beállítása úgy, hogy amúgy fizetési szolgáltatókkal és a számlázóval már megvolt az ügyfél szerződése, és már korábban másra is használtuk. Csak ebben az esetben nagyobb hangsúly volt azon, hogy az ügyfélből kinyerjük a megfelelő információkat, mint azon, hogy kőkeményen kódoljunk. Persze utána jött az, hogy még ez is kéne, amit persze a szolgáltató nem vagy nem úgy tudott, amit persze valahogy megint meg kell oldani, mégpedig egy olyan eszköz kontextusában, ami bizonyos dolgokra szuper, más feladatok elvégzéséhez viszont többet kell vele küzdeni… szóval ott tartunk, ahonnan e pont elején elindultunk, az informatikus/szoftverfejlesztő megoldásokat állít össze a meglévő eszközökből. (És itt tenném hozzá, hogy egyre inkább azt tapasztalatom, hogy az ügyfeleknek a korábbiakhoz képest még jobban utána kell nyúlni, mert olyan komplexitási szintet ért el az IT, amit ügyfélként nehéz lekövetni)

• A komplexitás növekedésével a hibalehetőségek száma és helye is megnőtt, tehát: hibákat keresnek és javítanak. A 30 évvel ezelőtt ha gond volt a rendszerrel, akkor az rendszerint az általunk írt programban volt. A hardver, az operációs rendszer és a programozási nyelv fordítója jól átgondolt, alaposan kitesztelt eszközök voltak, nagyon ritka volt az ő hibázásuk. Manapság meg még az is kihívás, hogy az ember meghatározza a hibás komponenst. Mondok megint egy hétköznapi példát a közelmúltból: nem ment az újonnan felállított MOHU-nak a Díjneten keresztül való számlázás. Elvégeztem, amit mondtak, de nem jött össze: postán kaptam meg a számlámat. A feladat az volt tehát, hogy hibát keressek és javítsak egy olyan rendszerben, amiről ismeretem nem, hozzáférésem pedig elég felületes volt (értsd: tudok írni egy emailt az ügyfélszolgálatnak). Mondanom sem kell, hogy ment az egymásra mutogatás: a Díjnet szerint a MOHU hibázott, a MOHU szerint pedig a Díjnet. És persze minden rettentő lassan, tehát a MOHU 30 nap alatt addig jutott el, hogy „még vizsgálják a problémát”. Végül a korábbi hulladékszállító céget is ráállítottam a problémára, és én is beidőzítettem heti küldéssel egy-egy panaszlevelet, mire az átállástól számított majdnem 1 év alatt sikerült megoldani a problémát. Ez az IT rendszerekkel kapcsolatos probléma szoftverfejlesztőként is áll: a rendszerek a korábbinál jóval több komponensből állnak, a gyors kiadások és a saját növekvő komplexitásuk miatt annyira nem is hibamentesek, és amikor a hibajelenség felüti a fejét, lehetséges, hogy az ember azt sem tudja, melyik komponensnél kezdje el a kutakodást. Megoldások, technikák vannak ezekre is, de kérdés, hogy ismeri-e az ember ezeket, vagy ha nem, hogyan és mikor tanulja meg.

A feladatok ilyenfajta sokszínűsége azt mutatja, hogy az újonnan belépő technológiák, mint az AI lehet, hogy egy-egy részletet megkönnyítenek, viszont a teljes egészre elég kicsi befolyással vannak. Tőlem független forrás szerint – amivel én is egyetértek – a kódolás a szoftverfejlesztő idejének kb. 20%-át teszi ki. A többi a megoldáskeresés, tanulás, egyeztetés, tervezés… Ennek a 20%-os résznek képes a jelenlegi AI technológia az időigényét 20%-kal csökkenteni azzal, hogy megoldásokat ajánl fel, és a bepötyögés helyett elfogadás/javítással lehet bizonyos esetekben dolgozni. Ha a kettőt összerakjuk, akkor azt kapjuk, hogy a szoftverfejlesztő esetében azonos munka elvégzésének az időigénye 4%-kal csökken. Emellett azt láttuk még több ponton, hogy a szoftverfejlesztésben tart már jó ideje az a trend, hogy az eszközeink egyre összetettebbek, hatékonyabbak lesznek, egyre több mindent automatizálunk, ezzel párhuzamosan viszont egyre újabb és újabb lehetőségek nyílnak meg, amik újabb és újabb feladatot adnak a fejlesztőknek. Hogy mást ne mondjak, az elmúlt 20 évben megjelent az okostelefon, ami az eszközeink fejlődésének következménye, és egyben egy új lehetőség is. Az okostelefonok megjelenése megteremtett egy egészen új szegmenst, aminek hatására még több szoftverfejlesztőre lett szükség: rövid időn belül három új platform jelent meg, melyeket programozni kellett a meglévők mellett. Lehet, hogy gyorsabban tudunk fejleszteni, mint 30 éve, de több a fejlesztendő szoftver darabszámra is, de a platform is, amin mindezeknek futnia kell. Az AI okozta változás eddig a meglévő trendbe illeszkedik bele, nem jelent abból kiugrást, és a múlt azt mutatja, hogy ez a trend nem csökkentette (sőt, inkább növelte) a szoftverfejlesztők tudása iránti igényt. Ezek alapján ma is legalább ugyanannyira érdemes letenni a voksunkat e szakma mellett, mint amennyire érdemes volt az elmúlt 5, 10 vagy akár 20 évben. Aki emellett dönt, egy érdekes, intellektuális kihívásokkal járó, megújuló, sosem unalmas hivatás mellett kötelezi el magát.