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

[Schlomo Schapiro]

Hello Carsten,

ich kann jedem Wort nur beistimmen. Meine Firma macht Software für
Bankenautomation (z.B. Geldautomaten) und der Aufwand, der in
Sonder- und Nebenlösungen steckt ist riesig, der Code selber recht einfach.

Und der Preis- und Termindruck verhindert ein normales oder vernünftiges
oder gar gründliches Arbeiten komplett !

Schlomo

PS: Ist IMHO nicht so ganz OT, wir sind ja alle auch irgendwo tätig und
beten nicht nur Linux an...

Thursday, February 20, 2003, 11:27:53 PM, you wrote:

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

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

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

CP> In manchen Fachbereichen ist das Programmieren eben nur eine
CP> "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?!".

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

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

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

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

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

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

>> Tut mir leid, aber das ist leider Bullshit.

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

>> Und der ist in der Arbeitswelt weit verbreitet.

CP> Wie gesagt, ich glaube da nicht dran, dass das so weit verbreitet ist.
CP> Natürlich gibts diese Einstellung bei manchen Programmierern, aber Deine
CP> verbale Keule klingt mir arg nach den Klischees, die sonst nur den ach so
CP> 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.

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

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

CP> In Grafikkartentreibern vielleicht. In Betriebssystemen eher nicht. In
CP> Anwendungen, die zu 80% aus Fachwissen bestehen, das selbst hochkomplex ist,
CP> 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.

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

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

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

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

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

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

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

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

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

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

CP> Die Faustregel sagt "30% entwickeln, 70% testen". Da fehlen dann nur noch
CP> 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?!

CP> Das ist unbestritten. Mancher ADAC-"Engel" macht Deine Schrottkarre durch
CP> bloßes Handauflegen wieder fit, andere Kfz-Meisterbetriebe schrauben daran
CP> eine Woche und kommen nicht weiter. Das ist Talent und Wissen und Erfahrung.
CP> Aber wirkliche Top-Programmierer kosten nunmal ein Schweinegeld und damit
CP> s.o., und außerdem haben sie immer noch nicht das fachliche Know-How, das
CP> 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. :)

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

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

CP> RedHat veröffentlicht die Errata meiner Meinung nach auch nicht unbedingt
CP> von sich aus, sondern weil der Bug auf irgendeiner wichtigen Mailingliste
CP> 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.

CP> Ach ja? Ich dachte, man muss Code ausgiebig testen, bevor man ihn freigibt?
CP> *staun* Im Übrigen rede ich gar nicht mal von den neuesten Features, die
CP> offiziell noch beta sind, sondern von Teilen, an denen offenbar jeder
CP> 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.

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

CP> Carsten

CP> _______________________________________________
CP> linux-l mailing list
CP> linux-l at mlists.in-berlin.de
CP> https://mlists.in-berlin.de/mailman/listinfo/linux-l


-- 
Best regards,
 Schlomo