"Mérnök"

Mottó: "Ha az építészek úgy építkeznének, ahogy a programozók programoznak, akkor az első k.... harkály romba dönthetné az emberi civilizációt!"

 

 "Mérnök" és "ipar" vs. IT

A hétköznapjaink tele vannak az IT gyarlóságaival: már megint lefagyott az X app, az Y böngésző eszi a memóriát és rendszeresen újra kell indítani, a Z oprendszerben újabb kritikus sebezhetőséget fedeztek fel, és így tovább.

Ugyanakkor szintén naponta találkozunk az IT diadalaival: újabb képfelismerő rendszert fejlesztettek ki az X cégnél, az Y egyetemen tovább jutottak a szövegértési rendszerekkel, a Z technológia instant képi kommunikációt tesz lehetővé fillérekért, satöbbi.

Ilyesmiket valahogy sokkal ritkábban hallani a klasszikus mérnöki területekről, pl. a gépészet, vegyészet, villamos- és építészmérnöki  tudományok tájáról. Vajon miért?  Van-e netán összefüggés a kettő között, esetleg valami közös ok, amelyikből ezen két sajátosság ered?

Vegyük kicsit szemügyre először a hagyományos mérnökök munkájának azon vonásait, amik az IT-ben másképp vannak.

Hosszú lesz, de egyrészt úgyis munkaidőben vagyunk :), másrészt pedig szükség van a pontos képre.

Aki nagyon türelmetlen, az menjen a végére, van ott egy egyflekkes összefoglaló is :).

A hagyományos mérnöki tevékenység

Szabványok használata

Egy gépészmérnök csak a legszükségesebb esetben tervez új komponenst, ahol csak lehet, igyekszik már létező, szabványos, 'katalógusból rendelhető' elemekből tervezni, építkezni. Ezt diktálja egyrészt a gazdaságosság, hiszen így a kész rendszer tulajdonosának a későbbi pótalkatrész beszerzésénél könnyű a dolga, nem kell egyedi gyártmányt újragyártatnia, de ugyanebbe az irányba hat a megbízhatóság is, nevezetesen egy komponens csak akkor kap forgalomba hozatali engedélyt, ha annak van érdemi specifikációja (a paraméterek várható érteivel, szórásával, üzemi és extrém minimumával és maximumával), és ez rendszeres szúrópróbákkal ellenőrizve is van. A tervező mérnök tehát ezekre építhet, az ezen modulok megvalósítási problémáival nem neki kell megküzdenie, azt már azok tervezői és gyártói megtették.

Ez olyannyira értékes szempont, hogy épeszű keretek között az anyagtakarékosságot és a méret-optimalizálást is felülbírálja: Ha valahová a méretezés szerint minimum 11.712 mm vastag csavar kellene, akkor nem esztergáltatunk pontosan akkorát pontosan a szükséges darabszámban, hanem betervezünk 12-est, vagy rátartással akár 14-est, amiből fél óra alatt lehet venni kilószámra fillérekért bárhol.

 

Iparági előírások

Egy villamosmérnöki tervezésnél konkrét előírás van arra, hogy milyen felhasználásra milyen fajta vezetékek használhatóak, azokból milyen terhelésre milyen minimum vastagság van előírva, és milyen környezetben milyen szigetelési és érintésvédelmi intézkedéseket kötelező megtenni.

Egy épületvillamossági terv nem kap jóváhagyást, ha ezen előírásoknak nem felel meg, és jó okkal: ez garantálja az üzembiztonság első, legalapvetőbb szintjét (amire aztán épülhet a többi).

Egyrészt tehát ezek számítgatásával sem kell bajlódni (és óhatatlanul elrontani egyet az ezer, vagy akár csak a tízezer esetből), valamint ha más munkájához csatlakozik a miénk, akkor építhetünk arra, hogy ő is ezen elvek szerint dolgozott.

 

Szabályozott folyamatok

Ahhoz, hogy egy termék forgalomba kerülhessen, pontos specifikációt kell adni arról ('mit vállal?'), a felhasználási paramétereiről ('milyen körülmények között vállalja?'), a gyártás mérőszámairól és a folyamat ellenőrzési pontjairól ('honnan tudhatjuk, hogy tényleg teljesíti a vállalást?'), és szükség van a teljes felépítési és működési leírásra is ('hogyan teljesíti a vállalását?').

Azt, hogy közben más problémákat nem okoz, azt nem kell külön igazolni, mert azt az iparági előírások betartása hivatott garantálni.

Az emögötti koncepció az, hogy aki a mi termékünket használja építőelemnek az ő termékéhez, az ugyanúgy számolhasson a mi vállalásunkkal, mint ahogy mi is számoltunk a mi építőelemeinkével.

 

Összefoglalva

A mérnök munkája nem izgalmas és újdonságokkal teli, hanem 'csak' a derék, jól végzett tevékenység megelégedettségét nyújtja: a mérnök jól bevált, kipróbált, megbízható és ellenőrzött elemekből és technológiákból építkezve biztosít a feladatra stabilan alkalmas, kipróbálható, megbízható, ellenőrizhető megoldást.

Ez nem a kreativitás hiányát jelenti, hanem inkább olyan szabályok betartását és olyan hozzáállással végzett alkotást, ami terméket eredményez, azaz valami olyasmit, amit nem-mérnöki felhasználó is tud a megadott célok elérésére használni.

Nem magunknak tervezünk, nem a világ szépségére, nem a tudásunk csillogtatására, hanem egyes egyedül azért, hogy a megrendelő igényeire hatékony és fenntartható megoldást  nyújtsunk.

Az ilyen, terméket előállító tevékenységet hívjuk iparnak.

 

A kutató / fejlesztő / konstruktőr tevékenysége

Ők azok, akik  új, soha nem látott dolgokat találnak fel vagy fejlesztenek ki, akik olyasmiket hoznak létre, amikre más még nem is gondolt.

Ez persze teljesen más megközelítést igényel, mást nyújt és mások a lehetőségek, és mások a problémák is.

 

Nincsenek keretek

Feltalálni valamit kétségtelenül izgalmasabb a mérnöki munkánál, és kötetlenebb is, hiszen új területről lévén szó, még nincsenek előírások, nincsen 'keret', amihez igazodni kellene.

Van, hogy egy prototípus elektromos kapcsolásnál még az érintésvédelem is csak minimálisan van megoldva, hiszen a dolog kísérleti jellegéből nem kell olyasmikkel foglalkozni, hogy pl. mi történik, ha a berendezést kinti hidegből meleg helyiségbe viszik, és így a burkolatán pára csapódik ki.

Az érem másik oldala, hogy olyasmi sincs, amihez igazodni, amire építeni lehetne, tehát a konstruktőr csak magára számíthat, hiszen olyasmikre használ mindent, amire annak tervezői nem gondolhattak, neki semmi se garantált, minden előfordulhat.

Az első, még kísérleti turbinás hajtóműnél sem lehetett előre tudni, hogy hogyan fog viselkedni a tengely anyaga a konstans magas hőmérsékleten a 20 kHz körüli mechanikai rezgés hatására, mert ilyennek azelőtt még nem volt anyag kitéve.

 

Nincs termék sem

Ennek megfelelően viszont az így előállított dolgok, még amikor működnek is, akkor sem tekinthetők terméknek, hiszen nem ismeretesek a korlátaik, nem lehet rájuk érdemi garanciát vállalni, így tiszta lelkiismerettel nem lehetne a felhasználóknak kiadni őket. Nem beszélhetünk tehát közvetlen haszonról sem, nincs megtérülés sem, optimalizálni sincsen mire.

Szigorúan nézve a kutatás-fejlesztés (K+F) egy pénznyelő, amit bizonyos intézmények azért tartanak fenn mégis, hogy az így előálló ismeretekből később, hosszabb távon lehessen gyümölcsözőbb technológia.

A félvezető lézerek tömegtermelése előtt az optikai adattárolás is csak egy érdekes laboratóriumi kísérlet volt, amihez rezgésmentes környezet és drága kísérleti eszközpark kellett; a lehetőséget igazolta ugyan, de mindennemű gyakorlati haszon nélkül. Az majd később jött, amikor már kialakult a lézerdiódák olcsó gyártástechnológiája, amihez viszont pont az optikai adattárolás bizonyított lehetősége adta meg az indíttatást.

 

Más tehát a cél

A cél tehát általában valamely elv vagy konstrukció működőképességenek az igazolása, valami nagyon korlátozott feltételek között ugyan, de működő prototípus előállítása, amiből későbbiekben sok-sok munkával ipari technológia is válhat.

Bár a kutatás által létrehozott működő prototípus tulajdonképpen nem a cél, hanem igazából csak a rajt: abból, ami valamilyen körülmények között egyszer működött, pontosan meg kell határozni a szükséges feltételeket és az elvárható működés paramétereit, és megbízható, reprodukálható, a belelátás és belenyúlás igénye nélkül felhasználható építőelemet, technológiát kell belőle csinálni, ami a fejlesztés feladata.

 

Összefoglalva

A konstruktőr egy sejtésből új technológiát állít elő, vajmi keveset törődve közben rend- és módszerességgel, kiszámíthatósággal, de ez szükséges is ahhoz, hogy az eddigieken túlmutató, új dolgok jöhessenek létre.

Azon dolgozunk, hogy megmutassuk, hogy a dolog megoldható, működésre bírható, hogy lehetséges. Nem valami konkrét célért, hanem az új lehetőségek feltárásáért.

Az ilyen, lehetőségeket feltáró tevékenységeket hívjuk kutatás-fejlesztésnek.

 

A kontár 'Mekk mester' tevékenysége

És persze vannak azok, akik ötvözni próbálják a mérnöki munka megoldás-központúságát a feltalálói munka kötetlenségével, és önfeledten gányolnak bármit és mindent a megrendelőnek, tekintet nélkül annak a biztonságára vagy fenntarthatóságára.

Sokszor pont ezeknek a félmegoldásoknak az előnyös tulajdonságait ('olcsó!', 'kicsi!') használják reklámként, az ezért beáldozott egyéb tulajdonságok említése nélkül, ezzel letarolva a keresletet a korrekt(ebb) megvalósítás elől.

A kontárság kicsiben azzal kezdődik, hogy az illető a réz burkolatot vascsavarral rögzíti (olcsóbb, csak fokozott korróziót okoz), nagyobb léptékben azzal folytatódik, hogy egy kapcsolóüzemű tápegységből kispórolják a szűrést és a túlfeszültségvédelmet (olcsóbb, csak hajlamos leégetni a táplált berendezést), és kicsúcsosodni a sajtóból ismeretes autóipari botrányok környékén szokott.

 

Összefoglalva

Amikor valaki az igénytelenség, a hozzáértés hiánya vagy a rövidtávú haszon növelése miatt indokolatlanul tökéletlen, csökkent működőképességű vagy minőségű kísérleti vagy fejlesztési szintű dolgokat kész termékként tálal, akkor az nem termék, hanem megtévesztő selejt.

Hál'Istennek hivatalos kereskedelmi forgalomba csak nagyon korlátozottan jut tovább az ilyesmi, köszönhetően a kötelező norma-kontrollnak, legalábbis a világnak ezen a részén, úgyhogy az ide tartozó dolgokat inkább a kisipari mókolásnak és a meggondolatlan dzsunka-importnak köszönhetjük.
Nem szabad viszont lebecsülni a sok apró kókányolás hatalmát: ha egy piac 99%-át ilyen teszi ki, akkor aközött elvész az 1% normális, és ez válik normává.

Az ilyen, kontár selejtet termelő tevékenységet pedig egyéb iránt gányolásnak hívjuk :).

 

Az IT szektor jelen állapota

A hosszas felvezetés során meghatározott fogalomrendszerrel tehát hová sorolnánk azt, amit az IT terén manapság látunk? Haladjunk inkább sorban, nézzük először az objektív tényeket.

 

Szabványok

Nagyon kevés a szabványosított dolog. A TCP/IP például az, és nincs is vele gond. A HTML például nem az, és pont annyira lehet is építeni a kezelésének a mikéntjére.

A szabványok velejárói, hogy pontosan leírják az általuk meghatározott dolog mérési pontjait és az azokra megfogalmazott előírást, és ennek megfelelően egy TCP/IP stackről el lehet dönteni, hogy úgy viselkedik-e, ill. hogy megbízható-e, vagy sem.
Az újabb keletű dolgok, amiknek a specifikációja (ha van) erősen használja a 'might/may/shall/should' fogalmakat, azok nem szabványok, egy ilyesmi olyan helyen tud meglepetést okozni, ahol nem is várná az ember.

Meglepően hatékony volt annak idején viszont pl. a JavaEE terén a referencia-implementációval történő specifikálás (glassfish): ami azzal működött, az szabványos, ami nem, az nem.

Lehet, hogy nem a legjobb megoldást fogalmazta meg, de teljesen egyértelmű volt, tehát lehetett rá építeni. 

Iparági kontroll

Nincsen. Konkrétan semmilyen nincsen.

Forgalomba kerülő autót csak úgy tervezhetek, ha megvan a szükséges végzettségem, ha a terv átmegy számtalan ellenőrzésen, és azután a null-széria is kiállja a tényleges törésteszteket.
Szoftvert ezzel szemben bárki fejleszthet, publikálhat és hozhat forgalomba, és a készterméknek sem kell a legkisebb teszten se megfelelnie.

Nem hivatalos irányelvek vannak (SOLID, CleanCode, stb.), amiket általában csak akkor szokás megszegni, ha valakinek épp úgy jön kézre, és perse erre vonatkozóan sincs semminemű ellenőrzés.

Ez különösen azért problémás, mert hiába tartaná magát ehhez valaki, ha az általa használt építőelemek megbízhatatlanok: az eredmény is az lesz.

 

Termék-szemlélet

Szintén hiánycikk. Ritka az olyasmi, amikor egy program teljes és használható dokumentációval érkezik, egyrészt mert a szabványok hiánya miatt nehéz is lenne megfogalmazni pl. azt, hogy mit is értünk a 'HTML-t jelenít meg' alatt, másrészt pedig általános érvként használatos, hogy 'ott a forrás, ha érdekel, nézz bele'.

Most képzeljük el, hogy veszünk egy autót, a leírása egy reklámprospektus, és amikor megkérdezzük, hogy milyen üzemanyag kell bele (oktánszámot is beleértve!), akkor azt kapjuk válaszként, hogy 'hát szedd szét a motort, aztán olvasd ki belőle, hogy mit mennyire tolerálna'...

Kutatás-fejlesztés?

Igen, sajnos a termékek nagy része (a pénzeseké is!) erősen prototípusnak mutatkozik. Működik valahogyan, valamikor, de nincs is célba véve, hogy ez vagy általánosabb legyen, vagy legalább ismerjük meg a peremfeltételeit.

A nyílt forráskódú világ pedig szinte teljesen ilyen, befejezett, vagy legalábbis funkcionálisan teljes verziójú dolgot nem találni, a dokumentáció és support pedig ritka, mint a fehér holló.

És ezzel így még semmi baj sem lenne!
Mármint ha emellett lenne szoftver-termék és -ipar is, azaz a forradalmian ötletes barkácsvívmányok mellett lennének alternatív lehetőségként konzervatív, bejáratott, kevesebbet ámde azt stabilabban tudó programok is.

 

Gányolás?

Hajjaj. Fejlesztő lehet bárki, aki gépelni tud, és be tudja copy-paste-elni a 'git commit; git push' parancsokat...
Árulkodó, hogy a pl. stackoverflow-n feltett kérdésekre a válaszok hány százaléka követi a 'hát biztosan nem tudom, de nekem így működött'-sémát.

El lehet képzelni, hogy milyen minőség és megbízhatóság kerül ki egy olyan fejlesztő keze alól, aki nem ismeri az általa használt eszköztárnak még az általa használt részét sem. Nos, pontosan olyan...

 

A felhasználói kultúra

Meglepő, de nincsenek elvárások! Ezen a téren teljesen általános és elfogadott az igénytelenség, értve ez alatt az igényektől való mentességet, azaz a felhasználók teljesen normálisnak tekintik, hogy

• egy program lefagy
• újra kell indítgatni
• nem tudni, hogy mit csinál (mit hová továbbít)
• adatokat ad ki kívülállóknak
• a felhasználó tudta és engedélye nélkül változásokat eszközöl

Ugyanez tapasztalható az információkkal kapcsolatban is. Nem lepődik meg senki, ha

• egy weboldalon nem az van, mint amit a címe mond
• egy kereső olyan találatokat ad ki, amiken nincs is rajta a keresett dolog
• kéretlen reklámokkal bombázzák az embert
• a kapott információ pontatlan, idejétmúlt, és nincs felelőse (se dátum, se forráshivatkozás)

Közben az általános panaszkodás ellenére mindenki továbbra is használja a kifogásolt programokat/szolgáltatásokat/forrásokat, amikor pedig pl. háztartási gépek kapcsán hasonló esetben nem hogy kidobná azt, de attól a gyártótól mást se venne még egyszer, még akkor sem, ha nincs igazi alternatívája.
Megszoktuk, elfogadtuk, és már teljesen természetesnek vesszük, hogy a szoftver megbízhatatlan és az adat hamis, és nem vagyunk hajlandóak még arra sem, hogy 'a pénztárcánkkal szavazzunk'.

Ahogy a szoftver-világban régen használatos 'stable/unstable/testing' felosztás kihalt, úgy vette át a helyét az 'örök béta' hozzáállás.

Ha az autónktól tapasztalnánk ehhez hasonló üzembiztonságot, akkor attól a gyártótól lábtörlőt se vennénk többé, azt viszont szó nélkül lenyeljük, hogy a telefonunkról azt sem tudjuk, hogy mi miatt használt el mennyi adatforgalmat ill. akkumulátor-töltést.

Szó nélkül töltjük le hetente az újdonságot nem hozó frissítéseket, amikre csak azért van szükségünk, mert a programok/weboldalak igénylik, amik viszont csak azért igénylik, mert már mindenki frissített úgyis, és már ez az aktuális.

Úgy teszünk, mintha a szoftver ingyen volna, és ezért elvárásaink se lehetnének vele szemben, pedig még ha a bekerülési költségét tekintve ingyenes is, a használati költségét tekintve nem az, mert a pénzünkkel fizetünk a sávszélességért, az akkutöltésért, a megbízhatatlanság miatt szükséges mentésekért, az adatvesztés okozta kárért, az időnkkel az összes járulékos (azaz nem a célra irányuló) ráfordított kattintásért, a figyelmünkkel az arcunkba tolt összes spamért és reklámért. Jócskán van ára a szoftvernek (különben nem lehetne belőle megélni), viszont mégis úgy fogadjuk, mintha ajándékba kaptuk volna...

 

Összefoglalva

Az alkalmazói szoftverek terén tehát nem igazán beszélhetünk termékről, tehát iparról sem, és ennek megfelelően mérnökről is csak elég ritkán.

Túlnyomórészt a jóindulatra épülő ad-hoc fejlesztgetés és többé-kevésbé jóra törekvő, ámde kontrollálatlan háztáji munka zajlik, aminek pontosan annyi köze van az iparhoz, mint egy favelában épülő falaknak és házaknak az építészethez és az épületgépészethez.

Ennek pedig a legfőbb, a kontroll hiányán is túlmutató oka a norma hiánya: a túlnyomó többségnek nincs is igénye ennél jobbra.

Mivel bizonytalan alapra stabil dolgot építeni nem lehet, ez a trend így fog sajnos folytatódni is. Kiváltani ezt legfeljebb egy igényes hozzáállásra alapuló szoftver-kultúrával lehetne, viszont annak már induláskor kellene mindazt tudnia, amit a mostani instabil info-világ úgy-ahogy, de tud, ezt pedig egy lépésben lehetetlen megtenni.

Tehát a 'szoftvermérnök' és '-ipar' alá továbbra is odaértjük ezt a színvonalat is, a hagyományos, vagy most már mondhatjuk azt is, hogy a valódi mérnökség és ipar fogalmát is devalválva ezzel.

"Valahol egy fa keményen dolgozva állítja elő azt az oxigént, amit mi most erre elpazaroltunk. Ideje volna lassan megkeresni, és legalább megköszönni neki az erőfeszítést..."