Újabb eszmefuttatás a jó szoftver-rossz szoftver témakörében.

Újabb eszmefuttatás a jó szoftver-rossz szoftver témakörében.

Az egyik belső vállalati szoftverünkkel állandóan bajom van. Jóvá kell benne hagynom valamit, de nem sikerül: rákattintok a megfelelő gombra, erre a szoftver kritikus hibával eldobja magát. Egy olyan funkciónál, amit heti szinten kellene használnom, nem csak nekem hanem a cégnél lévő összes menedzsernek.

A jelenséget annak rendje-módja szerint bejelentettem a Helpdesk-nél, képernyőkép, hibaleírás, útmutató lépésről lépésre. A programozók nem kapkodták el, időnként kérdeztek valamit, de érdemi változás nem történt. Kb 1 hónap után úgy döntöttek, hogy belenyúlnak az adatbázisba, és amit az adott gombbal kellett volna jóváhagynom, azt az adatbázisban jóváhagyottra állítják. Ezzel az ügy lezárult.

Azaz mégsem, mert következő alkalommal, amikor megint jóvá kellett hagynom valamit, a program pont ugyanúgy elhasalt. Ismét bejelentettem a hibát, és elgondolkodtam.

Rálátásom van a cégnél dolgozó különböző csapatok teljesítésére, és tudom, hogy ez a csapat kapja a legtöbb hibajegyet havonta. És fejlesztőből is sok van, egy egész hadseregnyi, hogy dolgozzon azokon a hibajegyeken. Mondanom sem kell, kiszervezett fejlesztők.

Nagyon úgy tűnik, hogy ők mindig csak ideiglenes megoldásokra koncentrálnak, az adatbázisba belenyúlva korrigálják az adatokat, ahelyett hogy megkeresnék a hiba forrását, és azt oldanák meg. Hosszú távú megoldások helyett rövid távú – quick&dirty – megoldásokat alkalmaznak.

Sajnos sok szoftverfejlesztő követi ezt a gondolkodásmódot. Belenyúlni az adatbázisba egyszerű. Nem kell gondolkodni, csak csinálni. Egyszerű az élet, csinálom amit mondanak, a következmények nem érdekelnek. Ha lesznek is következmények, majd megint belenyúlok az adatbázisba, és megy minden tovább.

Ugyanezek a szoftverfejlesztők azok, akik úgy fejlesztenek interfészt, hogy nincs hibakezelés. Minek is? A program egészen addig jól működik, amíg nincs hiba a feldolgozásnál. Aztán ha az adatvitel során hiba lép fel, ha a kapott adatok nem megfelelő formátumúak, ha programhiba miatt megszakad a feldolgozás, akkor ott állunk gatyával letolva. Jobb esetben „csak” elszáll a program, valahol megjelenik egy hibaüzenet. Rosszabb esetben átugorjuk a hibát, a program fut tovább, senki sem veszi észre ami történt. Aztán majd 1-2 hét, esetleg hónap múlva valaki kiszúrja, hogy hiányoznak adatok. Vagy esetleg 6-12 hónap múlva az auditoroknak szúr valami szemet.

Pedig annak idején tanultunk olyanról, hogy CRC kód, handshake, hearthbeat, és társai. Mert szoftver írni könnyű, csak jó szoftvert írni nehéz.

A fenti rendszer beszállítójáról pedig annyit, hogy a megállapodás szerint a támogatásért nem átalánydíjat fizetünk, hanem hibajegyenként T&M alapján. Vagyis konkrétan anyagilag érdekelt benne, hogy a szoftver hibás legyen, minél több hibajegyet generáljunk, és rendszeresen bele kelljen nyúlni az adatbázisba.
Szerintük ez a „best practice”, amit minden más szoftver támogatásánál alkalmazni kellene. Szerencsére nem magyar cégről van szó.