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

Fr Feb 21 14:55:17 CET 2003

On Fri, Feb 21, 2003 at 08:22:40AM +0100, Carsten Posingies wrote:
> Oliver Bandel <oliver at first.in-berlin.de> schrieb:

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

Naja, mittlerweile spür' ich den miesen Markt auch. :(

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

Och, wieso? Ist doch sexy. ;-)

Falls ihr noch Unterstützung sucht...

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

Nun, wenn die 4 testtage nicht drin sind - und selbst, wenn sie
drin sind - sollte man zusätzlich ohnehin jeden Tag testen.

Genauso, wie man nicht drei Wochen lang Code eintioppen, und am Anfang
der 4. Woche das erste mal kompilieren sollte, sondern den
Compiler schon etwas öfter mal benutzen, genauseo sollte man eigentlich
auch möglichst oft testen.

Da man ja immer nur ein paar zeilen auf einmal hinzu fügt,
muß man auch immer nur diese testen. (Zusätzlich natürlich
auch mal das gesamte System).

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

Wenn man das auch nebenbei gleich gemacht hat, dann ist das keine
Extra-Zeit, sondern geht in der Entwicklungszeit mit auf.
Manche Leute aber schreiben erst Kilometerlange Code-Passagen,
bevor sie compilieren und noch längere, bevor sie's testen.

Trotzdem sollte man immer auch einen Abschlußtest durchführen.

Wer die Zeit dazu nicht hat, hat sie deswegen nicht, weil
er sie sich beim letzten mal nicht gegeben hat...

Sowas mit Debugging und Entwicklungszeit verschleppt sich.
und das ganze Problem ist sicherlich nicht linear gelagert...

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

Wenn man mit jedem Compilieren gleich die technische
Sauberkeit und Funktionalität der neuen Codeteile
abprüft - gewissenhaft -, dann ist das in der Tat so,
daß die Testzeit letztlich minimiert wird.
Den Gesamt-Funktionalitätstest des Systems, zumal wenn er
von externen durchgeführt wird, wird nur insofern
vereinfacht oder verkürzt, als man nicht durch unnötige
Abstürze am weiteren Testen der Gesamtfunktionalität
(Korrektheit des Ergebnisses) gestört wird.

Daß die Funktoanlität insgesamt aber auch getestet werden
muß, und Ihr da Eure fetten ordner von Testverfahren auch
erst mal abarbeiten müsst (oder lassen müsst), ist ja klar.

> Das halte ich eben für ein
> Gerücht.

s.o.: Wenn man die Tests wegen Abstürzen nicht durchführen kann,
dann kostet das Zeit!

> Sauberer Code hat eigentlich "nur" den Zeitvorteil, dass er im
> Fehlerfall leichter zu durchschauen und zu warten ist.

Nein. Sauberer Code (im Sinne von zuverlässig) bedeutet,
daß man auch beim Testen Zeit spart. Natürlich auch in
der Entwicklung - da ist dann "sauberer Code" zusätzlich
auch in dem Sinne zu verstehen, daß man ihn lesen kann...

> Und natürlich, dass
> man ihn bei Modifikationen später leichter versteht und ihn auch
> wiederverwenden kann.

Ja. Das ist dann der Aspekt von "sauber", bei dem es um die
typographischen Gesichtspunkte des Quellcodes geht.

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

s.o.

      (Man fängt die Fehler schon beim Entwickeln ab, oder in
      Zwischentests, statt daß man sie erst am Abschlußtest
      entdeckt! Trifft letzteres zu, wird man schon wegen des
      erhöhten Stresses beim kurzfristigen Ändern mehr Fehler
      einbauen, als man ausmerzt.)

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

Nicht unbedingt. Muß man sich eben im Zeitplan vier mehr einplanen
und aufgrund der gelassenen, fehlerarmen Arbeitsweise wird man dann
zwei Tage früher fertig. Macht sechs Tage Differenz.

(Sinngemäß gesehen; die zeitverhältnisse hängen natürlich
vom Projektumfang ab. Aber wenn man die Termine zu kurz legt,
werden sie schon wegen des Stresses mindetens dreimal so lange
werden...)

> Du schreibst schicken Code, der lesbar
> und sauber und im Zweifel ausgiebig getestet ist und lieferst aus.

Gut so.

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

Ja, und?

> Das Ganze geht dann mindestens viermal
> so, und natürlich braucht der Kunde die Änderungen gestern, weil ja
> vorgestern schon der Abgabetermin war.

Das muß man ihm halt nicht zu sagen. Was nützen denn Zusagen, die
den Kunden zufrieden stellen, aber nur kurzfristig?
Auf Dauer gesehen denkt der Kunde möglicherweise, daß er
verscheissert wird.

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

Das Prinzip ist immer das selbe.
Auch in der Entwicklung der Grafikkartentreiber wird man
wohl seinen Entwicklern Stress machen. Und dann dauert auch
dort die Entwicklung länger.

Statt negativ-Motivation sollte man die Leute lieber positiv
motivieren. Lohntüten-Bonus-System Lohntüte für bugarmen Code
oder sowas. Oder für geringste Anzahl von Rückläufen durch
den Kunden.

Aber vielleicht ist es ja aus Marketinggründen gut, wenn man
Scheisse abliefert, denn dann ist man zumindest ständiges
Gesprächsthema beim Kunden. Hmhh, muß ich mal drüber nachdenken.
Es heisst ja, schlechte Werbung sei besser, als garkeine.

<grübel>

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

Naja, wenn man den Debugger meidet, hat man mit ihm auch kein
Problem am Hals. :)

Antibugging stat Debugging!

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

Oha. naja, das ist natürlich immer Ka... sowas.
Ich habe meist versucht, an Neuentwicklungen
zu arbeiten. Dann muß man sich nicht mit den
Code-Leichen der Vorgänger herum plagen. ;-)

Aber im Moment sieht's da doch schon ziemlich
schlapp aus, auf'm Arbeetsmarkt.

Scheint keiner mehr was neu zu entwickeln, und
lieber grottenschlechte 0815-Fertig-Bibliotheken
zu horrenden Preisen einzukaufen, statt das
selbe Geld nem guten Entwickler zu geben,
der eine maßgeschneiderte Lösung zusammen baut.

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

Devise: Nicht den Code hinrotzen, sehr wohl aber die Benutzerdaten
und bei den Bedienmöglichkeiten.

Einfachmal einen der Kaffee-Junkies aus der Entwicklungsabteilung
hektisch auf allen Buttons herum drücken lassen.
Dann findet sich garantiert was. :)

Falls ihr aber keine solche Kaffee-Junky-Entwickler habt, hmhhh,
das ist natürlich ein Manko!

Zum Schreiben der Software braucht man eine gewisse
Ruhe (das ist eh manchmal nervenaufreibend genug, wenn
man eine Harte Nuß knacken muß).

Zum Softwaretesten muß man sich schon mal ganz gestresst
an den Rechner setzen und hart an der Grenze zum klinischen
Fall sein - dann bildet man die Nutzerbedingungen gut ab
und findet garantiert noch ein paar Fehler.

Stichwort Biorythmus oder so. ;-)

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

Meinst Du jetzt beim Kunden, wenn der die Software bedient?

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

Die Kaffee-Überdosis nicht vergessen. ;-)

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

Mag sein, daß sowas passiert. Meine Erfahrung lehrt mich aber,
daß da meist (nicht immer) der Wurm drin ist, weil man ihn
nicht vorher raus gelockt hat.

Sicherlich gibt's aber auch Fälle, die man einfach nicht
gefunden hat.

Aber auch sporadische Fehler haben ihre Ursache. Und nicht selten
hätte man auch diese Ursachen umgehen können.

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

Ja, klar.

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

Das muß man halt berücksichtigen und selber mal auf diese
Weise testen. Funktionstests prüfen im Allgemeinen den
erlaubten Bereich (von Eingaben) auf korrekte Ergebnisse ab.

Interessant wird's aber da, wo man die nicht erlaubten
Sachen abtestet, oder die unwahrscheinlichen.
Da tauchen dann oftmals die meisten Fehler auf, denn
die Funktionalität hat man ja schon während der Entwicklung
berücksichtigt. (Man gibt den Code ja nur raus, wenn man
auch denkt, daß er funktioniert.)

> zweitens ist wie gesagt unsere
> spezielle Entwicklungsumgebung weit von der Güte eines GCC entfernt,

Das ist natürlich etwas gemein.

> drittens ist wie gesagt der größte zu testende Teil der, der das Fachwissen
> umfasst.

Möglicherweise kann man ja Probleme dieser Tests schon
auf unteren Ebenen abblocken.

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

Ja, das ist doch aber nur ein Beispiel. Das Prinzip erweitern
und dann schön krude testen!

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

Wenn die Auf Funktion prüfen und etwas nicht nur kein korrektes
Ergebnis liefert, sondern garnicht funktioniert, oder gar
abstürzt, dann liegt das Problem woanders.
Wenn man statt 16% 160% Steuern zahlen soll, dann muß das
der Funktionstest prüfen. Wenn aber beim Klicken auf einen
Berechnen-Button das System herunter fährt, oder erst mal
20 MB Core schreibt, dann wird der
Test sicherlich länmger dauern, als wenn da bloß der falsche
Wert heraus kommt.

Man behebt den Segfault, muß die Testprozedur nochmal
durchlaufen und findet dann erst die falschen Berechnungen
(statt "*" ein "+" eingetippt, oder sowas).

Man hätte den Segfault hoher Wahrscheinlichkeit nach
schon vorher gefunden, wenn man seinen neuen Code auch mal
ordentlich-krude getestet hätte.

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

Tja, da muß man dann den Schneit haben, und auch den
eigenen Code mal wegwerfen, wenn der nur noch Probleme
bereitet.

Man sollte Wolkenkratzer nicht auf morastigem Boden bauen,
und davon ausgehen, daß die lange aufrecht stehen bleiben.

> Da
> müssten dann mal ein paar pfiffige Inder ran, die diese Ecken neu schreiben.

Das müssen keine Inder sein. Einfach mal den eigenen Code
in die Ecke feuern. Wer das nicht über#s Herz bringt, hat
da wohl ein Problem...

> Aber da sind wir wieder beim Faktor "Kosten".

Das Kosten-Argument ist - wenn es als alleiniges daher kommt -
oftmals nur eine Ausrede und sorgt nicht selten dafür, daß
die notwendigen Dinge nicht getan werden.
Das heisst ja nicht, daß man das geld verschleudern soll.
Aber da das Geld ja meist so oder so verballert wird,
sollte man es nicht ausgerechnet da einsparen, wo es
wirklich gebraucht wird!

> 
> > 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 ;-)

Wieso? Wenn die das selbe Schicksal erleidet?! ;-)

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

Na, das spricht dann wohl für Dich! :)

[...]
> > 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,

Oha.

> weil z.B. ein Import so krude geschrieben werden muss

Wer macht das bei Euch?  ;-)

> (wegen der
> gelieferten externen Daten), dass das nicht am grünen Tisch geht.

"Hallo Perl!" :)

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

Vielleicht müsste man den Debugging-Prozess, oder eben lieber
schon den Test, oder noch besser das Design mal beim Gestzgeber
ansetzen....

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

Naja, hmhhh, ääähhh.

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

Das war nur _ein_ Beispiel.

> ich
> vom Test eines Abrechnungsalgorithmus.

Daon rede ich auch.

> Test ist Test.

1) Ja, aber ein Test zielt auf Integrität des Programms bezüglich
Stabilität und Daten-Integrität des Programms bei Fütterung
mit richtigen Eingaben oder auch Fehleingaben ab.
Erst mal, um zu sehen, daß das Programm nicht abstürzt.

2) Und ien anderer Test zielt auf Funktionalität bei korrekten
Eingaben ab - unter der Voraussetzung, daß da nichts
abstürzt oder andere Daten beschädigt. (Setzt (1) voraus.)

3) Und ein dritter auf Funktionalität bei Fehleingaben -
unter der Voraussetzung, daß da nichts abstürzt oder
andere Daten beschädigt. (Setzt (1) voraus)

(2) und (3) gehören aber auch zusammen.

> Der eine ist halbwegs
> trivial, der andere ist hochkomplex.

Manche von Dir "triviale Fehler" genannte Fehler
sind aber Ursache von Fehlern der von Dir
"hochkomplexen" genannten Fehler.

Mindestens die Fehler bzgl. (1) liegen im Aufgabenbereich
des Entwicklers. Das Stichwort Bufferoverflow kann man
hier anbringen.

Solche zu verhindern, sichert auch, daß man nicht
Probleme mit Deinen "hochkomplexen" Tests/Fehlern bekommt.

Wenn man aber aus Schlamperei seine eigenen Daten überschreibt,
weil man seine Arraygrenzen überschreitet, dann hat man sich
damit Probleme eingehandelt, die weit schwieriger
zu erfassen sind, als wenn man "nur" eine der zu testenden
kopmplexen zu implementierenden juristischen Vorgaben
der Aufgabenstellung nicht korrekt eingehalten hat.

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

Statt eines Core-Dump überschreibt die Eingaberoutine möglicherweise
Berechnungstabellen im RAM und das FA schickt Dir eine
Rechnung über 200.000 Euro Steuern, obwohl Dein zu versteuerndes
Einkommen möglicherweise unterhalb dieser Summe liegt...

Das sind dann Fehler, die man nichtr so einfach findet.
Der Code der Berechnungen ist dann möglicherweise 100%
Fehlerfrei, aber der Fehler tritt wegen nachlässiger
oder unerfahrener Programmierung auf. (Oder weil man
irgend eine teure Frickel-Bibliothek einsetzt, weil der
Chef den Chef der anderen Firma von früher her kennt...)

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

Aha. Das "inzwischen" läßt darauf schliessen, daß der Prüf-Code
im nachhinein eingebaut wurde - erst mal los legen, und wenn's
kracht, baut man fehlerprüfungen ein.

Statt dessen gleich einbauen, und statt dass es kracht, meldet
der Prüfcode gleich, daß irgendwo anders was nicht stimmen kann,
da man plötzlich nicht zugelassene Daten an die Funktion
übergeben will.

Aber ok, ihr habt ne vererbte Code-Basis. Das ist dann natürlich
immer so eine Sache...

Davon abgesehen heisst es nicht, daß 30% des Codes auch
30% der Performance schlucken.

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

s.o.: Schon vorab testen, dann hat man nicht alles erst am
letzten Tag zu checken... (die Zeit sollte man sich aber
dennoch gönnen; evtl. ein neues Feature halt erst für den
nächsten Monat ankündigen, statt schon "vorgestern").

> 
> > [...]
> >> 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*

Naja, läßt sich drüber reden. :)

Was BSD angeht, ist der Entwicklungsprozess IMHO nicht ganz so
"chaotisch", wie bei Linux.

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

Aha. :)

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

Ja, ist auch mal gut, wenn man mal ne Rechnerpause macht.

Ciao,
   Oliver