Software bez chyb – proč vznikají chyby

Možná jste už slyšeli o tom, že existují firmy, které vydávají software bez chyb. Možná jste už dokonce četli nějaké případové studie. Když to tedy jde, proč to nedělají všichni? Proč tolik softwarových firem vydává svoje produkty s chybami a způsobují tím frustraci svých zákazníků a programátorů, kteří předávají nekvalitní produkt zákazníkům jen velmi neochotně a pod manažerským tlakem.

Sprcha - metafora jednoduchého systému

Ty samé firmy přitom používají spoustu mechanismů pro kontrolu kvality. Pro veškerý kód používají review kódu. Píšou automatické testy. Dokonce mají celé oddělení QA, jehož zaměstnanci jsou placení za to, aby našli chyby dříve než zákazník.

No, možná právě proto. Tyto firmy se pokoušejí zasáhnout na nepravém místě. Pojďme si na chvíli vypomoci metaforou. Každý softwarový vývoj tvoří takzvaný systém. Systém se skládá z částí a z interakcí mezi nimi. Důležité jsou dvě části systému – bod pozorování a bod ovlivnění. Například v případě automobilu je bodem pozorování tachometr, zatímco bodem ovlivnění je plynový pedál. V případě sprchy je bodem pozorování sprchová hlavice, ze které teče voda, bodem ovlivnění je vodovodní baterie.

Jednoduchý model ystému s bodem pozorování a bodem ovlivnění

Jak ovlivnit systém?

Pokud nám připadá, že auto jede moc rychle a pokusíme se ho zpomalit tím, že ručičku na tachometru budeme tlačit dolů, asi moc neuspějeme. Stejně tak, pokud se pokusíme zmenšit množství vody tekoucí ze sprchy tím, že začneme zacpávat dírky na sprchové hlavici, je jasné, že dosáhneme jenom toho, že voda z nezacpaných dírek bude proudit o to rychleji.

V případě vývoje software je bodem pozorování okamžik doručení zákazníkovi, zatímco bodem ovlivnění je okamžik, kdy kód vzniká. Už víte, proč žádná z technik vyjmenovaná na začátku článku nesnižuje množství chyb? Ano, je to proto, že žádná z nich nepůsobí v bodě ovlivnění, ale různě daleko od něj, někde mezi bodem ovlivnění a bodem pozorování. Čím dále od bodu ovlivnění jsme, tím marnější je naše úsilí něco zlepšit.

Oddělení QA, která dělá manuální akceptační testy těsně před vydáním je proto spíše projevem zoufalství než mechanismem pro zajištění kvality. (Tím neříkám, že by v softwarových týmech neměli existovat lidé, kteří se specializují na testování. Jejich role je ale jiná, než hledání chyb v produktu. O tom ale někdy jindy.)

Proč tedy firmy používají neúčinné praktiky? Protože systém, se kterým manažeři pracují, je podstatně složitější než sprcha a není jednoduché vidět, kde je přesně bod ovlivnění a jakým způsobem se změna na tomto místě promítne v bodě monitorování. Můžeme si to opět zobrazit na zjednodušeném modelu:

model systému pro vývoj software

Příčina a následek ve vývoji

Způsobují to dva systémové problémy

  1. Příčina a následek jsou od sebe vzdáleny v čase

Například firma vydává software jen jednou za 6 měsíců. Pokud tedy programátor nevědomky udělá v kódu chybu, tato chyba může existovat několik měsíců bez toho, aby si jí někdo všiml. V okamžiku, kdy se chyba projeví, může už být původní změna překrytá mnoha dalšími změnami, takže není zřejmé, která změna vlastně chybu způsobila.

  1. Příčina a následek jsou od sebe vzdáleny v prostoru

Například firma má specializované oddělení zákaznické podpory. Toto oddělení filtruje problémy od zákazníků a do vývojového oddělení propouští jenom ty, které není schopné vyřešit. Pokud tedy programátor udělá chybu, kterou je schopen vyřešit pracovník podpory, v nejhorším případě se o tom vůbec nedozví, protože se k němu tato informace vůbec nedostane.

Mimochodem v tomto případě nastane ještě horší efekt – taková situace se postupně projeví tím, že oddělení podpory bude přetížené a bude žádat o posily. Když je dostane, tak celou situaci ještě zhorší, protože bude schopno vyřešit ještě více zákaznických problémů bez účasti programátorů a tím dále zamlží jejich odpovědnost za tyto problémy.

Závěr

Takže jak se vyhnout produkci chyb? Nejprve radikálně zkracujte cestu mezi bodem ovlivnění a bodem pozorování, a to jak v čase, tak v prostoru. Je to nezbytná podmínka k tomu, abyste mohli udělat další krok – vzdělávání týmů v technické oblasti tak, aby byli opravdu schopní psát software bez chyb. Ale o tom zase příště.

Pokud se vám článek líbil, sledujte mě na LinkedIn nebo Twitter.

Napsat komentář

13 + six =