Dobrý den Johne, přátelé

rád bych využil možnosti zareagoval na články, kterými u tebe Zsolt Szabo nedávno otevřel téma vývoje softwaru.

Po pravdě, s články nejsem moc spokojený.

Začnu od konce, respektive od Zsoltova prvního článku. Ještě předtím bych ale rád varoval všechny programátory a vývojáře – dál nečtěte. Riskujete zvýšený krevní tlak a možná i pocit ukřivděnosti. 🙂

Zsolt rozebral možnosti vývoje web aplikace a vytvořil krásný rozhodovací strom. Jeho zásadní nevýhodou je však to, že i přes Zsoltovu snahu nebere v potaz realitu většiny podnikatelů, tedy lidí bez jakýchkoli znalostí o vývoji softwaru.

Většina programátorů apriori předpokládá, že všichni podnikatelé tuší, co software je, co všechno (a proč) obsahuje i jak vzniká.

Lidé, na které Zsoltův článek míří, však podle mě nemají žádnou potřebu tomu rozumět. Nepotřebují a nechtějí vědět, co je frontend a backend. Vůbec je nezajímá, jak se objeví(?) funkčnost, kterou vyžadují.

Pro podnikatele jsou důležité jiné věci – aby bylo hotovo co nejdříve a nejlevněji, aby software dělal to, co má, kdy a kde má a aby vypadal podle jejich představ. A to je kámen úrazu.

Další článek zametl s celou problematikou proč je něco vyvinuté pozdě jen tvrzením, že podnikatelé jsou příliš optimističtí a že nebyl správně definovaný rozsah. Škoda, že nezmínil, že existují spousty přístupů a metodik, jak se přesně tomuhle vyhnout.

Abych si přihřál polívčičku, tohle přesně je práce projekťáka u dodavatele a quality managera na straně objednatele. A není to vážně tak triviální. (Tedy, pokud se nesmíříte s pseudo-agile přístupem, kdy prostě platíte programátora, dokud to nevypadá, jak chcete. A on přepisuje tam a zpátky podle toho, jak pískáte. To ale v realitě skončí spokojeností málokdy.)

Vývoj softwaru totiž není hladká cestička a obsahuje spoustu odboček, na které zadavatel nemyslí a jejichž opomenutí se připomene mnohem později a za mnohem více peněz, než kdyby se tyto problémy řešily včas.

V zásadě jste zcela vydáni na milost a nemilost dodavateli, spoléháte na jeho profesionalitu a doufáte, že se nenechá přemluvit k šetření na nesprávných místech. A to je kámen úrazu, protože z principu dodavatel chce jen vydělat a všechny tyhle metodiky a přístupy ukusují z rozpočtu a z jeho zisku. A kdo si na sebe chce dobrovolně ušít bič profesionálního dohledu, že?

Horší je, když má podnikatel pocit, že vývoji softwaru rozumí, protože už jeden projekt v praxi viděl, ve firmě spustili webové stránky vytvořené v ekosystému WordPress, či se dokonce kdysi na škole učil programovat. Takový podnikatel má představu, že už vše viděl a když bude projekt řídit jako svoji firmu, tak vše ohlídá, bude to včas a skoro zadarmo. Z jeho pohledu dodavatelé všechno jen zbytečně komplikují.

Takový projekt obvykle končí totální katastrofou. Obzvlášť když je dodavatelem kodér (úmyslně neříkám programátor nebo developer) bez znalosti projektového řízení (a co hůř, s představou, že to v žádném případě nepotřebuje), nemůže to dopadnout jinak než nespokojeností obou zúčastněných stran.

A tím bych ukončil obecné povídání. John mě požádal, abych se podělil o skutečné příběhy katastrof, jichž jsem byl svědkem za 18 let, co tohle dělám.

Jednotlivé příběhy jsem musel kvůli NDA anonymizovat, ale pokud se v tom poznáte, tak je to čistě shoda náhod. 🙂

Moje práce bohužel není vidět. Když ji dělám pořádně, od začátku projektu, tak vlastně projekt běží hladce a rizika, o kterých mluvím, nikdy nenastanou, takže jsem “zbytečný”.
Problémy, kterým zabráním, z definice nenastanou.

Takže zábavné jsou samozřejmě ty ostatní historky.

Příběh první: Pohřbená multikára aneb “To není potřeba testovat, vždyť to běhá u desítek zákazníků roky”

Kdybych dostal stovku pokaždé, když slyším “to je ověřený kód, to nám běhá v x zařízeních roky”, byl bych na tom jako John. Bohužel, tenhle argument je naprosto neplatný. Jediné, co to znamená je, že se chyba ještě neprojevila.

Chci to ukázat na následujícím případu – software, velmi jednoduchý, v zásadě jen řídil dávkovač písku v lomu.

Dovedete si představit stav, ve kterém dorazil nebohý majitel firmy ráno do práce, když mu ve 3 hodiny ráno zavolali z kamenolomu, že jeho software namísto 1 kubíku nasypal 9 a jen díky tomu, že šel řidič na cigáro a množství zadával z vnějšku kabiny, nemusí řešit smrťák?

Ano, software fungoval skvěle, jen prostě proměnná “kolik” nebyla (tentokrát?) binárně “0001” ale “1010” (tedy 9). Díky intenzivnímu zkoumání jsme nakonec našli problém.

Programátor šetřil pamětí a využil zbytek registru na počítadlo doby od restartu. No a po uplynutí “1111 1111 1111 ” hodin (tedy 4095 hodin decimálně, neboli 170 dní) bez restartu přeteklo počítadlo o paměťovou buňku vedle.

Tato řídicí jednotka běžela minimálně 6 let v provozu, než chyba nastala, a stejných cca 80 jednotek je roztroušeno po Evropě.

Argument “roky nám to funguje” prostě není a nikdy nebude platný. Pravděpodobně si říkáte, že tato chyba měla být nalezena při testování. Bohužel, takový test, který by odhalil všechny možné chyby tohoto druhu, lze napsat snad jen pro družici (psal jsem to), ale pro 80 jednotek do lomu je to totální overkill.

Šlo tomu tedy předejít testováním? Ne.

Šlo tomu předejít jinak? Samozřejmě že ano. Stačilo nastavit správně coding standard (standard pro kódování = jak co psát, jaké konstrukty používat a jaké ne) a udělat jednoduchou revizi kódu druhým programátorem.

Jenže to stojí trochu času a navíc je to “zbytečná práce”.

A moje zbytečná práce je nutit ostatní dělat tyhle zbytečné práce. Nakonec pak většinou ale nepohřbíme náklaďák pod hromadou písku.

Příběh druhý: “Kolik stojí jeden vadný bit”
Když jsme mluvili o testování, vždycky je otázka, kolik do testování chceme investovat a proč. To řeší docela složitý proces řízení rizik. (Opět PM/QM práce.)

Ale není to vlastně zbytečné? Navíc testování je “drahé a neproduktivní”, Ne?

A proč vlastně tohle píšu? Neb příběh, kolik stojí jeden bit.

Představte si sériovou produkci kde výsledkem je ECU včetně softwaru. Na každém kusu, který linka vyrobí, firma vydělá 5 Euro. Měsíčně jich linka vyrobí 200 000.

Bavíme se o jedné z asi 50 řídicích jednotek, které má moderní auto napojené na sběrnice. Tedy vážný vývoj, ne jako v předchozím příběhu, který byl v zásadě o prototypové výrobě.

Software v jednotce měl jít aktualizovat při servisu. Bohužel, programátor, který software psal ho do jednotky nahrával jen přes testovací stanici. Žádný z testů probíhajících v emulovaném prostředí nebyl schopen odhalit, že vlastně přes sběrnici nahrát nejde, a to kvůli jednomu přeplému bitu.

Nechci se bavit o tom jak a zda mohla být tahle chyba odhalena, jen vám chci ukázat jaké důsledky mohou nastat z byznysové stránky a o čem jako kvalitář taky uvažuju.

Jednotka stojí 10 EUR, zisk je na ní 5 EUR. Jediné řešení je ji při servisu prostě nahradit. Za to si servis účtuje cca 100 EUR navíc za práci (a 5 EUR za novou jednotku je náš náklad).

Jednotek s touto vadou bylo vyrobeno 350 000 (linka jela skoro dva měsíce).
Takže jeden vadný bit stál zhruba 36 milionů EUR.

Možná by byl lepší nápad zaplatit víc testerů a kvalitářů, a smířit se s tím že vývoj bude o půlku delší, že?

Příběh třetí: “Ty papíry nepotřebuju, hlavně ať to rychle jezdí”

Znáte ten pocit, když zákazník nemá vždy pravdu? Když chce nesmysl? To se ještě dá překousnout. Problém je, když Vám tvrdí něco jiného, než co má ve smlouvě.

Ve smlouvě na rekonstrukci tramvaje byla schovaná noticka, “a vývoj proběhne dle BOSTRAB”.

Nikdo z obchodu si s ní nedělal starosti, vývojáři se snažili aby tramvaj fungovala jak má, zákazník nás popoháněl.

“Dokumentace? Analýzy? Zkoušky? To já nepotřebuju.” i to je Vám schopen zákazník oficiálně oznámit.

Bohužel, když byl prototyp hotov, tak zákazník prohlásil: “Za 14 dní máte termín, kdy budete řešení obhajovat na drážním úřadě jako změnu na schváleném typu”. Což je právě to, co BOSTRAB řeší.

A tehdy začalo půlroční peklo dopisování dokumentace, zpětné vytváření analýz a, upřímně, i falšování záznamů o věcech, co s funkčním prototypem už nejdou dělat.

Ano, zákazník nic nepotřeboval, ale drážní úřad ano. A firma to celou dobu měla ve smlouvě.

Požadavky na vývoj podle něčeho, případně doložit zkouškou, má obrovské dopady na to, co musíte a jak to musíte udělat.

SW kvalita je tady právě kvůli adekvátní analýze problému a ušetření obdobných krizí.

Příběh ćtvrtý: “Analýzu rizik udělejte až zpětně, je to jen plýtvání časem”
Jednotlivé kroky výrobního procesu mají svůj čas a místo. Když je chcete dodělávat zpětně, stává se z nich jen formalismus, který nic nepřináší. Přinejhorším pak musíte všechno zpětně předělat. A to je drahé.

Typickým případem je analýza rizik na designu (FMEDA).

V metru jsou dveře, které se otevírají na povel z nadřazeného systému. Otevírá je motor, který zná polohu dveří, ale tu si ve skutečnosti jen dopočítává jeho řídicí jednotka na základě povelů do motoru.
Ve dveřích je senzor (kontakt), který detekuje, jestli jsou dveře zavřené a nebo ne.

Pokud děláte analýzu rizik zpětně, můžete se dostat do následující situace.

Nad dveřmi jsou dvě řídicí jednotky připojené na dvě nezávislé sběrnice, které řeší spoustu věcí v segmentu vozu, kromě ovládání dveří. Je potřeba z nich vyvést kabely pro čtení senzoru a pro ovládání motoru.

Projektant (navrhuje kabeláž, úchyty, prostě mechaniku) vám klidně zavede obojí do jedné jednotky. Elektrický návrhář s tím nemá problém. Programátor do ní v pohodě napíše logiku ovládání i logiku detekce zavření.

Nikdo neudělal nic špatně, všichni udělali svou práci jak měli. Vše funguje.

Ale je tu obrovský bezpečnostní problém. Ano, a to je právě obor FMEDA – detekovat problémy a řešit je změnou v návrhu.

Pokud tato jednotka selže, naprosto nevíte, jestli jsou dveře zavřené nebo otevřené. (A pokud selže pořádně, ani nevíte že selhala a myslíte si, že víte v jakém jsou stavu.)

A pak se metro rozjede s otevřenýma dveřma…

Řešení je strašně jednoduché, stačí mít ovládání v jedné a detekci v druhé jednotce (která tam tak jako tak je).

Malá změna v kabelovém svazku a přesun kódu z jedné jednotky do druhé.

Ve fázi vývoje je to práce možna na 2 hodiny s nulovými náklady.

Když ale máte ve výrobě zadané všechny přípravky a všechny kabelové svazky, tak se jedná o změnu za stovky tisíc v nákladech.

A to vážně nechcete.

Jo, není nad to dodělávat ty “papíry” zpětně, hlavně ať nám jede výroba.

Příběh pátý: “Vždyť je to jen beta verze a nikdo ji nenajde”

Bezpečnost informací
– řešíte to vůbec? Co vás možná zajímá jsou zkratky jako GDPR, ISO27000….
Ale vážně chápete příčiny?

Byla jedna firma v hyperkonkurenčním prostředí. Ta si nechávala vyvíjet svůj nový e-shop a jako obvykle, nechala vše na dodavatelích.
Dokonce, protože je to jednodušší, jim poskytla pro vývoj svou ostrou databázi zákazníků a data o smlouvách.
Proč ne, přeci se to bude importovat tak jako tak.
Proč dělat anonymizovaný testovací dataset, to je plýtvání časem a penězi.

Bohužel, jak říkám, prostředí je hyperkonkurenční a jeden konkurent si googlil a hledal. Hledal něco úplně jiného, ale našel beta verzi eshopu. Začal tedy klikat a zkoušet.

Doteď dobrý, mohl si prohlédnout design, možná se inspirovat, ale to by mohl za měsíc při spuštěné ostré verze tak jako tak.

Naneštěstí pro firmu a naštěstí pro něj, si něco chtěl přes ctrl+a zkopírovat. A najednou si při označení všeho všiml bílého linku na bílém pozadí – Admin. (Jo jo, super nápad, takhle schovat nezabezpečený vývojářský přístup, toho si nikdo nevšimne…)

A díky tomu si vytáhl celou databázi zákazníků, uzavřených smluv a cenových nabídek.

Moc dobře pro něj, zisk pár miliónů a desítek přetažených zákazníků.

Jo, byla to jen betaverze na doméně z gabonu…

Příběh poslední : “Dokumentaci i kód máme, tady v té skříni”
Možná jste už slyšeli o Cargo kultu. Napodobování vnějších znaků nějaké činnosti totálně bez pochopení toho, k čemu slouží.

Krásným příkladem je firma, která slyšela, že s vyvinutým SW by měla dostat i zdrojový kód. Mít zdrojový kód je dobrá věc, jde pak změnit dodavatel. Ale když přišlo na věc, bylo vše jinak.
Ono totiž předat někomu 500 vytištěných stran s tím, že tady je zdrojový kód, je dost na nic. Mám dojem, že netaktní vývojář se u zákazníka smál snad deset minut.

A firma zaplakala a vyvíjet se muselo z čisté louky.

Není to osamocený případ a problémem není jen kód. Netušíte kolik věcí exportovaných do PDF jsem viděl. Designy, schémata, pokladačky, ale třeba i grafiku.
K čemu to je, když to zpětně do nástroje nenahrajete?
Povím vám to, je to k ničemu…

Vývojová dokumentace má sloužit k tomu, aby jste byli schopni ze zálohy (archivu) obnovit projekt tak, aby šlo jednoduše a levně opravit malou chyby nebo přidat novou funkci. Ne proto abyste měli “papíry”, protože to chce standard.

A tak je to bohužel se vším. Doufám, že jsem vám na pár případech ukázal proč a jak je lepší se občas zastavit a přemýšlet, že standardy nejsou jen papíry a pro úřady, a že hurá přístup není ani nejlevnější ani nejrychlejší.

Kdybyste si chtěli popovídat, nebo se na něco zeptat, moje stránky jsou www.softsyng.com a můj linkedin je https://www.linkedin.com/profile/view?id=46111140&trk=nav_responsive_tab_prof a mail je petr.svimbersky@softsyng.com

Bohužel vím, že stejně si musíte prožít alespoň jeden podobný příběh, než vás napadne, že je možná dobrý nápad nedělat vše sami a nevynalézat znovu kolo.

Povězte mi v komentářích, jak se strašně mýlím a dramatizuju,
Petr