Fertőző hibák

Valahányszor az elé a kérdés elé állunk, hogy kijavítsunk egy ismert hibát, vagy halogassuk egy későbbi alkalomra, ne habozzunk sokat. Az egyetlen út a sikeres, hosszú életű alkalmazás készítésénél az, ha az összes megtalált hibát elkezdjük kijavítani.

Órákat pazaroltam el az életemből, hogy hibákat javítsak különböző hiba-priorizási megbeszéléseken.

A hiba „pártfogása” egy alapvető jellemzője a tradicionális szoftverkészítési szervezeteknek, melyek a „code-then-test” gyakorlat lelkes hívei. Az idő múlásával meglehetősen sok részem volt benne. Elmagyaráznám, hogy az üzleti- és technikai projekttagok a hiba tüneteit és lépéseit lépten-nyomon reprodukálják, ennek a következményeit szenvedik meg a felhasználók. Segíthetnék abban, hogy a belső érintettek összefüggést lássanak a hiba kiújulásának kockázata, és az alkalmazás értéke között, amelyen dolgoznak. Röviden, megtanultam egy üzleti esetet a hibák javítására.Szörnyű volt, minden percét utáltam.

Minden egyes hiba-priorizálási megbeszélés egy kínszenvedés volt. Hosszúak voltak, és tele voltak vitatkozásokkal. Nem értettem akkor sem, és most sem tudom felfogni, hogy a szervezeteket miért nem zavarja, hogy annyi időt és oly sok pénzt pocsékol tesztelésre, ha nem kezdenek semmit azzal az információval, amit a tesztelés felfedett.

Ezekben a napokban döntöttem úgy, hogy inkább „kezeket a billentyűzetre” munkát végzek a szervezetekben, ahol oly nagyra értékelik a tiszta kódot, és ahol nem kell igénybe vennem a hiba „érdekképviseleti” képességeimet.

Még most is van egy tévhit a szoftverfejlesztői közösségben, hogy a hibák elkerülhetetlenek, hogy nem tudod mindet kijavítani és van értelme annak, hogy a hibákra egy javítási/késleltetési döntést hozzanak néhány ROI mutató alapján.Az efféle gondolkodás egy halálos csapda.

Lehet, hogy egy lassú hosszadalmas halál. Lehet, sőt biztos, hogy egy lassú halál, ami nem derül ki azonnal, de minden egyes ilyen döntés egyre közelebb hozza egy termék-, vagy akár a cég halálát. Viszont ha egyszer elindul lefelé a menthetetlen úton elhalasztgatva az „aprócska” hibákat, melyek akkorra már hegyekben állnak, könnyen lehet, hogy lehúzhatjuk a rolót.

Ha azt hiszed, hogy túlságosan drámai vagyok, fontold meg: az a két vállalat ahol a legtöbb időt töltöttem hiba-priorizáló üléseken már halott cégek. Szóval úgy gondolom, tudom mi egy halálos csapda.Engedd meg, hogy elmeséljem a történetüket.

Az egyik a társaságok közül szoftvert adott el közvetlenül a fogyasztóknak. A másik egy fizetett szolgáltatás volt, egy szoftverkomponenst terjesztett nagy hardvergyártókon keresztül. Mindkét esetben „nem volt idő rá”, hogy kijavítsák az összes hibát, voltak mindig magasabb prioritások. Ki kellett adnunk a funkciókat, szorítottak a határidők, meg kellett felelni az ügyfelek igényeinek.

Mindkét esetben a vezetői csapat nyomást gyakorolt ránk, hogy az új verzió kiadásának késése miden egyes nap milyen hatalmas költségkiadást jelent a cég számára. Noszogattak minket hogy legyünk gyakorlatiasabbak. Ésszerű. Hozz üzleti döntéseket optimalizálással.

A vezetők nem hibáztak. Mindkét vállalat a gyorsan változó piacban utazott, ahol a sebesség volt a kritikus pont. Amikor a cég eladott a hardvergyártó cégnek, a határidők hihetetlenül rövidek voltak. Csak egy nappal csússz el a határidővel, és kicsúszik a talaj a lábad alól, ami azt jelenti, hogy nem látunk bevételt további 6 hónapon keresztül.

Ilyen körülmények között könnyen belátható, hogy miért hoztuk a döntést, amit hoztunk.De ne feledd, a két vállalat halott.

Nem a hibák voltak, amelyek tönkretették őket közvetlenül, sokkal inkább az, hogy a hibák átható fertőzéssé lettek. Ezek akadályoztak minket és lassították le a termelékenységet. Végül megbénulunk. Nem tudtunk még minimális változtatásokat sem végrehajtani biztonságosan vagy gyorsan.

Valahányszor előkerült a kérdés, hogy halogassuk vagy javítsuk a hibát, ránéztünk a velejáró költségekre, összenézve a kibocsátott szoftver ismert hibával: bosszús ügyfelek, technikai támogatás és a felszabadító patch-ek a legsúlyosabb esetekre.

Nem tévedtünk a költségeket illetően. Így nem voltunk meglepve hogy az új fejlesztésekben megszakításokat eredményezett és arra kényszerített bennünket, hogy még több erőfeszítést fordítsunk a javításokra. Még több embert béreltünk, hogy lépést tartsunk a megnövekedett igényekkel és azt mondogattuk magunknak, hogy ez csak üzleti költség a szoftver iparban.

Volt azonban, hogy a rejtett költségek teljesen lecsapoltak: órák vesztek el a hibákról való vitatkozások alatt a hiba-priorizálási megbeszéléseken; órákat vesztegettünk azzal, hogy ugyanazon ismert hibákon bukdácsoltunk újra és újra; órák teltek el a törékeny és hibára hajlamos kóddal való küzdelemmel; és órákat töltöttünk a feladatlista kategorizálására és katalogizálására. Ez nagyon demoralizáló volt, és rendkívül drága.

Minden elfolyt idő kiszipolyozott minket, és csökkentette a kapacitásunkat. Láttuk, ahogy megtörténik de nem volt erőnk arra, hogy megfékezzük. Mire rájöttünk mekkora bajban vagyunk, már késő volt. A fertőzés már gyökeret vert, és semmi esély nem volt a teljes alapkód átalakításra, hogy jobbá tegyük a dolgokat.

A megbízó szoftvercég végül tönkrement, mert mozgékonyabb versenytárs került a képbe. Egyszerűen már nem tudott lépést tartani a változó piaci igények sebesen változó területén a mi segítségünkkel.

A hardvergyártó cég is tönkrement, mert nem tudtunk elég bevételt hajtani nekik. Ez a kis bevétel is köddé vált és a nagy hardvergyártó cégek pedig egytől-egyig elfordultak tőlünk. Az OEM cégek belső személyzete nem hitt már a szoftverünkben, amikor az ő ügyfeleik panaszosan követelték a technikai támogatást, az OEM technikai támogatása pedig a mi szoftverünket hibáztatta.

Van ebben egy tanulság a hibák tolerálásának valós költségéről és az azt követő hiba-priorizálási gyakorlatról. Sokáig tartogatni egy hibát sokkal többe kerül, mint azt az ember gondolná. Egy triviális, kis kozmetikai probléma kijavítása csak rövid időbe kerül. Ha vitát nyitsz róla, hogy javítsátok-e vagy sem, utána jársz, majd megnézed újra, aztán átgondolod a fontossági sorrendet, majd megvitatjátok, hogy újra elhalogassátok-e vagy sem, máris órákat pazaroltál el.

Éppen ezért, már nincs türelmem a „hibák elkerülhetetlenek, nem tudod mindet kijavítani” gondolkodásmódra. A hibák megölnek. Megteszik lassan, fájdalmasan, könyörtelenül. Szeretnéd, hogy a szoftver elkerülje ezt a szörnyű halált?

Szakíts az összes hiba-priorizáló megbeszéléssel; szánj több időt a hibák javítására, ahelyett hogy megakadályoznád azt. Tesztelj előre és gyakran, hogy megtaláld a hibákat minél korábban. Javítsd ki a hibákat amilyen gyorsan csak lehet, közvetlenül az azonosításuk után, azelőtt hogy betörnének néhány ablakot.

És bármit teszel, ne fogadd el mentségnek azt, hogy a fejlesztés alatt elkerülhetetlen a hiba megmaradása és az egyetlen gyakorlatias megközelítés az, hogy költség/haszon döntés-e vagy sem, hogy javítsátok-e azokat. Az ára szinte mindig jóval magasabb, mint bárki is hinné.

Szerző: Elisabeth Hendrickson