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

[Carsten Posingies]

Oliver Bandel <oliver at first.in-berlin.de> schrieb:

>> 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.

Ich spreche mal bewusst nur von meiner speziellen Branche, nämlich
Personalmanagement-Software, Schwerpunkt "Lohn und Gehalt". Jedem, der ab
und zu Zeitung liest, dürfte in etwa klar sein, dass Änderungen und
Ergänzungen im Code eines solchen Programms nicht so sehr von Userwünschen
herrühren, sondern von der Gesetzerlasseritis und Anordnungsfreudigkeit
deutscher Parlamente, Ministerien und Behörden. Und wenn nunmal ein § in
einem Monat inkraft tritt, muss unsere Software diese eben mit dem Update
kurz vor dem Beginn jenes Monats, besser sogar noch etwas früher (damit die
User die Neuerungen ausprobieren können) parat haben. Das können
Kleinigkeiten sein, aber auch Dinge, die sich durch das ganze L&G-Modul
ziehen wie zum Beispiel die laufenden Änderungen der §§ bzgl. der
geringfügig Beschäftigten (ehem. "630-Marks-Kräfte") oder flexible
Arbeitszeit samt Arbeitszeitkonten. Da stemmen dann 3 10-jährig erfahrene
Programmierer gemeinsam Monate dran. Und zwar nicht, weil wir zu blöd wären,
sauberen und funktionierenden Code zu schreiben, sondern weil einfach die
Anforderungen so komplex 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.

Weil sie sich vielleicht erstmal fachlichen Input besorgen mussten und
diesen Input auch noch zu verstehen haben, bevor sie ihn in einen
Algorithmus umsetzen können. Wenn ich 5 Jahre Grafikkartentreiber
programmiere, weiß ich irgendwann Bescheid. Aber wenn ich neben
Programmierung auch noch die Kenntnisse eines Arbeitsrechtlers, eines
Personalchefs und einer Buchhaltungskoryphäe haben muss, sieht die Sache
anders aus.

In manchen Fachbereichen ist das Programmieren eben nur eine
"Nebentätigkeit", die Hauptbeschäftigung ist Lernen des Fachgebiets.

> 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?!".

Es mag ja durchaus sein, dass frische Informatik-Absolventen alle 34 nötigen
Testfälle finden, um eine Routine zu prüfen, die 2 Zahlen malnimmt... Aber
eine durchschnittliche Softwarebude, deren Geschäftsführer nicht beide
Lottomillionäre sind, kann es sich einfach nicht leisten, für 10 Zeilen Code
4 Tage fürs Testen aufzuwenden.

Im Übrigen widersprichst Du Dir ja laufend selbst in Deinem Posting, wenn Du
zum einen sagst, man müsse eben sauber programmieren, zum anderen aber
intensives Testen forderst. Natürlich mindert sauberer Code laufendes
Umschreiben, weil die Tests alle "ok" ausgeben. Aber die Tests müssten
unabhängig von der Codegüte durchgeführt werden - und im Übrigen auch
entwickelt und selbst getestet. Sonst taugen die besten Tests nicht.

Nebenbei gibt es im Bereich Lohn & Gehalt jährlich einen Programmtest mit
zwei großen Aktenordnern voll Testfälle. Alleine diese abzuarbeiten, um
überhaupt eine Zulassung zu erhalten (den Segen der gesetzlichen
Krankenkassen, damit diese überhaupt mal eine Diskette mit Zahlen dieser
Software akzeptieren), dauert etwa 2 Wochen und dann noch 1 Woche für den
eigentlichen Test durch die Kassen.

Und gleich nochwas dazu: Diese Tests werden von Leuten entworfen, die die
Top-Ahnung vom Fach haben, aber keinerlei Peilung von Usability und
Anwender-Wünschen. D.h., dass aus dem Programm für den Test ganz viele
Kundenwünsche ausgeblendet und nach dem Test wieder eingeblendet werden
müssen. Wieder ein paar Tage Arbeit, weil es da (glaubs oder nicht) nicht
mit einem #ifdef test getan ist.

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

Möglich, aber wenn Du Dir mal was ganz anderes anschaust, nämlich die
Gehaltsentwicklung in diesem Segment, kann ich den einen oder anderen Coder,
der zum dritten Mal mit "Tja, wir können Ihnen nicht mehr als bisher zahlen,
aber Sie können sich natürlich jederzeit eine neue Stelle suchen" erpresst
wird, durchaus verstehen. Und das ist (glaubs oder nicht) nicht wirklich die
seltene Ausnahme. Vor allem nicht bei Berufseinsteigern, die nur davon
träumen können, in 15 Jahren das zu verdienen, was ihre Kollegen, die früher
angefangen haben, schon nach 5 bekommen.

> Tut mir leid, aber das ist leider Bullshit.

Tut mir leid, aber ich empfinde DEINE Sicht als nunja... rosarot und sehr
theoretisch.

> Und der ist in der Arbeitswelt weit verbreitet.

Wie gesagt, ich glaube da nicht dran, dass das so weit verbreitet ist.
Natürlich gibts diese Einstellung bei manchen Programmierern, aber Deine
verbale Keule klingt mir arg nach den Klischees, die sonst nur den ach so
verluderten Handwerkern nachgesagt werden.

> 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.

Hast Du schonmal Code geschrieben, der so komplex war, dass Du nach einem
Urlaub Deine eigenen Ablaufdiagramme nicht mehr verstanden hast? Nein? Dann
bist Du entweder ein Genie oder hast eben doch nur Grafikkartentreiber
geschrieben. Sorry, wenn ich jetzt polemisch werde, aber Dein "das ist doch
alles Scheiße, die Coder sind faule Schweine" macht mich irgendwie
aggressiv.

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

In Grafikkartentreibern vielleicht. In Betriebssystemen eher nicht. In
Anwendungen, die zu 80% aus Fachwissen bestehen, das selbst hochkomplex ist,
noch weniger.

> 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.

Mag sein. ICH hingegen habe in der Praxis sehen können, dass just die
Anwender, die unsere Hotline deswegen anrufen, weil sie nichtmal eine Datei
per Maus verschieben können (glaubs oder nicht: davon gibts reichlich viele,
weil ihre Arbeitgeber nicht willens oder nicht in der finanziellen Lage
sind, Kurse zu bezahlen), bei anderen Problemen mit irgendwelchen Tools, die
ihnen Kollegen oder der nette EDV-Onkel aus dem 2. Stock gegeben haben,
knietief durch die Datenbanken hinter dem Programm schlendern und dann
"natürlich nichts machen", sprich: übelsten Schaden anrichten. Natürlich ist
die Software so geschrieben, dass die entsprechenden Rechte sowas EIGENTLICH
nicht erlauben, aber dann greift eben doch wieder der nette EDV-Onkel ein
und erlaubt mal eben alles für jeden (auch schon in großen Firmen gesehen),
damit er Ruhe hat. Und das alles, weil die Sachbearbeiter unter Zeitdruck
stehen oder eigentlich hilflos vor den PCs sitzen und dann im Affekt
irgendwo draufhauen, wo sie meinen, es hätte grad gezuckt.

>> 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.

Generisches Programmieren findet spätestens im Paragraphendickicht des
deutschen Gesetzgebers sein jähes Ende. 80% unseres Codes ist (wie üblich)
für 20% der möglichen Fälle der Art "§ 5 Abs. 3, Satz 1, 2. Halbsatz in der
geänderten Fassung vom 4.5.2002 lt. BGBl. xyz" geschrieben. Die nötigen
Bibliotheken für die Programmteile, die nicht fachlich sind, sind so
generisch, dass wir sie teilweise als Entwicklungsbibliotheken für andere
Programmierbuden verkaufen.

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

Ich rede nicht von Marketing, sondern von meiner täglichen
Arbeitswirklichkeit...

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

Der Entwicklungsaufwand ist hoch, weil... s.o. der fachliche Teil 80%
ausmacht, und den lernt man weder aus Büchern noch an Universitäten, sondern
fast ausschließlich durch Reden mit dem Kunden.

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

Genau das bezweifele ich weiterhin.

> 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.

Erklär mal dem Prokuristen eines Kunden, warum er für die neue Version einer
Software neue PCs anschaffen muss, weil die alten Maschinen die Leistung
nicht mehr haben, um alle nötigen Validierungen und Prüfläufe in einer
erträglichen Zeit zu absolvieren...

> Wer vorher mal schaut, wie man sowas vermeiden kann,
> wird zumindest die meisten Probleme aus der Welt schaffen.

... wenn er nicht gerade mal wieder auf einem Lehrgang der Krankenkassen
sitzt und versucht, die neuesten gesetzlichen Änderungen zu verstehen. Ich
komme auf eine meiner Ausgangsthesen zurück: man müsste die Manpower
erhöhen, um dem einzelnen Programmierer mehr Zeit zu verschaffen, sich
ausgiebig mit seinem Code beschäftigen zu können. Ergo wird das Produkt
teurer.

> 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!

Die Faustregel sagt "30% entwickeln, 70% testen". Da fehlen dann nur noch
die o.g. 80% fachliche Qualifikation.

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

Das ist unbestritten. Mancher ADAC-"Engel" macht Deine Schrottkarre durch
bloßes Handauflegen wieder fit, andere Kfz-Meisterbetriebe schrauben daran
eine Woche und kommen nicht weiter. Das ist Talent und Wissen und Erfahrung.
Aber wirkliche Top-Programmierer kosten nunmal ein Schweinegeld und damit
s.o., und außerdem haben sie immer noch nicht das fachliche Know-How, das
sie brauchen, um auch nur 100 Zeilen Code zu schreiben.

>> 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. :)

Ich verwette meinen Arsch darauf, dass von BSD nur deswegen so wenige dicke
Klopse bekannt sind, weil es im Vergleich zu Windows und mittlerweile Linux
so wenig verbreitet ist.

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

RedHat veröffentlicht die Errata meiner Meinung nach auch nicht unbedingt
von sich aus, sondern weil der Bug auf irgendeiner wichtigen Mailingliste
aufgetaucht ist.

>> 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.

Ach ja? Ich dachte, man muss Code ausgiebig testen, bevor man ihn freigibt?
*staun* Im Übrigen rede ich gar nicht mal von den neuesten Features, die
offiziell noch beta sind, sondern von Teilen, an denen offenbar jeder
zwischen zwei Kernel-Releases mal rumschrauben darf, z.B. "iptables".

> 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.

Ich glaube kaum, dass Administratoren so denken. Es liegt eher daran, dass
die Damen und Herren Verkäufer beim Kunden große Ohren kriegen, wenn jener
sagt: "Ich hab irgendwo gelesen, dass die neueste Version von Foo jetzt auch
Bar kann! Das brauchen wir UNBEDINGT, machen Sie uns ein Angebot!"

Carsten