Shipping buggy code: The most critical skill for a programme

[lillahuset]

Vi tar väl en till som passerade idag. Det ligger mycket i vad hen skriver.
http://codingismycraft.com/index.php/20 ... programmer

Edit:

Even the most extensive testing suite, represents an extremely limited subset of all the possible paths that any application is expected to have thus it is simply impossible to believe that in any way we can “prove” it error free with a guaranteed behavior complying to a specific set of rules!

Given the fact that the verification process is asymmetrical to its falsification, induction cannot “prove” anything; although a billion successful tests cannot prove the validity of an application, a single fail is enough to designate it as invalid! The problem lies in how to discover the failing conditions of course and nobody can be sure that they do not exist since it is impossible to test all the possible combinations of variables and execution paths.

[HUGGBÄVERN]

Hen?! Han heter John och John är ett mansnamn, alltså vore det korrekt att skriva HAN, med A.

[lillahuset]

[Glenn]

Fast microsoft har ju garanterat buggfri programvara har vi ju lärt oss innan (av en person på EF), det beror på att deras utvecklare och testare får betalt, det gör att dom blir ofelbara.

Sen är det väl ett större problem idag att man medvetet skeppar buggig ofärdig programvara då marknadsavdelningen har mer att säga till om än utvecklingsavdelningen.

[Gimbal]

Gammal anekdot från jobbet:
En servicetekniker åker till kunden med senaste versionen av mjukvaran till maskinen. Kunden är nöjd, äntligen är alla buggar fixade.

Alla? säger serviceteknikern, det finns säker 20 buggar till som vi inte upptäckt än.

Det skulle han inte ha sagt.
Det gick ända upp till högsta ledningen som i panik hörde av sig till företaget och krävde att de 20 buggarna omedelbart skulle fixas.

[Glenn]

gimbal: Man tänker onekligen på den gamla hassan-sketchen "10000 tyska bögar"

[sodjan]

Många programvaror kommer med en list med "known bugs"
och med eventuella kända "work-arounds". Speciellt om det
gäller viktiga/kritiska programvaror. Det finns nästan alltid
något som inte fungerar optimalt...

[jpalsson]

Fast microsoft har ju garanterat buggfri programvara har vi ju lärt oss innan (av en person på EF), det beror på att deras utvecklare och testare får betalt, det gör att dom blir ofelbara.

Sen är det väl ett större problem idag att man medvetet skeppar buggig ofärdig programvara då marknadsavdelningen har mer att säga till om än utvecklingsavdelningen.

Så har det väl alltid varit, men i och med att det blivit så enkelt att skeppa uppdateringar via internet så chansar man mycket mer.
Spelbranschen håller ju på att dra det där till absurdum, det är ju i vissa lägen närmast alfakopior som skeppas, och man förväntas
dra ner 10-tals gigabyte uppdateringar i flera steg för att allt ska funka.

Det tråkiga är ju att det här har spridit sig även till de som kör embedded, istället för att testa riktigt så skeppar man ofärdig kod och låter
kunderna vara testare.
Exempelvis Ikeas smarta lampor verkar (vad jag förstått på forum) vara en sån produkt.

[hummel]

För i alla fall inbyggda system inom rimlig storlek går det att skriva program på ett sådant sätt att man garanterat testar varje rad (100%) kod i programmet.

[lillahuset]

Ja det är ju en vacker tanke och ett bra mål men knappast realistiskt.

Det är väldigt mycket som ska vara felfritt för att slutresultatet ska bli felfritt.
Jag har aldrig haft en kund som har kunnat leverera en korrekt och fullständig specifikation av vad de vill ha.
Jag har aldrig sett en testmiljö som inte har utvecklats med tiden pga att det hittades fel i den.
Jag har aldrig sett tredjeparts programvara som på ett någorlunda trovärdigt sätt har garanterats vara buggfri.
Jag har vid flera tillfällen sett program gå sönder för att utvecklarna har uppgraderat verktyg eller bibliotek. Företrädesvis strax innan deadline.

Inse att vi människor är klåpare, i varierande grad, och kommer troligen att förbli det. Ibland har vi tur och det blir riktigt bra.

[TomasL]

För i alla fall inbyggda system inom rimlig storlek går det att skriva program på ett sådant sätt att man garanterat testar varje rad (100%) kod i programmet.

Jo, om koden inskränker sig till något hundratal rader typ.

[HUGGBÄVERN]

Och i ett fåfängt försök att återknyta till texten, så även om en kod är felfri kan ju programmeraren ändå ha missat att pröva sin kod mot alla möjliga scenarier och situationer som "omöjligt kan inträffa".

[Lennart Aspenryd]

Eftersom, som lillahuset så riktigt påpekar, kunden aldrig lämnar en fullt klar specifikation, är vägen kantat av kast och genvägar.
Vi måste alltså bli bättre på att kommunicera syfte och resurser innan man gör ett program!
Men visst är det ett otyg att man inte går hand i hand med beskrivning av en produkt och dess funktion.

[adent]

För i alla fall inbyggda system inom rimlig storlek går det att skriva program på ett sådant sätt att man garanterat testar varje rad (100%) kod i programmet.

Jo, om koden inskränker sig till något hundratal rader typ.

Sen infinner sig genast interrupt som kan inträffa lite när som helst och ställa till saker i väldigt specifika fall om man gjort fel...
Nästan omöjligt att hitta sådana fel genom testning.

[swesysmgr]

Och i ett fåfängt försök att återknyta till texten, så även om en kod är felfri kan ju programmeraren ändå ha missat att pröva sin kod mot alla möjliga scenarier och situationer som "omöjligt kan inträffa".

Det går åtminstone ibland att använda formella metoder och verifiering för att bevisa att systemet inte kan göra fel förutsatt att systemet exakt implementerar modellen. Att göra rätt från början så att säga, motsatt idé mot testning i efterhand.

Vågen av unit test verktyg och liknande tycker jag har ökat slarvandet tyvärr, det blir bekvämare för vissa att inte orka tänka medans man kodar utan hafsa ihop något och hoppas att testningen fångar ev. fel.