Názory k článku
Nejzbytečnější chyby v programátorské historii

ale mirne zmatene napsane, clanek nema strukturu, blbe se to cte....

Čte se blbě taky proto, že obsahuje spoustu nekvalitně přeloženého textu z angličtiny.

Naopak, mě přijde jako ten z lepších článků zde na Rootu. Hezký a srozumitelný. Jen tak dále. Struktura mi vyhovuje.

Proč jste si tak jistý, že takový software neexistuje? Existují oblasti, kde je SW tak důkladně testován, že si takovou záruku představit dokážu. Např. medicína.

spis neco jako SW pacemakeru

Neděs, mě teda jako první asociace napadl Peacemaker. A to je fakt účinná medicína, i když softwaru má jen šest kousků :-D

Ale houby jistí. Prostě si jen za velmi levný peníz najímají externí testery. Chápu, že je to pro někoho výzva, ale z čistě ekonomického pohledu je těch $20 za odhalenou chybu hrubé podhodnocení ceny práce.

http://cr.yp.to/djbdns/guarantee.html - stare, ale predsa...

Na tohle se ovsem jeden hack opravdu nasel, i kdyz trochu nerealny:

Soft byl psan v dobe, kdy pocitace byly pouze 32bit a 64bit vyhradne v navrhu tech nejodvaznejsich.

Nekomu se podarilo prijit na to, ze QMail selze, kdyz bude pouzivan na 64bit platforme a zasilany email bude mit delky vetsi nez 4GB :D

Pan Bernstein takovou chybu samozrejme neuznal a penize tak vyplaceny nebyly.

Prof.Knuth vyplácí odměnu za nalezenou chybu.
http://tex.loria.fr/historique/rewards1995.html

No zrovna MCNP nie je sw pre siroku verejnost, je to cisto vedecky soft, povacsinou vo fortrane. Robia sa na nom Monte-Carlo simulacie spravania sa castic. Tu ak niekto najde chybu, je to cest a nie zarobkova cinnost.

Hm, openbsd je vyborny priklad, komiku.

Ze to rikas zrovna ty. :-)

Takový SW samozřejmě existuje a běžně se s ním setkáte. Možná jste se nechal zmást textem článku, ale i v řadě v něm uvedených případů platil škodu dodavatel SW. V případě ERP systémů, SW pro medicínské aplikace, SW pro správu letadel, vojenské techniky, zdravotnického zařízení, jaderných zařízení - v těhle případech je naprosto běžné, že dodavatel SW ručí za způsobené škody. A naprosto běžně je i platí :-) Stačí aby se ERP zamyslelo a nepodařilo se vytisknout dodací list - a už letí faktura za zmeškanou dopravu. Naštěstí pro dodavatele SW žije řada českých firem v domění, že to není běžná praxe, v čemž je navíc utvrzuje praxe státní správy, kde se skutečně odpovědnost za způsobené škody běžně nevyžaduje. Ovšem naše firma není česká a tak nám opravdu čas od času platí dopravu IBM :-)

Mluvite o komercnich systemech, kde ve vetsine pripadu je podepsana smlouva o dodavkach sluzby (tedy SLA, reaktibilita teamu, dostupnost sluzby, udrzba, obnova HW), ktera se s koncovym zakaznikem/beznym uzivatelem neuzavira!! Takze firmy/pravnicke osoby maji samozdrejme vetsi ochranu (takovou jakou si nasmlouvaji s dodavatelem, protoze dodavatel ma UC se subdodavatelem) pri pripadnem kolapsu, diky chybne naprogramovanemu SW ... tedy faktem zustava, ze pokud jste bezny uzivatel a napr. Wokna Vam zhavaruji, diky spatne napsanemu ovladaci, ktery sahl do jemu neprirazene pameti, tak muzete jen cekat na patch a tise nadavat ... opravi to MS nebo vyrobce driveru, pokud uzna chybu a prizna se...

Tři řádky kódu denně vám připadá málo?

Při práci pro nejmenovanou velkou zahraniční firmu jsem hledal chyby v cizím kódu (sice C#, ale neuvěritelně zprasené, autor byl dávno ten tam a dokumentace žádná). Jednu klidně celé 4 dny a oprava byla jen jeden řádek. Takže vlastně 0.25 řádku za den :-)

Za nás se říkalo, že za dobrým assembleristou zůstane 4000 instrukcí ročně. Ne to, co napíše, ale to, co přetrvá. Bojím se, že v současné době to není o nic lepší, spíše naopak. Většina kódu, který se napíše, jde potom stejně do přepisu...

20 instrukci denne slo na Z80, kde mel clovek system pod kontrolou
s dnesnimi x86 monstry na produktivitu 20 instrukci denne zapomen

Tak to musela být práce snů ;-) Doufám že alespoň dobře zaplatili.

Já mám rekord jeden znak za tři dni. :-)

Ale to je oprava, ne psaní ...

Nikdy ale opravdu nikdy zároveň neupgradujte obří IT systém a nerestruktura lizujte společnost!

To mi pripomina nase vysoke skolstvi a financovani vedy. Zmena vyse dotaci ve vsech kapitolach + zmena systemu prerozdelovani v jeden okamzik. Idealni situace (jak pro koho) neb je naprosto nepredvidatelne kolik penez kam ve skutecnosti prijde. Tak uz vim odkud vitr vane :)

Omlouvam se za prihlouple tema, ale fakt se mi to uplne vybavilo :)

Mě to zase připomíná českou snahu o e-goverment - datové schránky, czechpoint, elektronické podpisy.

No nevím jak ve financování vědy, ale pro průmysl je ta věta z článku dost nepřípustná. Proč upgradovat IT systém, když se ve společnostni nic nemění? A opravdu je možné restrukturalizovat společnost bez změny IS? Leda společnost, která IS nepoužívá v řízení svých procesů. Já osobně naopak považuji za přínosné, aby se obě změny odehrály současně. Bez toho se můžeme pokoušet leda o drobné změny.

MS koupil SAP?? Sem si nevšim... ;-))

Pokud je v SAPu chyba a vy odvedete špatně daň, pak je to z pohledu zákona jen váš problém a proto půjdete do tepláků vy. Pokud ale máte se SAPem standardní support smlouvu, pak vám SAP bude nucen proplatit veškerou škodu a váš pobyt ve vězení tak bude náležitě odškodněn. Alespoň v Německu je to běžná praxe. Že české firmy obvykle ani nenapadne do smlouvy klauzuli o plné odpovědnosti za škody napsat, to už je věc jiná a nelze to celé házet na SAP. V případě MS je pak bohužel smutný fakt, že na výběr nemáte.

Mne by bohate stacilo, kdyby MS opravdove dotahl bajecny projekt MS-WSYP - Microsoft We Share Your Pain. Sice je to humor, ale vydalo to MS v It's Showtime na MS TechNet. :-) video treba zde http://www.metacafe.com/watch/88657/share_the_pain/

To ne. Jestli dokáže někdo prodat kvalitní produkt, je mu přáno, aby plaval v penězích, jako Strýček Skrblík. U Gatese to byla náhoda: byl ve správnou dobu na správném místě a potkal správné lidi. Microsoft v době, kdy k nim napochodovali pánové z IBM se svým PC a chtěli po nich operační systém, existoval už několik dlouhých let. Bez valného obchodního úspěchu. Pak přišli páni z IBM a MS jim prodal něco, co koupil od někoho jiného a vydělával na klonech.
Já nejsem vůbec proti tomu software koupit. Klidně i za hromadu peněz. Ale chci, aby ten software byl kvalitně napsaný, aby v něm bylo co nejméně chyb a aby byl otestovaný tak, že při prvním náznaku složitější akce nezahučí do nenávratna a nestrhne s sebou polovinu operačního systému (který je taky tak hloupě napsaný, že se nechá strhnout).
U kancelářského softwaru chci, aby vše fungovalo tak, jak má, tedy aby funkce pracovaly tak jak je popsáno v manuálu, abych nemusel moc experimentovat a aby produkt byl rychlý a stabilní. Protože není nic víc k vzteku, když čtyři hodiny pracujete na nějaké hnusné tabulce, která obsahuje spoustu čísel z knih, výkazů a kdovíčeho ještě a pak se vám na monitoru objeví lakonické hlášení, že program vykonal chybu a musí být ukončen. Pro jistotu nefunguje ani hotbackup, takže čtyři hodiny práce jsou v prčicích. V tuto chvíli dostávám pravidelně amok a je nutno mne hlídat, abych hardware nerozbil :o)))

to není mrkvosoftí přístup, ale přístup rozumného člověka, neboť ten ví, že chyba nemusí být jen v sw, ale může vypadnout proud nebo se pokazit nějaký kus hw nebo cokoliv jiného.

Muzes i ty udelat chybu. I kdyz ty asi ne...

To co píšete o SQLServeru je absolutní blábol, doporučuji si přečíst např. http://cs.wikipedia.org/wiki/Microsoft_SQL_Server anebo v knize Mistrovství v SQL Serveru 6.5 je počátku vývoje Sybase SQL Serveru věnována celá kapitola.

Jestli jsem to pochopil správně, testovací program musí být mnohem lépe zpracován, než testovaný program. Jen tak můžeme garantovat bezchybnost testovaného programu. Ty 3 řádky denně jsou zřejmě u testovaného programu, o testovacím nebyla zmínka.

Logicky vzato: testovací program NASA byl mnohem delší a komplexnější, než testovaný.

S tim bych si dovolil polemizovat.
Napousteni se nezastavi -> pracka pretece a vytopi byt.

Zapnute topne teleso pri nenapustene vode -> prehrati topneho telesa a riziko pozaru.

Jestli jste nekdo pracovali s angloamerickyma jednotkama, tak vite, ze galon neni galon. Jinymi slovy anglicky galon je 4.6 litru, americky galon je 3.7. Ted si s tim zkuste pracovat, kdyz pocitate mnozstvi paliva pro let na Mars v Anglii a nadrz pak plni v Americe.

Tady myslim neslo o galon a galon, jako spis o to, ze NASA pouziva primarne metricky system, zatimco obcane USA (a tedy nejspis i vetsina zamestancu NASA) bezne pouzivaji hen ty "english units".

Ja jsem nekde pred nekolika lety cetl, ze jim to pocitali anglani a oni pak prevadeli v NASA americky galon na litry, misto anglickeho galonu na litry.

Ale rekl bych, ze cela tato udalost nema s IT chybama nic moc spolecneho. Spise jde o fyziku a spatne jednotky. Sice se to nejspise pocitalo na pocitaci, ale k SW chybe nedoslo.

Tahle chyba se stala v Kanadě, když tam letový provoz přecházel na metrický systém a pilot vypočítal dolet podle obsahu nádrže v galonech, ale letadlo zobrazovalo obsah v litrech.

Ve skutečnosti šlo o záměnu kg a liber, protože dopravní letadla používají především váhu, nikoliv objem.

No, bylo to o dost slozitejsi, oni ti piloti zas tak hloupi nejsou. Pripad je znam jako Gimli Glider, viz http://en.wikipedia.org/wiki/Gimli_Glider#Aftermath

Gimli Glider byl jiny pripad, tam mechanik ohnul privodni trubku paliva a ono pak unikalo za letu.

Mea culpa, byl to Gimli Glider. Popletl jsem si to ja, omlouvam se. To jsou ty rychle odpovedi o skoro o pulnoci :)

Přesně tak, NASA i Boeing používají metrický systém (zde newtony), zato Lockheed Martin zůstal u imperiálního systému (libry síly) a tím to všechno podělal.

Ta kontrola jednotek u kritických systémů v NASA byla, ale v uvedeném případě se stalo, že jiné jednotky byly použity na logovacím výstupu (který jen zapisoval data do logu). To nevadilo, bohužel se na to ale za nějaký čas zapomnělo, a logovací výstup se použil jako jeden ze vstupů modulu, který ovládal motor - a čekal, že bude mít všechny vstupy v jiné soustavě.

Takže chyba byla v tom, že se důležitý systém připojil k systému do té doby 'nedůležitému', který tím pádem nebyl tolik kontrolovaný.

No a s mílemi to je ještě horší - jen v USA mají dvě, na pevnině 1609 metrů a na moři 1853, ostatní státy měly další verze míle (http://en.wikipedia.org/wiki/Mile), naštěstí se většinou už nepoužívají. Metrická soustava je proti tomu opravdu skvělá.

Metrická soustava je opravdu skvělá, protože 1Km má přesně 1000metrů. Není to krásné kulaté číslo? :-)

Metr je stejný, protože je definován jako vzdálenost uražená světlem za jednu sekund.

No ta definice je drobatko jina a postupem casu se i menila.

Pravda, ani nevím, kde se mi tam vzala ta jednička, ale je to definované na základě sekundy (která je zase definovaná na základě přechodů v atomu cesia). Definice se měnila, ale právě z toho důvodu, aby byla všude stejná i přes vliv obecné relativity a aby se pro přesné odměření nemuselo jezdit do Francie.

A nejlepší na tom je, že prototyp metru míval přesně 1,00000nic metru. Když chtěl někdo odměřit přesně metr, musel někam do Paříže. Teď už to není pravda, metr je definován pomocí rychlosti světla a časové jednotky 1s.

A aby to nebylo tak jednoduche a byl chaos jeste vetsi, tak je jeste uzasna strojarsko-elektrotechnicka jednotka mil, coz je 2.54um :)

pdf URL?

Pokud vim, ta kniha je pod copyrightem, takze se da neda zadarmo stahnout (ale bude na P2P sitich).

Pokud autor neručí za svůj produkt nebo nesouhlasím s EULou, potom pokud si nebudu stěžovat, nemusím za tento sw platit.

No kdyz se budes hodne hadat, tak to asi casem uhadas
Vzhledem k tomu ze mame EU tak by to nakonec i soud asi uznal, ale trvalo by to dyl nez jakou ma ten program zivotnost

Program vzdycky funguje tak jak ma.

Tím dosáhneš akorát toho, že na trhu bude 'trhni si... powerpoint' za 2000 Kč, a 'všechny chyby opravíme, i ty, které má jeden člověk z milionu na specifické konfiguraci' verze za cca 50000 Kč. A budeš zase nadávat, načež EU přikáže snížit cenu, a výrobce programu se na tenhle byznys vykašle.

A nakonec nebudeš mít ani ten chybový program.

(z desetinou -> s desetinou)

Plácáš voloviny. To je jako by ti pekař řekl, že houska je komplexní - ani mouku, ani vajíčka, ani pec nedělal on, tak za to nenese zodpovědnost.
To je stejná "argumentace", jako "nikdo tě nenutí chodit do té restaurace, kde se maso válí po zemi a hodují na něm mouchy". Jednak jako spotřebitel mám právo za své peníze dostat to, co je deklarováno - tedy zdraví nezávadné jídlo (resp. funkční software), jednak to asi těžko budu kontrolovat a vymáhat jako obyčejný spotřebitel - to mám počkat, až dostanu žloutenku a pak se soudit? A jednak kolik by nakonec těch kvalitních restaurací zůstalo? Ta hygiena si holt vyžaduje nějaké náklady, stejně jako kvalita SW. Rozhodně nejde o desetinásobek, ale něco navíc to prostě je - třeba přijmout 5 kvalitních vývojářů místo 20 lemplů. To dokonce (pro někoho možná kupodivu) vyjde nakonec levněji.

Když si od tebe objednám housku a ty ji upečeš ze špatný mouky, bude mi šuma fuk, až mi budeš kecat o tom, že to je chyba té mouky. To je tvůj problém a jak si kontroluješ mouku mě nezajímá. Mně jsi dodal šmejd a za to poneseš následky ty.

P.S.: Já už se vývojem živím. A dobře. ;-)

OK, živíš sa vývojom, a dobre...

Ešte napíš, že dávaš na svoj softvér plnú záruku a spomeň názov tvojho softvéru, prípadne ak je neznámy, trošku naznač jeho funkčnosť a na čo všetko sa tá záruka vzťahuje ;-)

Je to zákaznický soft. Jedná se o průmyslovou aplikaci. Spoluúčast na likvidaci škod by se určila ad hoc u soudu podle těch škod a povahy chyby, která to způsobila. Místo obvyklého "PROVIDED AS-IS" mám ve smlouvě pravý opak - závazek nést zodpovědnost za škody způsobené nefunkčností mého produktu. Připadá mi absurdní, že se mnou jakožto s fyzickou osobou se uzavírá takováto smlouva, zatímco velké firmy odmítají nést zodpovědnost za svůj výtvor. Kdyby podobnou povinnost měly i tyto velké firmy, pravděpodobně by musely vyházet většinu svých programátorů a konečně začít důkladně zkoumat kvality místo toho, aby honem, honem něco zmatlaly dohromady dřív než konkurence a udělaly vše pro to, aby těch milion a jeden nedostatek utajily. Už by nestačilo "umět" C# nebo Javu - už by museli dotyční i něco doopravdy umět a opravdu rozumět své práci. Cena některých programátorů na trhu práce by vzrostla, většina současných programátorů by se naopak stala bezcennými a museli by se zabývat nějakou hůře placenou prací.

Tak to ti držím palce až skončíš pod mostem, protože se projevila chyba v jedné s desítek knihoven (nebo OS modulů/ovladačů), na které funkčnost tvého softu závisí. Já bych za fyzickou osobu takovou smlouvu nepodepsal ani na program běžící na mnou navrženém a vyrobeném počítači s mnou napsaným OS - protože vím že ani tak nejsem neomylný.

Good luck.

Neomylný není nikdo. Ani lékař, který se ti bude hrabat v hlavě když se ti něco stane, ani automechanik, který ti bude vyměňovat brzdy, ani elektrikář, který ti bude připojovat bojler.
Nést zodpovědnost neznamená býti neomylným. Povinnost nést zodpovědnost za svou práci je mechanismem jak eliminovat diletanty. Je to mechanismus, který prakticky realizuje úsloví, že za chyby se platí. Pokud někdo něco dělá s vědomím, že za své chyby bude platit, přistupuje k tomu přeci jen trochu jinak než když ví, že toto mu nehrozí.
Proč bych to měl být já, kdo skončí pod mostem? Proč bys to neměl být ty? Umíš programovat jen tak, že o funkčnosti svých výtvorů pochybuješ i ty sám? Tak proč by tě to mělo živit? Znamená to, že na svou práci odborně ani morálně nestačíš a měl by ses spokojit s méně zodpovědnou a nejspíš i hůře placenou prací. Podobně jako elektrikář, automechanik aj., kteří by nebyli ochotni nést zodpovědnost za svou práci. Opravdu nevidím jediný důvod, proč by programátoři měli být výjimkou.

Utíkat před zodpovědností za svou práci je jen prachsprostou zbabělostí.

Plky. Model situace je prostý.

Pán A udělá za 3 měsíce bezchybný sw podle původní dohody s panem B a ten ho přijme.
Za týden si pán B vzpomene na dva měsíce starou záležitost, kdy po probuzení říkal nanynce C: "Chci mít v tom sw super funkci. Předej to panu A.".
Nanynka C na to zapomene. Pán B také umí mít špatnou paměť. Když chce.

Ber nebo nech být. To je realita.

Mnoho virů by naopak mohlo být vzorem kratších ale bezchybných kódů.

To bych netvrdil, takové viry jsou naprosto výjimečné a v naprosté většině případů jde o viry experimentální. Když zkusíte nějaký běžný virus dekompilovat, celkem snadno zjistíte, proč autor píše viry místo toho, aby dělal v nějaké softwarové společnosti.

To záleží...
Ano, dříve když autoři viry vytvářeli jen pro slávu neměli možnost viry otestovat a proto obsahovaly chyby.... Ale teď, když je mnoho virů vytvářeno placenými profesionály, kteří mají rozsáhlé možnosti testování, už viry obsahují mnohem méně chyb....

ÚV KSČ (ustredni vybor komunisticke strany Ciny :-)
vydal prohlášení:
Problem Y2K nehrozi
a nemusely se investovat miliardy dolaru

1.1. 2010 zneskodnil sikovny francuzky programator desattisice nemeckych debetnych a kreditnych kariet. Moja bola medzi nimi. Hovori sa tomu "late millenium bug". Pravdepodobne chcel vyriesit problem Y2K, ale dosiahol len jeho posunutie o 10 rokov.

http://uk.creditcards.com/credit-card-news/german-millennium-bug-credit-debit-cards-1360.php

precital som az dokonca :) a to sa casto nestava

Firma by nemela zabit vic nez 25% casu hledanim chyb a jejich opravami. Navic 25% je jiz horni hranice. Jestli v nejake firme je vetsi procento oprav chyb, tak to firma dela od zakaldu spatne a je to znamka toho, ze by mela vymenit project leadera nebo sw architekta.

Nas team nepresahuje 20% casu na chybach. Delame komercni IS. Jiz kdyby mel programator stravit vic nez polovinu produktivniho casu na oprave chyb byl by z toho otraven a prace by ho nebavila a ne to, ze by mel stravit resenim chyb vetsinu casu.