About: Software, Gute Bugs und Schlechte Bugs 

Keine software ohne Bugs, doch wie unterscheidet man gute Bugs von schlechten Bugs - und gute Software von schlechter Software? Nate Graham hat diese Frage beiläufig im Rahmen seiner neuesten Ausgabe von This Week in KDE beantwortet.

Occasionally people ask, “Jeez, it feels like you guys are fixing bugs all the time… shouldn’t they all be fixed by now? Why is your software so buggy?” Thing is, that’s the nature of software. There are always more bugs to fix, no matter how long you work at it. And the more people who use it, the more bugs they’ll find. This is universal, for every piece of software. The best metric is not really “number of bugs fixed,” but rather “egregiousness of bugs fixed.” You want to see that the bugs we fix get weirder and more esoteric over time, which indicates that the basics are becoming more reliable. We’re not all the way there yet, but I believe we are making progress!

Zu deutsch:

Gelegentlich fragen die Leute: "Mensch, es kommt mir so vor, als würdet ihr die ganze Zeit Fehler beheben... sollten die nicht schon längst alle behoben sein? Warum ist eure Software so fehlerhaft?" Die Sache ist, das ist die Natur von Software. Es gibt immer mehr Fehler zu beheben, egal wie lange man daran arbeitet. Und je mehr Leute die Software benutzen, desto mehr Fehler werden sie finden. Das gilt für jedes Stück Software. Die beste Kennzahl ist nicht die "Anzahl der behobenen Fehler", sondern vielmehr die "Ungeheuerlichkeit der behobenen Fehler". Sie sollten sehen, dass die von uns behobenen Fehler mit der Zeit immer seltsamer und esoterischer werden, was darauf hindeutet, dass die Grundlagen immer zuverlässiger werden. Wir sind noch nicht ganz am Ziel, aber ich glaube, wir machen Fortschritte.

Also, gemäß Nate Graham ist die beste Kennzahl nicht die Anzahl der behobenen Fehler, sondern die Ungeheuerlichkeit der behobenen Fehler. In anderen Worten: je seltsamer und esoterischer die behobenen Fehler, desto zuverlässiger die Grundlagen, desto besser die Software.
Im Gegenteil gilt: Je einfacher und offensichtlicher die behobenen Fehler - je ungeheuerlicher sozusagen, desto unzuverlässiger die Grundlagen, desto schlechter die Software.