Alighanem igen. Helyesebb viszont inkább programozókrízisnek nevezni. Egyszerűen nem vagyunk elegen, ugyanakkor a piac bővülése, ahogy az egyre újabb és persze komplexebb szoftvermegoldások iránti kereslet továbbra is növekszik.

Az 60-as évek végén, a 70-es évek első felében egy egészen sajátos, addig ismeretlen jelenség következett be: sokkal több számítógépre és szoftverre lett volna szüksége a piacnak, mint amennyi egészen egyszerűen rendelkezésre állt. Ekkor már sokan tudták, hogy nagyon sok minden számítógépekkel végezve csökkenti a költségeket és növeli a hatékonyságot, viszont egész egyszerűen nem voltak meg a szükséges szoftverek hozzá. Körülbelül ekkorra tenném a szoftvertechnológia - és egyben a digital age - kultúrtörténetének kezdetét.

A történet folytatása ugye az egyedileg fejlesztett szoftverrendszerek voltak, amik nemhogy egymással, hanem sokszor még önmagukkal sem voltak kompatibilisek, alaposan feladva ezzel a leckét a szabványügyi szervezeteknek és egyben kooperációra kényszerítették azokat a cégeket, amik korábban egymás legnagyobb riválisai voltak. A probléma persze csökkent, szinte el is tűnt, akik óvodás koruk óta követik a híreket, még az én korosztályom tagjai közül is emlékeznek arra, hogy bizony a 90-es években nem ritkán még egy közepes méretű cég is inkább összetákoltatott egy adatbáziskezelőt, táblázatkezelőt, komplett számlázórendszert vagy éppenséggel amit egy kis programozócsapattal. Ma már senkinek sem jutna eszébe, hogy egy programozóval saját táblázatkezelőt vagy teljes vállalatirányítási rendszert írasson. Jöttek a komplett irodai programcsomagok, mint az Office és klónjai, a pénzügyi szektorban megkerülhetetlen szereplő lett az SAP és az ahhoz kapcsolódó technológiák, ahogyan a Cisco szolgáltatja a saját oprendszerével a teljes internet gerinc-infrastruktúrájának több, mint háromnegyedét, óvatos becslések szerint és sorolhatnám. Azaz eléggé egyértelművé vált, hogy különböző "sportágban" és "súlycsoportban" kiknek a termékei maradtak talpon és viszik a piac nagyobb részét, ahogy a végfelhasználó a 2000-es évek elejére már teljesen hozzászokott, hogy szinte minden feladathoz feltelepíthető a megfelelő szoftver next-next-finish-tematika alapján, ekkorra a legnépszerűbb operációs rendszereket érintő, ma már elképesztő mértékű stabilitási és inkompatibilitásbeli problémák is alaposan redukálódtak.

Azaz ma, ha szükségem van egy normális videóvágó programra, letöltöm és használom, közben nem kell tartanom attól, hogy kékhalállal elszáll a gép minden különösebb előzmény nélkül, ahogy attól sem, hogy akár hónapokat kelljen várni ahhoz, hogy egy újonnan megjelent vírus leirtásához szükséges frissítés el is jusson hozzám. Természetesen például a cloud technológiák és a mobil megoldások elterjedése új típusú, komplexebb problémákat szültek.

A felhasználót nem érdekli, hogy valami miért nem úgy működik, ahogy kellene, miért fagy, miért nem kényelmes, őt csak az érdekli, hogy működjön, de szinte esélye sincs belelátni egy informatikai eszköz működésébe, legyen szó akár végponti eszközről, azaz például a mobilon futó oprendszerről, akár a szolgáltatásokat kiszolgálóoldalon biztosító szerverekről. Viszont idővel eljött az a pont, hogy már az informatikusoknak is egyre nehezebb, nos, ekkor kezdődtek a gondok.

Tudom, hogy az átlag felhasználó úgy gondolja, hogy aki informatikával rendszeresen foglalkozik, mindennek a működését érti és egy hibát azonosítani is javítani is tud azonnal, egészen a mikrosütőtől kezdve a blogmotoron át a rendszeresen lefagyó mobilokig - mert, ha nem, akkor nyilván "hülye hozzá" - a valóság azért máshogy fest. Az nem várható el egy informatikustól, hogy minden informatikai eszközhöz és technológiához a problémamegoldás szintjéig értsen, az viszont továbbra is elvárás, hogy egy adott rendszert és annak felmerülő problémáit ésszerű idő alatt át tudjon látni és tudjon is orvosolni. Azt írtam továbbra is elvárás illetve ésszerű idő alatt.

Viszont vagy mi, informatikusok vagyunk egyre hülyébbek vagy a napi rendszerességgel használt informatikai eszközök is egyre komplexebbek, úgy fest, hogy ennek a kihívásnak egyre nehezebb megfelelni - még egyszer: ésszerű időráfordítás mellett. Ennek a jelenségnek a tüneteit, lehetséges okait és középtávú következményeit boncolgatom egy kicsit - anélkül, hogy mostanában lett volna időm a poszt megírása előtt utánakutatnom a konkrét jelenséggel kapcsolatos mutatóknak, de meg tudom magyarázni! Legyen erős a Kedves Olvasó: nem volt rá időm :) Szóval írok a meglévő tudásomra és logikámra hagyatkozva. Jöjjön három példa, bármiféle egyezés a valósággal a véletlen műve!

0x100. eset: adott egy szép nagy pénzintézet csúnya és komplex informatikai kiépítésének egyik alrendszere, amit egy csapat egészen szépen át tud látni, viszont amint egyvalaki hiányzik a csapatból, ha nem is válik totálissá a fejetlenség, elég nagy a para, mivel ha nincs ott a Jürgen, akkor az egész csapat meg van lőve, mivel Jürgent esélytelen, hogy valaki tudja helyettesíteni és csak szerencse, ha pont nem akkor történik valami olyan, amihez ő kellene, mert akkor az érezhető hatást gyakorol a pénzintézet üzletfolytonosságára. Igen: egy Oracle-höz kapcsolódó rémségről van szó.

0x200. eset: adott egy informatikai  biztonsággal foglakozó cég, ami egy új megközelítéssel próbálkozik megoldást fejleszteni arra, hogy egy közepes vagy éppenséggel nagy méretű cég, ami nap, mint nap irgalmatlan mennyiségű netről érkező fenyegetésnek van kitéve, megfelelően tudja megelőzni és kezelni a biztonsági incidenseket. Összelőttek több csapatot, akiknek ki kell dolgoznia a tervezéstől kezdve az implementációig a megoldást, csakhogy több hétig tart, mire megértenek egy-egy problémát, de nem azért, mert hülyék lennének, sőt, konkrétan profikról van szó. Csak éppenséggel a probléma bonyolult és a fejlesztés természeténél fogva nagyon kockázatos lenne külsőst bevonni a munkába.

0x300. eset: adott egy portál, egy adott blogmotorral és egyre növekvő számú látogatóval, amit nincs mese, a forgalmából adódóan stabilabb helyre kell költöztetni azért, hogy folyamatosan biztosan elérhető legyen, korábban alighanem nettó mákjuk volt, hogy azt a szervert, amit használtak, más ügyfelek csak kevés látogató mellett használtak, azaz alighanem a teljes szerverkapacitást ki tudták használni. Viszont ha költözni kell, hát költözni kell, ha saját szerverre nem költenek, akkor virtuális szerverre. Fehér ember viszont mielőtt VPS-re tesz bármit is, tesztkörnyezetben alaposan méricskéli keresztbe-hosszába az portálmotor erőforrásigényét és ha 100+1%, hogy nem lesz probléma, akkor teszi át a teljes hóbelebancot egy erőforrások szempontjából teljesen autonóm rendszerre. Ja és még egyszer: mindezt relatív olcsón – olcsó környezetben. Gyakorlatilag 1-2 nap alatt kibukott, hogy az akkori formájában jó, ha pár percig működött volna a portálmotor kiválasztott éles környezetben, mert eszelős mennyiségű adatbázislekérdezést küldött a szerkesztőfelület az adatbázismotor számára. Ennek megfelelően a tesztelő próbálta az egész erőforrásigényét csökkenteni megtartott stabilitás és sebesség mellett, de az adott (olcsó) tesztkörnyezetben - na ez volt a kihívás - olyan régen tesztelt ilyet, hogy rövidke időre eltűnt négy napnyi cikk, amint mentésből kellett visszavarázsolni, részben a CMS programozóinak hülyesége, részben pedig a tesztelő  kapkodásom miatt: ingyenes szoftverről sose hidd el, hogy biztosan azt és úgy csinálja, amit csinálnia kell, a tesztelő viszont fél percig elhitte... Az olcsó környezetet azért emeltem ki, mert máshogy gondolkozik a tesztelő agya, amikor 5-10 USD illetve egy 500+ USD havi díjért elérhető vason kell valaminek zakatolnia úgy, hogy közben az össz-minőséget és rendelkezésre állást fenn kell tartani. Igen: Wordpressről van szó.

Ami mindhárom, valós eset alapján világos és folyamatosan tapasztalom, hogy - drámaian fogalmazva - a gépekhez az emberek egy ideje "túl hülyék", függetlenül attól, hogy melyik szektorról vagy milyen felhasználási területről van szó. Oké, persze, van, amikor az, aki a technikai megvalósításért felel, tényleg hülye hozzá, de a cikkben sosem azt az esetet fogom alapul venni. Akár alapkutatás, akár fejlesztés és ipar, ahogyan a polihisztorok kihaltak, egyre jobban értünk egyre kisebb területhez, amivel viszont nem számolunk, hogy ez egy szinten túl azt is magával hozza, hogy ha valami mást kell fejleszteni vagy tesztelni, mint amivel kimondottan foglalkozunk, ezért annak utána kell kutatni, a dolog sokkal több időt és energiát vesz igénybe, mint mondjuk 15 évvel ezelőtt egy informatikusnak, aki akkor járt hasonló cipőben. Ha feltételezzük, hogy informatikusként nem vagy hülye, a Te időd és az ügyfeled infrastruktúrára fordítható anyagi keretei végesek, és nem droidpisti-kontármunkát akarsz kiadni a kezedből vagy több időt fordítasz arra, amit vállaltál vagy a minőség terén teszed lejjebb a lécet, na ez mondjuk nálam nem opció.

Hogyan jutott a bedrótozott világ idáig, mit hozhat a jövő és mi lehet a megoldás?

Ezen a ponton tételezzük fel, hogy azoknak a szoftvereknek a nagyobb részét, amik el is terjednek akár okostelefon-appról, akár nagyszámítógépes platformról van szó, szakszerűen készítik olyan értelemben, hogy klasszikus módon valamelyik bevált módszertannal megtervezik, megírják és rendszeresen tesztelik is.

A fejlesztésben dolgozó informatikusoknál több országban csak a pénzügyi szektorban dolgozók keresnek jobban, valami miatt mégis elképesztő informatikushiánnyal néz szembe szinte az egész világ. Elég csak arra gondolni, hogy Magyarországon 10-15 ezer informatikus hiányzik a munkaerőpiacról, több cég a Szilíciumvölgyben és a Nyugat-európai térségben nem csak kiszervezi a fejlesztés vagy a tesztelés részét vagy egészét olyan országokba, ahol a munkaerő olcsóbb, hanem sokszor akár oda is költöztetik a legjobb fejlesztőket a kutatóbázis közelébe, azaz mintha nem lenne elég fejlesztő helyben /*ugyan azzal kapcsolatban nincs konszenzus, hogy a munka világában ilyen akkor történik globális viszonylatban, ha a fogadó országban munkaerőhiány van vagy a jelenség ettől részben független */. Informatikusnak lenni menő, mégsem mennek ennek megfelelően sokkal többen informatikai pályára.


Ezzel kapcsolatban globális viszonylatban aligha lehet mondani bármi értelmeset is, ha a magyar viszonyokat nézem, azért van néhány dolog, ami ezzel összefüggésbe hozható:

- Elég csak megnézni a fórumokat, abból a többség számára az jön le, hogy az informatikai szakok nehezek, sok "fölösleges" dolgot tanítanak, túl sokat kell dolgozni a diplomáig abban az életszakaszban, amíg gondtalanul ihatna a fiatal egy másik, ha nem is feltétlenül könnyebb, de kiszámíthatóbb szakon. A bizonytalanság pedig öntudatlanul kerülendő. Meg is lehet nézni, hogy rendszerint milyen tragikusan alakulnak az informatikus felvételi ponthatárok, 2-3 helyet leszámítva.
- Igen, igaz az, hogy összesen 2-3 egyetem van az országban, aminek az informatikus szakán tanulva sajátítja el valaki azokat a skilleket, amik lehetővé teszik, hogy jó informatikussá váljon. Azt írtam: lehetővé teszik! Ugyanis önmagában attól, hogy valaki informatikus diplomát szerez, az én fogalomrendszeremben - na meg a munkaerőpiac fogalomrendszerében - még nem informatikus, legalábbis nem önálló és nem is azonnal piacképes, a rutint viszont egyetem mellett is meg lehet szerezni. Szóval összesen 2-3 komolyan vehető hely van, amiből persze nem következik az, hogy aki nem ott végzett, nem lehet jó szakember, de ezerszer jobban meg kell dolgoznia azért, hogy a szakmai kompetenciája igazodjon a tényleges piaci elvárásokhoz, ahogy persze annak is, aki meg konkrétan semmilyen informatikus diplomát nem szerez. Most abba nem mennék bele, hogy maguk a bérviszonyok és a szakmai elvárások is jelentősen eltérnek Budapest és a többi város közt ebben a szakmában.
- Na, de mi a helyzet a többi egyetemmel? Távol álljak attól az általánosítástól, hogy egy vidéki egyetemen manapság egy tehetséges hallgató számára visszataszítóan sok a tuskó - a ponthatárokat előbb emlegettem - az viszont biztos, hogy az ottani légkör nyomokban sem hasonlít akár a kkv-s, akár nagycéges munkahelyi légkörhöz, többek közt ezért az iskolapad egyszerűen nem vonzó sokaknak. És egy pillanatra se felejtsük el, hogy ha egy piacon alapvetően kevesen vannak, általánosságban oda fog menni az informatikus dolgozni, ahol alaposan megfizetik (==ezt csak a jobbak tehetik meg), így nagyobb valószínűséggel kerül olyan informatikus egyetemi oktatói pozícióba, ahol kevésbé fizetik meg, aki - mondjuk ki - nem kell az iparnak. Vigyázat! Elnagyolva fogalmaztam. Hangsúlyozom: általánosságban, hiszen jelen esetben a kereslet a kínálatot alaposan meghaladja, így ez az effektus jobban érvényesül az informatikusoknál, mint más terület képviselőinél, de nem jelenti azt, hogy aki iparban van, jó szakember, ha pedig egyetemen tanít, kókler. Akiket én ismerek vagy elhivatottságból tanítanak vagy a tehetségtelenségük miatt. Ezen kívül a tehetséggondozásnak, tehetségsegítésnek nem igazán van elvárható szintű kultúrája.

Nem vagyok hajlandó senkinek magyarázkodni az ezzel kapcsolatos véleményemért, de az informatika tényleg az a terület, ahol a jobbak tényleg csak azért maradnak a katedrán, mert elhivatottak, szeretnek tudást átadni vagy éppenséggel minősíthetetlenek munkaerőpiaci szempontból, de jobb esetben máshol legfeljebb stupid robotok lehetnének. Nemrég történt, hogy egy informatikus hallgatókat tömörítő egyetemi csoportban, amire nekem is van rálátásom, nem értettem egyet egy oktatóval [pontosabban ő velem], a kommentejei alapján pedig kiderült, hogy 0x100. a vitakultúrája körülbelül egy ősember szintjén áll 0x200. ha az érvelésem kicsit is bonyolultabb volt, nem értette annak lehetséges konnotációit [amiből lejön, hogy fingot sem olvas] 0x300. a tahó válaszai nemhogy ellenérzést keltettek volna a hallgatókban, sőt, egyenesen népszerű volt számukra, hiszen a rövid és tuskó válaszok egyszerűek és mindenki számára értelmezhetőek 0x400. annyira primitív módon fogták meg többen a dolgot, hogy jobb híján nem az érveket próbálták ütköztetni egymással, hanem inkább a személyeket, nevezetesen arra célozgattak egyik másik oktatónál, hogy ejnye-bejnye, kiállt mellettem korábban, pedig lám' mekkora pöcs vagyok. Többet most erről nem csak azért nem írok, mert már ennyi is kínos, na meg szükségtelen, hanem mert még a végén valamelyikük eljut idáig ennek a posztnak az olvasásában, aztán rögtön rohan perelni valami wannabe-retardált ügyvéddel képviseltetve magát. /*ez is megvolt, egy Tumblren megjelent mikroposzt miatt!*/

Összefoglalva: hiba lenne bármiféle általánosítást megfogalmazni az alapján, hogy ilyen egy egyetemi közegben megtörténhet, azért mutatja, hogy vannak gondok, amivel kapcsolatban nem vigasz, hogy biztosan lehetne találni még kínosabb helyet. Lényeg, hogy az egyetemek egy nagyon nagy része nagyon nem menő, főleg annak, aki ismeri azokat a munkakörülményeket, amik elvárhatóak egy normális IT-s cégnél, ezért nem mennek informatikai szakra vagy dobbantanak.

A mostani szoftverkrízis küszöbén, a jelenség értelmezésében nem választhatóak el az emberi tényezők a többitől, nem feltétlenül állja meg a helyét az a modell, ami szerint az informatikai eszközök és szoftverek közt - divergáló technológiák ide vagy oda - majd az evolúció kiszórja a gyenge minőségűt. Ez működött egy darabig. Már nem, egészen egyszerűen azért, mert a tömeg ilyen eszközök esetén nem racionálisan dönt: például megveszik az okosmobilt, mert jól néz ki, akkor is, ha a rajta lévő platform a rá letölthető programokkal tragikusan alacsony minőségű, illetve egészen egyszerűen nagyon olcsó okosmobilra is mindig lesz kereslet. Ha pedig nem okosmobilt vesz az egység sugarú felhasználó, hanem portálmotort izzít be a saját blogjához, nem olyat választ, ami stabil és gyors, hanem olyat, aminek a szerkesztőfelülete - amit ugye az olvasó sosem lát, így irreleváns szempont kellene, hogy legyen - szép, jópofa, a portálmotor pedig népszerű. A portálmotorokat illetően a minőség általában még csak azzal sincs összefüggésben, hogy ingyenes vagy fizetős megoldásról van szó. Elő lehetne túrni azokat az eléggé komoly cikkeket, amik azzal foglalkoznak, hogy sokszor nemhogy a felhasználók, hanem az IT döntéshozók is úgymond pofára, külcsíny alapján döntenek valamelyik termék vagy IT megoldás mellett, amiben végülis nincs semmi meglepő, hiszen emberek vagyunk. Olyan marketingpszichológiai részletekbe most nem mennék bele, hogy akár egy egyéni végfelhasználó freemium modellben működő szolgáltatás esetén néhány garast fizet az extrákért, akár egy IT döntéshozó döntött egy új CRM-rendszer, levelezőrendszer vagy csapatmunkát segítő suite bevezetéséről, amit jó drágán adnak, nem vizsgálja felül a döntésének helyességét akkor sem, ha a termékről menet közben kiderül, hogy trágya minőségű - ugyanis bizonyítottan elhitetjük magunkkal, hogy ami drágább, annak jobbnak is kell lennie.

Azaz ne legyünk naivak, a versengés erős, de sokszor nem igazságos, ami át is vezet a következő gondolathoz.

Ha szoftverről van szó, már rég elkezdett eloszlani az az egyszerűsége miatt közkeletű téveszme, ami szerint ami nyílt forráskódú és/vagy ingyenes, az jó, ami pedig nem nyílt forráskódú és/vagy fizetni kell, az rossz. Itt nem csak arra gondolok, hogy sokszor a teljesen nyílt forráskódú termékekben is csak évekkel később vesznek észre egy-egy orbitális hibát. Ebben a műfajban a kedvencem, hogy hiába volt az open source közösség orra előtt egy fájlszervereket érintő sebezhetőség az egyik BSD-s oprendszerben, csak évekkel később vették észre, ahogy előfordul, hogy nem tűnik fel nekik, hogy mások később kihasználható sebezhetőségeket építenek a szoftverbe. Sokszor pedig bele sem kell építeni semmit szándékosan, konkrétan szintén az OpenBSD operszert érintette egy több, mint harminc évig felfedezetlen hiba nekem mondjuk ezért (sem) volt meglepő a 2014-es év nagy ITsec parája, ami a titkosított webhelyek elérését érintette az biztonságos elérést szavatoló OpenSSL bizonyos verzióinak sebezhetősége miatt.

Tehát az egy dolog, hogy a nyílt forráskódú kultúra szépségét az adja, hogy a szoftver forráskódját bárki olvashatja, ez nem jelenti, hogy olvassa és értelmezi is. Sőt, egy pillanatig se felejtsük el, hogy ha valaki egy szoftverhibára bukkan egy nyílt forrású rendszerben, nem biztos, hogy a fejlesztőt értesíti, aki jó esetben nem akarja leperelni az illetőről a gatyát is a világ túloldaláról, akár bizonyítható, hogy a szoftverhibát kihasználták, akár sem. Ezen kívül jól ismert jelenség, hogy egy hiba bejelentése után a szoftver készítője a hibát elbagatellizálja, mondván, hogy másnak úgysem jut eszébe, de az is gyakori, hogy a munkaköltsége, a szükséges időráfordítás, amit a lyuk befoltozásával kellene tölteni persze a szükséges tesztek lefuttatásával együtt olyan többletköltséggel járna, hogy a hiba ezért marad benne egy termékben azon túl, hogy fel kellene vállalniuk a fejlesztőknek, hogy hiba maradt a termékükben.

Elsősorban biztonsági szempontból érdekes programhibák bejelentésére kitalált ún. bug bounty programok és azok dicsőségfala ide vagy oda, mondjuk a Googlenél vagy a Facebooknál,  ne legyenek illúzióink, a világot ezzel nem váltja meg egyik óriás sem.

Kínosan közhelyes, hogy programhibák mindig is lesznek. A gond azzal van, hogy egyre több, egyre több helyen és úgy fest, hogy a szoftverek mennyiségéhez képest egyre kevesebben látják át és tudják javítani. Amikor azt látom, hogy a minőségi szoftverfejlesztésben egy-egy olyan terméknél, aminek alaposan meg kell fizetni az árát, a fejlesztési fázisok közt legalább annyit költ egy cég a tesztelésre, mint a kezdeti implementáció elkészítésére, érthető, hogy ezekkel csak ideig-óráig tudják felvenni a versenyt a szabad szoftveres megoldások, amiket sokszor tehetséges, ámde lelkes önkéntesek készítenek és nincs rajtuk az a nyomás, hogy a tesztelésre, a software quality assurance-re annyira figyeljenek. Tesztelés persze van ott is, csak éppen lazábbra veszik a figurát: a szoftver szükségszerűen gyengébb minőségű lesz. Ugye-ugye, az a mocskos pénz mégsem az ördögtől való dolog ám.

Egyébként értem én, hogy leegyszerűsítve kezeli egy jelenséget mindig népszerűbb, csak éppenséggel vegyük észre, hogy egy egyszerűsítés mikor veszélyes demagógia. Ha valaki olvasta Eric S. Raymond A katedrális és a bazár, vagy éppen Lessing Szabad kultúra könyvét,  érdemes elolvasnia Bőgel György Üzleti elvárások, informatikai megoldások című könyvét is és rögtön világosabb lesz, hogy az ingyenes-fizetős, community support-dedicated support, zárt kódú-nyílt kódú jelleget és ami ezekhez kapcsolódik, nem egymással szemben, hanem egymással párhuzamban kell értelmezni. Nemrég jelent meg szintén Bőgel György szerkesztésében a Terepszemle: Tanulmányok és feljegyzések az infokommunikációs világról című könyve, szintén az IT gazdaságtanáról. Az említetek közül a negyediket még nem volt időm elolvasni, az elkövetkezendő három hétben nem is lesz, de ha valaki gyorsan elolvasná, kérem, hogy zanzásítva küldje el az email-címemre, csak ne "Kötelezők röviden"-stílusban.

Az IT- és a szoftverfejlesztés gazdaságtana sokmindenre magyarázatot ad, de nem mindenre.

Hogy mi várható az elkövetkezendő 3-5-10 évben, úgysem tudja senki, néhány lehetséges - esetleg egymással párhuzamosan bekövetkező - eshetőséget tippelni azért még szabad, végig vegyük figyelembe, hogy nem barlangban, hanem egy erősen behálózott világban élünk, azaz az informatikai eszközök megbízhatósága az MP3 lejátszótól a kémműholdig vagy így vagy úgy, de komoly hatással van a mindennapjainkra. Néhány lehetséges eset:

Armageddon - a piacot annyira elönti a gagyi, hogy kishíján mindenki belefullad: közvetlenül érzékelhető lesz például azon, hogy a mobilok lassúak lesznek és önveszélyesek, míg közvetetten érzékelhető lesz például azon, hogy az, amiért korábban [közvetlenül] nem kellett fizetni, de hatékony volt eltűnik a süllyesztőben vagy fizetős lesz, mivel egy ingyenes levelezőrendszer mögötti infrastruktúrát is szerverek képzik, rajta bizonyos operációs rendszerrel, bizonyos technológiákban megvalósított szerveroldali szoftverekkel. Az elgondolás alapján tévedés lenne azt hinni, hogy a legnagyobbak, mint mondjuk a Google levelezőszolgáltatása ezt az eddigi modellel megúszhatná, mert nem. Az armageddon közbeni állapot megszüntetése még szürreálisabbnak tűnik, mint a bekövetkezése: a verseny mostani természetétől teljesen eltérően, a legerősebb piaci résztvevők hallgatólagos és nyilvános megállapodásokat kötnek, amik hirtelen terelik a világot egy olyan irányba, ahol nagy ütemben tűnnek el egész programozási nyelvek, keretrendszerek, technológiák, módszertanok, a helyüket pedig a korábbinál jobban egységesített és tesztelhető komponensek veszik át. Rémesen bizarrul hangzik az, hogy egy élesedő versenyben egyszer csak bekövetkezzen az a pont, amikor csak úgy fogja megérni bárkinek is a bizniszt, hogy pont magát a versenyt mesterségesen megtörik, de ha elgondolkozunk azon, hogy mennyire függnek egymástól látszólag független komponensek, rögtön könnyebb elképzelni. Például köszönet a Samsungnak, hogy ilyen kitűnő ARM processzorokat gyárt az Apple iPhone-jaiba, amikben a mai napig egy nyílt forráskódú BSD /*unix-szerű oprendszer mag*/ rendszerből  származtatható iOS fut.

Ha az armageddon bekövetkezik, ami pedig az emberi, fejlesztői oldalt illeti, nyilván sokan húzzák majd a szájukat, nem pisálhatnak szembe a széllel, nem programozhatnak akármiben, akárhogy, ha nem akarnak éhenhalni, mert az lesz a mostaninál is kevésbé eladható, ami számításigényesebb, ilyen módon drágábban futtaható is. Elszigetelten persze már történt kicsit hasonló - persze nem valamiféle titkos összeesküvés alapján - például a fél évtizeddel később megjelenő C#-hez köthető technológiák szépen kipréselték a Java-alapú vagy ahhoz köthető technológiákat bizonyos területeken: a webes szempontból fontos ASP.NET-re és JSP-re gondolok. Persze lehet mondani, hogy alapvetően rossz a példa, na meg lehetetlen normális adatot találni arról, hogy mennyi webhely halna meg JSP nélkül és mennyi ASP.NET nélkül.

Tételezzük fel, hogy nem történik armageddon, hanem csak mérsékelt ütemben lesz minden egyre rosszabb, viszont az eddiginél jobban bekapcsolódnak a fejlesztés vérkeringésébe azok az országok, amik még kevésbé vannak benne a bizniszben. Remek kérdés, hogy ha összességében több fejlesztő lesz, ezzel együtt több kiugróan tehetséges, na meg zseni lesz-e, akik egyébként most még nem vehetnék ki a részüket a fejlesztésből érezhető mértékben az életkörülményeik miatt vagy egyszerűen az igényeik miatt. Azaz például a Piréz-szigeteken élő fejlesztők nagyobb felelősséggel járó melókat is megkapnak majd a világ túloldaláról, na meg jóval több pénzt. Most körülbelül két és fél milliárd ember tud netezni, mindenki más pedig úgy, ahogyan jut internethez vagy sehogy, de mindenesetre abban a még néhány százmillió emberben is jelen lehet a potenciál, akik most még nem neteznek. Az ugye már nagyon-nagyon nem reális, hogy az egyik körbe sem tartozó éhező néhány milliárd közül tömegesen kezdjenek el programozással foglalkozni, főleg úgy nem, hogy kivegyék a részüket a technológiai csapásirányok meghatározásában.

Oké, oké, a következő, harmadik lehetséges perspektívát az ország egyik legnagyobb ITsec stratégájától loptam két sör közt egyik este, aztán finomítottam rajta: idővel olyan bonyolultak lesznek a szoftverrendszerek, hogy azt most még nem létező vagy létező, de még nem elterjedt, mesterséges intelligenciára épülő gépek fogják tesztelgeti és fejlesztgetni, ami pedig a lényeg: döntéseket hozva, felelősségteljesen. Pár évvel ezelőtt írtak róla, hogy amikor a konyhanyelvi értelembe vett mesterséges intelligencia került szóba, mindenkinek az ugrott be, hogy jön a Terminátor meg Terminátorné, aztán jól leigázzák az emberiséget, annyira fog függeni a géptől az emberiség, amire pedig kitér a cikk, hogy már évtizedek óta függünk a gépektől, csak nem vesszük észre. Ha belegondolunk, hogy egy-egy banki rendszer, netszolgáltató, vagy bármilyen telekommunikációs rendszer kiesésének vagy hibás működésének társadalmi hatása időről időre egyre nagyobb, ez teljesen világos. Az viszont már eléggé para lenne, ha az emberek még kevésbé látnák át a mostani rendszereket – mivel azokat gépek készítenék - ennek megfelelően a mostanság alkalmazott tesztek használhatósága is csökkenne, aztán az egész szoftveripar jövőjéről nagy és okos gépek döntenének, nagy és okos gépek kiviteleznék. Az embereket persze csak az érdekelné, hogy továbbra is működjön minden elérhető költséghatékonysággal, az viszont már nem érdekelné a feltétlenül szükségesnél jobban őket, hogy mindez hogyan valósul meg. Az IT-szakembereket már jobban, de ők is emberből vannak, ha pedig már képtelenek lennének áttekinteni a gépek által írt termékeket és tesztelni azokat, idővel fel is adnák. Ez persze magába hordozza annak a lehetőségét, hogy az emberi döntések háttérbe szorulásával a gépek sarokba szorítják majd az emberiséget, csak a sci-fi írók heppje az, hogy a tudatos és okos gépek feltétlenül gonoszak is. Persze lehetnének azok is, csak valahogy egymást gyilkolászni túl emberinek tűnik nekem.

Vannak még alternatívák? Biztosan.

Végül, kiugorva egy kicsit a poszt eddigi logikai menetéből, még egy általános tapasztalatot meg kell osztanom, ami gyakran megakasztja a minőségi csapatmunkát. Mégpedig az, hogy sokszor azért nem készül el – a lehetőségekhez mérten legjobb – specifikáció, mert a fejlesztők nem látják át eléggé a problémát, ami nélkül az algoritmustervezés és a projekt ütemezése el sem kezdhető. Ha konkrétabban akarok fogalmazni, nem várható el, hogy egy üzleti intelligencia alkalmazás tervezésekor a programozó tudása legyen teljesen naprakész BI-téren, ahogy egy bioinformatikai vagy keminformatikai megoldás összetákolásánál sem várható el tőlük, hogy naprakész tudással rendelkezzenek a molekuláris biológiában és a farmakológiában. Az viszont a piacképesség és a hatékonyság szempontjából másokhoz képest hatalmas előny, ha a legkülönbözőbb területeken a fejlesztő legalább az alapfogalmakkal tisztában van, legyen szó akár nyelvészetről, akár üzleti folyamatok modellezéséről, meg úgy egyáltalán bármiről. Az alapfogalmak persze még nem lesznek elegendőek ahhoz, hogy rögtön el tudja készíteni a specifikációt a vezető fejlesztő, ahhoz viszont igen, hogy elfogadható idő alatt megértse a feladatot, ha utánanéz. Azaz szakbarbárnak lenni nem csak kínos, hanem hátrányos is, mert több-kevesebb természettudományi, társadalomtudományi és stabil matematikai ismeret nélkül a fejlesztő lehet egy jó robot, aki megcsinálja, amit elé tesznek, de annál nem sokkal több. Nem csak az előbb fejtegetett ok miatt, hanem azért sem, mert a különböző tudományágak különböző szemléletmódot igényelnek, így a folyamatos tájékozódás minden területen az egész gondolkodási képességet tartja kondiban, ideértve az intuitív képességeket és a kreativitást. Jobb helyeken ugyan az egyetemek előírják, hogy a szakmai törzsanyagon és a specializációhoz szükséges tárgyakon kívül még valamennyit választható tárgyakból is fel kell venni, amik nem kapcsolódnak a szak tárgyaihoz, sejthető, hogy ez mennyit változtat a helyzeten.

Képek innen: https://www.ofs.edu.sg/resources/ms-un-interdisciplinary-units/unesco-and-our-world-heritage-of-personal-and-cultural-expression/space-research-programs/ , http://blogs.scientificamerican.com/cross-check/2012/12/10/can-engineers-and-scientists-ever-master-complexity/ , http://www.elinext.com/tipstesting , http://www.shapia.com/software-testing.html , http://blog.qatestlab.com/2012/10/23/software-testing-by-human-or-machine-what-shouldshouldnt-be-automated/ , https://www.cs.duke.edu/brd/Teaching/Previous/AI/

Pontosabb, bővebb magyarázat? Kapcsolatfelvétel? Kattints ide!