'Bètaversies Windows Vista en IE7 tellen 20.000 bugs'

Ligt aan je testmethodes. Met de scripts waar ik werk worden alle bugs meteen gedetecteerd en kan ik wel nieuwe fouten maken, maar niet zonder dat ik deze meteen te zien krijg en er voor kan zorgen dat deze meteen opgelost worden.

Ok, complexiteit is een factor voor hoeveel nieuwe fouten je creeert.

Ja, idd. Als je naar een stel van deze bugs kijkt, wat ik net een poosje heb gedaan, valt het al vrij snel op dat het bij de ernstigere bugs zaken betreft die 'aan het begin van een bepaalde keten' staan (nou ja, anders zouden het ook geen ernstige bugs zijn ).
Bij bugzilla (Linux) worden dit de critical bugs genoemd (die het OS crashen). Als deze zijn opgelost, gaan vaak hele stukken software werken, die eerder nog niet werkten, omdat een systeemcrash dat bijvoorbeeld verhinderde. Die stukken software zijn dan nog niet zo goed getest, en bevatten mogelijk weer een hoop minor-bugs. Het wil echter andersom ook wel eens gebeuren dat bij het squashen van een minor bug juist weer een critical bug ontstaat. Vooral als degene die de bug wil fixen nog een kater en veel haast heeft, en niet gemotiveerd is omdat hij toch wel betaald wordt, en daarom een 'dirty hack' toepast (waar Linux bijvoorbeeld van aan elkaar hangt, hoewel de mensen daar wel gemotiveerd zijn omdat het vrijwilligers zijn).

Om een paar voorbeelden van critical bugs te geven:
-BSOD on boot from DVD. (Jaja, terug van weggeweest!)
-Installation of OpenVPN 2.0 crashes system with BSOD
-USB compositeDriver failed to load
-IE7 on XPSP2 GUI ERROR

(In totaal 40x BSOD, en dat zijn alleen nog de publiekelijke, want BSOD's gaven vroeger vaak ideale informatie als geheugenadressen etc. voor virusmakers)

Maar persoonlijk vind ik 20.000 bugs erg netjes. De Gentoo(Linux) distro bijvoobeeld, die gewoon als 'stabiel' gezien wordt, heeft er ~8000 openstaan (alleen een stuk minder critical en blockers neem ik aan).

Als je een bug oplost dan kunnen er best weer twee bugs bij komen.

1) als je de bug oplost dan komt deze functie wel weer verder. daar loopt hij wel weer tegen een nieuwe bug aan.
2) jouw patchcode bevat een nieuwe bug!

Een bugvrij leven is altijd net zo dichtbij als wereldvrede. Altijd naar blijven streven maar ik zou er niet op gaan wachten.

Dat is voor een groot gedeelte op te lossen met regression testing: na een verandering alle tests opnieuw draaien, ook die van functies die er helemaal niets mee te maken lijken te hebben. Indien je fix een nadelige invloed heeft op een ander bestaand stuk code, gaan de alarmbellen direct rinkelen bij een andere test die in het verleden gemaakt is. Voorwaarde voor deze methode is dus dat je al test tijdens de ontwikkeling, en niet na afloop eens gaat kijken wat er getest zou kunnen worden (want dan ga je geheid een hoop cases vergeten).

Natuurlijk is ook dit niet de ultieme oplossing voor een 100% bugvrij programma (want zoals je zei bestaan die niet), maar dat is omdat het vaak erg lastig is testcases te maken die de functionaliteit van een procedure volledig dekken. Er zijn wel methoden voor om dat zo goed mogelijk te doen, maar dat is een verhaal apart Was een vrij interessant college op mijn universiteit

Die wikipedia definitie is nauwer dan dat jij zelf zegt. Als ik programmeer vind ik zelf dat een bug de wikipedia-definitie heeft, maar als de opdrachtgever (even kort door de bocht) weigert te betalen, omdat een knop een rare melding geeft, dan volg ik jouw definitie.