[linux-l] Microsoft B.G. about bugs

Oliver Bandel oliver at first.in-berlin.de
Do Feb 20 21:41:12 CET 2003


On Thu, Feb 20, 2003 at 07:18:47PM +0100, Carsten Posingies wrote:
[...]
> Im Übrigen würde ich Gates insofern durchaus zustimmen, dass sehr viele
> Fehlfunktionen (nicht alle, aber doch viele) in der Tat durch unfähige oder
> zu experimentierfreudige User verursacht werden.

Da möchte ich mal ganz drastisch widersprechen!

Es sind nicht die User, die zu experimentierfreudig sind,
sondern die Programmierer, die zu wenig experimentierfreudig
sind.

Da ich selbst als Programmierer gearbeitet habe, habe ich gesehen,
wie scheisse viele leute programmieren, und wie wenig oder unlustig
sie ihren Code testen.

Klar, Fehler passieren jedem mal. Dann muß man eben debuggen
oder neu schreiben. Aber die meisten probleme entstehen
durch laxes Programmieren, nach dem Motto "ja, ja, so ungefähr
geht das", oder "was kümmert mich detailliertes testen, wenn
ich nach zwei drei versuchen keine fehler feststelle?!".

Das sind leider übelste Faulheiten und eine beschissene
Arbeitseinstellung, die die meisten Programmierer haben.

Vielleicht verlassen die sich auch darauf, daß es da ja
noch die Tester gibt, und die werden die Fehler schon
finden.

Tut mir leid, aber das ist leider Bullshit.

Und der ist in der Arbeitswelt weit verbreitet.

Und manchen Leuten macht das Debuggen sogar mehr Spaß,
als sauberen Code zu schreiben. Das Debugging als
Adventure-Ghame anzusehen, statt mal vorher beim
progranmmieren solide voraus zu schauen, nun,
das iste eben leider sehr verbreitet.

Ich schätze mal, 85 bis 95 % aller Bugs sind aufgrund
von nachlässigem Arbeitsstil entstanden.

Und mit solidem Arbeitsstil könnte man die Projektlaufzeiten
auf 1/5 bis 1/10 drücken.

Und das ist, was ich in der Praxis mit eigenen Augen hatte sehen
können.



> Nun könnte man
> argumentieren, dass eine "gute" Software sowas abfangen muss, aber dann
> würde sie wegen des Entwicklungsaufwandes so teuer, dass sie keiner mehr
> kaufen würde.


Bullshit!

Das dauert deswegen so lange und ist deswegen so teuer, weil
die meisten programmierer ihr Zeugs zusammen rotzen und nicht
mal etwas voraus planen. Weil sie keinen Code schreiben,
der die Probleme etwas abstrakter handhabt und deshalb
generisch ausgelegt ist.

Einwegcode halt, selbst wenn da ganz groß "Code Reuse" drauf
steht /und man sich damit gut verkauft), muß das noch lange
nicht drin sein.

Der Entwicklungsaufwand ist hoch, weil die Leute ihren
Code hinrotzen, statt sorgfältig zu schauen, was sie da machen.

Kenne ich alles aus der Arbeitspraxis.
Nicht alle Programmierer sind so, aber die meisten.

Leider ist das bei den GPL-Programmierern nicht viel besser.

Wenn andauernd irgendwelche Buffer-Overflows in Software
auftreten, dann sind davon 95% selbst verschuldet, weil
der Code Funktionen nutzt, die solche Fehler geradezu anziehen.
Wer vorher mal schaut, wie man sowas vermeiden kann,
wird zumindest die meisten Probleme aus der Welt schaffen.

Man kann dann zwar trotzdem nicht davon ausgehen,
daß der Code fehlerfrei ist; aber erstmal hat man
schon viele Probleme vorab ausgeblendet; und dann
kann man gefälligfst mal seinen eigenen Code
kritisch durchleuchten und mal ne Testreihe durchführen.

Und das macht man am besten, wenn man eine Software auch
so testet, wie sie nbicht benutzt werden soll. Das muß
die schliesslich abfangen können!


Alles andere ist Ausrede. Oder wie erklärt es sich, daß
Code-Qualität sehr stark davon abhängt, wer den Code
geschrieben hat?!



> 
> Um zum Thema der Liste zu kommen, gibt es ernstzunehmende (d.h. frei vom
> Ruch der MS-Nähe seiende) Untersuchungen, die zum Ergebnis kommen, dass
> Linux viel löchriger als MS-Windows ist -

Tja, vielleicht doch mal BSD installieren. :)


> und wenn ich mir die Zahl der
> "Errate" anschaue, die das RHN wöchentlich in meine Mailbox kippt, bin ich
> nicht weit weg davon, das zu glauben.

Ja, mit dem von Dir selbst genannten Unterschied, daß
Firmen eben ihre Bugmeldungen nicht gerne veröffentlichen.



> Will man als Linux-Nutzer bestimmte
> Features haben (vor allem Kernel-Features, neue Treiber usw.), ist man
> automatisch Beta-Tester -

Will man zuverlässigen Code haben, muß man halt eben nicht
immer jedes Kernel-feature als erster testen.
Ist doch wohl klar, daß es immer ein Weilchen dauert,
bis Code solide ist.

Wer in Umgebungen, wo es auf Zuverlässigkeit ankommt,
immer jedes neueste Feature einsetzen will, der
braucht sich nicht wundern, wenn's kracht.

Auch da gilt: Ein bischen aufpassen, bevor man was installiert,
statt sich in einer Produktionsumgebung mit
"ah, geil, ey, neuester kernel, gerade jesaugt
und noch etwas hier und da gepatcht und installiert" 
als super-cooler Held hinzustellen.... und wenn#s dann kracht
kalte Füße zu kriegen.

Solche "ach so coolen Helden" habe ich auch schon in
Firmen gefunden. Statt bestimmte Sachen halt erst mal
im Userspace zu handhaben, musste es immer das neueste
(experimentelle, zwei Tage alte) Kernel-Feature sein
- vielleicht, weil man sich dann mit den Fehlern der
Kernel-Hacker raus reden kann, statt für die eigenen
Bugs der hingerotzten Software gerade zu stehen!



Ciao,
    Oliver




Mehr Informationen über die Mailingliste linux-l