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

[Carsten Posingies]

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

> Na gut, das sieht aber eher danach aus, daß man bei Euch
> den Programmierern im Entwicklerteam noch einen Juristen
> zur Seite stellen sollte.

Den haben wir. Und zwei externe Kräfte auf Abruf, die absolute Experten in
Sachen Personal und L&G sind.

> Dann müsst ihr Euch, wenn's zu unübersichtlich wird, eben
> auch noch einen Arbeitsrechtler oder sonstigen Spezialisten
> dazu gesellen.

Siehe oben.

>> In manchen Fachbereichen ist das Programmieren eben nur eine
>> "Nebentätigkeit", die Hauptbeschäftigung ist Lernen des Fachgebiets.
>
> Nun gut, ich habe mir immer Programmiertätigkeiten ausgesucht,
> wo ich das fachliche ganz gut verstanden hatte bzw. eine
> Einarbeitung machbar war.

Tja, wer sich das aussuchen kann, hat's gut. Der Markt ist aber für
durchschnittlich begabte Programmierer wie mich nicht soooo üppig derzeit.
Freundlicherweise hat mein Brötchengeber mir so einige Freiheiten
eingeräumt, u.a. mich vor allem um die nicht-fachlichen Features zu kümmern,
Ideengeber zu sein, Code-Reuse zu intensivieren, Programmteile generischer
zu gestalten, Kommentar- und Code-Formatierungs-Vorgaben zu machen usw.
Daneben bin ich allerdings z.B. die arme Sau, die Daten-Export- und leider
auch -Import-Kram schreiben muss. Und falls Du sowas schonmal gemacht hast,
weißt Du ja, was für ein hocherotischer Job es ist, Prüfroutinen gegen die
fehlerhaften Datensätze anderer Programme zu schreiben...

> Auf juristischem Gebiete würde ich mich nicht betätigen.
> Würde ich es wollen, müsste ich mir natürlich das Know-How
> dazu aneignen, oder immer einen Juristen mit im Team haben.
>
> Salopp gesagt: "Wenn Du auf dem gebiet arbeitest, musste da wohl
> durch!" ;-)

Ich habe mich auch nicht wirklich beklagt, sondern nur darzustellen
versucht, dass sich nicht alle Programmierprobleme vor "man", Sedgewick und
ein bisschen Coder-Philosophie beugen.

>> 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.
>
> Immer wieder diese Argumentation.... die letztlich die
> Zeitprobleme bei der Entwicklung wieder verstärkt, auf Grund
> derer man keine Zeit für's testen hat.

Wenn die Firma ihren Hintern in ein dickes Geldpolster graben kann, kann sie
4 Tage testen. Wenn sie so ein Polster nicht hat, ist sie froh, wenn der
Kunde seine bestellte Ware hat und dann erstmal zahlt. Oder gehst Du zu
Deinem Chef und sagst: "Hey, ich muss den Code noch ausgiebig prüfen, zahlen
Sie mir mein Gehalt ruhig ne Woche später!"?

>> 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.
>
> Nein, da widerspreche ich mir nicht.
> Das sind eben zwei Seiten einer Arbeitsweise, die
> zu extrem fehlerarmem Code und geringen Entwicklungszeiten
> führen.

Ich hatte Dich so verstanden, dass Du der Ansicht bist, dass fehlerarmer
Code den Testzyklus signifikant verkürzt. Das halte ich eben für ein
Gerücht. Sauberer Code hat eigentlich "nur" den Zeitvorteil, dass er im
Fehlerfall leichter zu durchschauen und zu warten ist. Und natürlich, dass
man ihn bei Modifikationen später leichter versteht und ihn auch
wiederverwenden kann. Dass das alles gut und richtig und schön und
erstrebenswert ist, da werde ich Dir natürlich nicht widersprechen, weil ich
es selbst genauso sehe wie Du. Nur das Argument, dass dadurch Zeit beim
Testen gespart wird, dem folge ich nicht.

> Man geht als erstes so ran, daß man möglichst keine
> Fehler einbaut. Und als zweites testet man seinen
> Code trotzdem sorgfältig, weil man weiß, daß man
> nicht perfekt ist, auch wenn man das anstrebt.
> Durch selbiges vorgehen wird der Code sehr zuverlässig
> und während die Kollegen bei Terminvorgaben kalte Füße
> kriegen, guckt man nach einer Weile, wenn sich die
> Vorteile dieser Arbeitsweise bemerkbar machen, fast
> schon gelangweilt aus dem Fenster. ;-)

Ein paar Zeilen tiefer sagst Du (sehr treffend), dass die Kunden selbst
nicht wissen, was sie wollen bzw. (in meinen Worten) nicht in der Lage sind,
ihre Anforderungen verständlich zu formulieren. Dadurch sind (zumindest
Abgabe-) Termine sowieso Makulatur. Du schreibst schicken Code, der lesbar
und sauber und im Zweifel ausgiebig getestet ist und lieferst aus. Zwei Tage
später rasselt unter Garantie das Telefon, und der Kunde erklärt Dir, dass
er das so ja gar nicht wollte, sondern so und so... Also setzt man sich
wieder dran und ändert den Quelltext. Das Ganze geht dann mindestens viermal
so, und natürlich braucht der Kunde die Änderungen gestern, weil ja
vorgestern schon der Abgabetermin war.

Das mag bei einem Treiber nicht so tragisch sein. Aber bei einer
Lohnabrechnung ist es das durchaus, weil die Mitarbeiter des Kunden schlicht
und ergreifend am Monatsende ihr Geld wollen - so, wie Du und ich auch ihr
Geld wollen, wenn Zahltag ist. Bei uns ist 12x im Jahr Stichtag.

> Es ist natürlich nicht unbedingt überall gerne gesehen, wenn
> man zügig seine Sachen erledigt.
>
> Sieht halt nach mehr aus, wenn man hektisch durch die
> gegend rennt und ständig den Debugger benutzt (benutzen
> muß).

WENN denn der Debugger zuverlässig ist ;-) Die Entwicklungsumgebung, die ich
benutzen muss (hat historische Gründe, die Programmiersprache, die wir
verwenden, ist ein Exot), ist von den Tools her vergleichbar mit Microsoft C
6 (also nix IDE, nix Formdesigner, sondern alles zu Fuß) und von der
Sauberkeit der Bibliotheken irgendwo zwischen Linux 0.1 und Windows 95.
Sprich: neben den eigenen Böcken, die man ab und zu schießt, muss man auch
noch die Böcke des Compiler- und Lib-Herstellers ausweiden. Unser toller
Debugger schmiert bei jedem zweiten Versuch, einen Thread im Programm zu
starten, ab.

(Ich habe mir die Sprache nicht ausgesucht, und 12 MB Quellcode mal eben in
eine andere Sprache zu übertragen, ist schlicht nicht drin.)

>> 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.
>
> Es gibt Tests, die checken, ob die Funktion gewährleistet ist.
> Und es gibt Tests, die Prüfen, ob das programm nicht schon
> bei simplen Fehleingaben den Geist aufgibt und nen Core ausspuckt.
>
> Bei solch sehr komplexen Dingen, wie Gesetzestext-Tests muß natürlich
> auch ein externer Test die inhaltlichen Prüfungen durchführen.
> Und soweit der Programmierer Sachkenntnis davon hat, wird er
> auch dies schon im Vorfeld mal vorprüfen können.
> Was der Programmierer aber auf jeden Fall abchecken sollte
> ist, ob sich das programm nicht bei Fehleingaben oder zu
> großen Datenmengen verabschiedet.

Stimmt, aber mein kleines Programmiererhirn ist leider nicht so kreativ, um
sich vorher zu überlegen, auf welche abenteuerlichen Ideen unsere Kunden ab
und zu kommen. Neben aller Testerei und neben allem sauberen Code ist es
(schon allein aus Haftungsgründen) unerlässlich, buchstäblich jeden
Tastenanschlag und jeden Mausklick zu protokollieren. Solche Logs lesen sich
manchmal wie 1001 Nacht, und man kommt aus dem Staunen nicht mehr raus...

> Das kann ja wohl nicht all zu schwer sein.
> Und wenn man sowas sorgfältig macht, spart es mehr
> zeit, als wenn man dreimal vom Kunden das Programm zurück
> bekommt.
> Klar bedeutet es ein bischen mehr Aufwand, wenn man nicht
> nur etwas in den Editor rotzt, sondern es auch im Betrieb
> prüft. Aber letztlich fährt man damit besser.

Tun wir. Wir setzen unsere eigene Software nicht nur für uns ein, sondern
arbeiten auch noch als Rechenzentrum für Kunden, sodass wir uns auch im
Echtbetrieb selbst testen. Dennoch tauchen manche Klopse erst in höchst
exotischen Fällen auf, manchmal Monate nach dem Release, weil unsereins
Durchschnittscoder an eben diese eine Konstellation nich gedacht hat. Das
eben ist das Problem der Testsuites: Die Tests sind immer nur so gut, wie
ihre Ersteller kreativ und vorausschauend sind. Das ist nunmal ein
Lernprozess, der mit jedem neuen Release weiter geht - und in der Natur der
Sache liegend dem Produkt immer ein bisschen hinterher hinkt.

>> 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.
>
> Ja, bevor man sowas durchtestet sollte man schon mal seine
> Teilmodule getestet haben. Wenn die schon abstürzen, weil
> man statt einer Ziffer einen Buchstaben eingegeben hat,
> und man immer nur getestet hat, was passiert, wenn man
> statt einer 1 eine 3 eintippt, dann ist man mit seiner
> testerei schludrig gewesen.

Richtig, aber erstens ist wie gesagt die Kreativität der Anwender
grenzenlos, was Fehlbedienungen betrifft, zweitens ist wie gesagt unsere
spezielle Entwicklungsumgebung weit von der Güte eines GCC entfernt,
drittens ist wie gesagt der größte zu testende Teil der, der das Fachwissen
umfasst.

> Und das sind leider Sachen, an die die meisten Programmierer
> nicht denken. Das müssen sie aber, sonst sind es Pfuscher.

Wenn es um "Ziffer statt Buchstabe" geht, stimme ich Dir da selbstredend zu.

>> 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.
>
> Sag ich doch: Amn darf sich eben nicht auf irgendwelche
> Testabteilungen verlassen.

Diese "Testabteilung", die nicht inhouse, sondern von den Krankenkassen
stammt, ist allerdings nunmal die, die L&G-Software deutschlandweit
freigibt. Selbst KHK oder SAP darf ohne diesen Segen nicht offiziell
verwendet werden. Somit sind alle L&G-Buden auf diesen Test angewiesen.

>> Wieder ein paar Tage Arbeit, weil es da (glaubs oder nicht) nicht
>> mit einem #ifdef test getan ist.
>
> Wer intensiv #ifdef nutzt, hat eh schon seine Probleme
> mit in den Code eingebaut.

Endlich kann ich Dir mal ohne Wenn und Aber zustimmen! :-)

> Nun gut, unter dem Gehaltsaspekt betrachtet, würde ich
> da jetzt auch garnicht mehr intensiv weiter drauf rum reiten... ;-)
>
> Macht weiter so, so erhalet ihr Euch wenigstens Eure Arbeitsplätze.
> Aber überspannt den Bogen nicht, sonst geht der Kunde zur
> Konkurrenz.
> Ach nee, deswegen gibt's ja Softwarepatente: Damit man sich seinen
> Crap-Code und am besten das gesamte Geschäftsfeld von der
> Konkurrenz abschirmt, dioe womöglich besseren Code schreibt,
> und damit man weiter pfuschen kann...

Naja, ausnahmsweise mal ein Vorteil für uns: mal eben zur Konkurrenz
wechseln bedeutet eine locker halbjährige Umstellungsphase samt Einarbeitung
für alle Sachbearbeiter. Wenn ich mir aber so anschaue, welche anderen
Anbieter wir schon abgelöst haben (u.a. die beiden oben genannten Firmen),
sind wir wohl nicht so übel ;-) Fehlerfrei und immer pünktlich sind wir
allerdings trotzdem nicht.

> Ist eben nicht gut, wenn man Leuten zu viele Überstunden aufbürdet...
> ...die Qualität läßt nach, die Motivation läßt nach,...
> ... man muß mehr debuggen und muß dann noch mehr Überstunden
> ableisten - am besten unbezahlt.

Das liegt aber u.a. auch daran, dass jeder Coder mal irgendwann angefangen
hat und seine ersten Gehversuche noch heute im Code zu finden sind. Da
müssten dann mal ein paar pfiffige Inder ran, die diese Ecken neu schreiben.
Aber da sind wir wieder beim Faktor "Kosten".

> Vielleicht waren das auch nicht die representativen
> Firmen. Jedenfalls macht das mit solchen Code-Rotzern
> keinen Spaß. Und die Firmen hat's (deswegen?!) - wie ich
> hinterher erfahren habe - auch zerrissen.
>
> Naja, wieder ein Konkurs mehr... :)

Erfreulich für die Konkurrenz ;-)

>>> 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?
>
> Hast Du schon mal mehr Kommentare in Deinen Code geschrieben,
> als Code selbst, wenn das ein sehr komplexes Programm war?

Manche Leute halten mir vor, ich würde zu viele Banalitäten kommentieren.
;-)

> Dann mal schnellstens damit anfangen, denn nach dem Urlaub
> hat man normalerweise auch simple Programmteile vergessen.
> Deswegen macht es sich immer ganz gut, wenn man nicht
> mit Kommentaren geizt.
> Die gehören nämlich auch zu einer sauberen Arbeit dazu.

Völlig d'accord.

> Na, meinst Du jetzt auch, daß das zu teuer wird, wenn ein
> Programmierer seine Zeit darauf "verschwendet", den eigenen
> Code zu kommentieren? Schliesslich gäbe es doch noch Leute,
> die eine Programmbeschreibung schreiben würden?

Das machen wir (Programmierer) bei uns in der Regel selbst. Anschließend
geht das Ganze zu jemandem, der der deutschen Sprache besonders mächtig ist
und anschließend in unser Rechenzentrum. Wenn die Damen und Herren das dann
verstehen, lassen wir die Beschreibungen auf unsere Kunden los.

> Naja, daß Du nach dem Urlaub deinen Code nicht mehr kennst,
> ist nicht verwunderlich. Daß Du aber keine Möglichkeit
> gefunden hast, das Problem zu mildern (sonst würdest Du das
> ja nicht als Problem hier anführen), DAS ist es wohl eher
> was Dich aggressiv machen sollte (oder auch tut).

Ich rede gar nicht von MEINEN Problemen. Im Prinzip stimme ich Dir ja mit
all Deinen Argumenten zu. Aber manchmal geht's eben nicht anders, als dass
man sich mit seinem Laptop beim Kunden hinsetzt und dort entwickelt, bis es
klappt, weil z.B. ein Import so krude geschrieben werden muss (wegen der
gelieferten externen Daten), dass das nicht am grünen Tisch geht.

> Schliesslich ist mit zunehmender Komplexität
> der Software jeder kleine Fehler aus den vielen
> verwobenen Teilen der Software dazu in der
> Lage, einem Stunden, Tagen oder gar Wochen
> an Debugging-Zeit zu bringen, insbesondere
> dann, wenn man in den einzelnen Teile der
> Software auf Fehlerprüfungen verzichtet hat,
> weil man möglicherweise denkt, das Problem
> in diesem kleinen teil noch überblicken zu
> können. Das ist aber genau der Fehlschluß!

Richtig, aber diese Art der Tests funktionieren eben nur in den generischen
Modulen. Neue GUI-Features oder ein Datenbank-Abstraktions-Layer kann ich
natürlich mit Dummy-Daten testen. Neue §§-Umsetzungen gehen aber nur im
Gesamtzusammenhang, und die dort auftretenden Fehler stammen fast immer aus
dem Zusammenwirken des Ganzen. (Im Übrigen hilft einem dort auch der beste
Debugger nicht mehr weiter, weil man sich dann tagelang totdebuggt.)

> Nun gut, Deine ganzen EDV-Onkels kenne ich nicht.
> Das ändert aber nichts am Programmiererproblem.
> Davon abgesehen: Wenn die die Datanbank selbst
> verhunzen, ist es das problem des Kunden.
> Da sollte man dafür sorgen, daß man für sowas
> nicht haftet.

Logo, dafür gibt's ja die Vertragsjuristen. Auf der anderen Seite will man
sich seine Kunden ja auch nicht vergraulen. Man kann schlecht jeden zweiten
Tag zu manchen Kunden sagen, dass sie völlig unfähig sind. Was machst Du mit
einer 55-jährigen Lohntante, die sich mental seit 15 Jahren gegen PCs wehrt?
Gehst Du zu ihrem Chef und sagst: "Also, die Frau Müller ist völlig fehl am
Platz, schmeißen Sie die mal raus!"?

>>> 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...
>
> Nun, das Problem, das ich schildere (Programmierer testen
> ihren Code nicht genug) und das Problem, das Du schilderst
> (Verzwickte Testfälle im Falle der juristerei-Software),
> sind zwei verschiedene.

Wir reden beide vom Testen. Du vom Test einer Eingabe über ein Textfeld, ich
vom Test eines Abrechnungsalgorithmus. Test ist Test. Der eine ist halbwegs
trivial, der andere ist hochkomplex. Testet man nicht, bleiben evtl. Fehler
im Programm. Bei Deinem Fall passiert vielleicht nur ein Core-Dump. In
meinem kriegen vielleicht die Arbeitnehmer zu wenig und das Finanzamt zu
viel Kohle.

> Das ist ist wieder so ein Gerücht. Die modernen rechner
> sind schnell genug. Wenn man nicht irgendwelche aufgeblähten
> Bibliotheken nutzt, sondern egenen, brauchbaren Code schreibt,
> dann geht das auch mit der Geschwindigkeit.
> Daß Fehlerprüfungen die Geschwindigkeit so rasant herunter
> setzen, ist eine Mär.

Von "rasant" ist nicht die Rede. Fakt ist aber bei uns, dass die nötigen
Prüfungen inzwischen locker 30% des Codes ausmachen.

> Das Produkt wird teurer, wenn man es zwanzig mal vom Kunden
> für Nachbesserungen zurück bekommt, weil man meinte, man sei
> schlau, das Update doch noch schnell "heute Abend noch" raus
> zu geben, statt es erst mal zwei Tage zu testen.
> Die zwei Tage Testerei sind aber schon alleine dann vertelefoniert,
> wenn man mit dem Kunden einmal über die Bugs, die man hätte selber
> finden können, lamentiert. Das dann mit den 20 mal
> multipliziert (oder auch nur fünfmal) und mit der Anzahl aller
> involvierten Personen (Programmierer, Kundenbetreuung, Entwicklungs-
> leitung, Chef) multipliziert mit dem jeweiligen Stundensatz
> der involvierten Personen... tja, das hätte schon wieder das
> Gehalt für den neuen Kollegen aus der Juristerei sein können,
> der den Laden voranbringen würde...

Zustimmung. Die endet aber eben am 27. eines Monats, wenn der
Abrechnungstermin da ist. Da MUSS alles klappen. Also kann man definitiv
NICHT noch zwei Tage testen, wenn man nicht haftbar gemacht werden will. Im
Zweifel schickt man also was raus, das man mal eine Stunde getestet hat.

> [...]
>> 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.
>
> Habe kein Interesse an Deinem Arsch.
> Hast Du noch was anderes anzubieten? ;-)

Hm, n Bier? *g*

>> 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!"
>
> Es gibt eben Leute, die sich als Admin und Programmierer
> verdingen, aber eher im marketing arbeiten sollten, da
> sie zwar alle Entscheider überzeugen können, aber letztlich
> keinen brauchbaren Code hervor bringen.
> Und sicherlich gibt es auch in vielen marketing-Abteilungen
> Leute, die wohl eher mal programmieren sollten, weil sie
> im Marketing absolut nichts gutes für die Firma tun
> können. - Habe auch schon alles in der Praxis gesehen, sowas!

Jau, vor allem dem zweiten Teil stimme ich völlig zu. Für die
Verkaufsfritzen gibt's nur Umsatz, und Umsatz bedeutet immer "geht nicht
gibt's nicht". Und das ist natürlich Stuss.

Im Übrigen ist unsere Bude so überschaubar, dass sowieso jeder Programmierer
auch Servicemensch und Kundenberater ist. Das hält einen zum Einen auf den
Boden und zum anderen hilft es der meiner Ansicht nach besten Methode, guten
Code zu schreiben - nämlich einfach mal zwei Tage gar nicht zu
programmieren. Das entspannt und bewahrt vor Betriebsblindheit :-)

Carsten