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

[Guntram Trebs]

On Fri, 21 Feb 2003, Oliver Bandel wrote:

> On Thu, Feb 20, 2003 at 11:27:53PM +0100, Carsten Posingies wrote:
> > Oliver Bandel <oliver at first.in-berlin.de> schrieb:
> >
> > 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.
>
>
> Na gut, das sieht aber eher danach aus, daß man bei Euch
> den Programmierern im Entwicklerteam noch einen Juristen
> zur Seite stellen sollte.
>
>

...

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

Wenn das das Budget hergibt, schaden kann es nichts. Aber der Jurist
kann dem Programmierer ja keine Anleitung im Programm-Code geben, die muß
der Programmierer schon selber finden. Und dazu muß er ebend doch einen
ziemlich guten Durchblick haben:

 - wie funktioniert das grob
 - wie sehen die Details aus
 - was gibt es für Spezialfälle
 - wie kann ich das Problem abstrahieren
 - wo könnten sich in Zukunft Schwierigkeiten ergeben, weil ich die
   Funktionalität nicht mehr erweitern kann
 - ...

Gerade bei den letzten beiden Punkten werden Nicht-Programmierer extreme
Schwierigkeiten haben. Da kommt von den Experten nur Mist, weil sie ebend
keine Ahnung von Programmierung haben.

Am besten man arbeitet da mit Entscheidungsfragen und fügt gleich noch ein
Beispiel mit an ...

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

Manchmal kann man es sich ja nicht aussuchen. Außerdem kann es ja auch
spannend sein, mal was zu machen, was man noch nicht beherrscht.

Und was soll denn der Hersteller von Personalsoftware machen? Warten,
bis er gute Programmierer bekommt, die zufällig auch noch Jura- und
Arbeitsrechtskenner sind oder gute Programmierer nehmen und versuchen,
denen das so gut es geht einzutrichtern?

By the way, das beste für so einen Hersteller wäre, wenn er die eigene
Software gleich in der eigenen Firma verwendet. Dann noch einen
Programmierer einmal in der Woche in die Personalabteilung schicken, da
müßte er einfach nur ganz normal mitarbeiten, vielleicht sogar under cover
als studentische Aushilfe ;-)
So ein feedback wirkt manchmal Wunder, wenn in der nächsten Release
plötzlich die Probleme verschwinden, über die man sich in der Kaffeepause
immer lustig gemacht hat.

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

Manchmal ist es gar nicht so einfach zu erklären, dass am Anfange
scheinbar nichts passiert, weil man ebend Zeit braucht, um zu entwickeln
und zu testen. Dass man am Ende schneller wird und in einem anderen
Projekt plötzlich auf Code zugreifen kann, den man schonmal programmiert
hat, außerdem der Code zuverlässiger läuft, das merken nur Leute, die sich
damit auskennen, außerhalb der Entwicklungsabteilung leider kaum jemand.

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

Notfalls kann man ja s tun, als wenn man hektisch durch die Gegend rennen
müßte und den Debugger kann man ja auch mal anschmeissen, am besten auf
dem Code vom Nachbarn dann. Der passende Gesichtsaussdruck stellt sich vn
selber ein ;-)

Auf jeden Fall ist das einfacher, als ruhig und gelassen zu bleiben, wenn
man extremen Termindruck hat.


> > 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.
>
> Ja, das kann ich dann sehr gut nachvollziehen, daß die dann keine
> Böcke mehr haben. ;-)

Meine Meinung dazu:

Wenn mir der Arbeitgeber weniger zahlt als meinen Mitarbeitern und ich
keine Aussicht habe, in absehbarer Zeit mehr zu verdienen, muß ich auch
weniger leisten. Die gewonnene Zeit kann ich ja dafür verwenden, neue
Technlogien auszuprobieren, möglicherweise hat mein Arbeitgeber ja
auch was davon. Wenn der Arbeitgeber das nicht einsieht, ist es Zeit,
mich nach einer anderen Stelle umzusehen. Möglicherweise ja in einer
Firma, wo ich mehr dazulernen kann, das ist ja auch eine Form der
Bezahlung.

> > > Und der ist in der Arbeitswelt weit verbreitet.
> >
> > Wie gesagt, ich glaube da nicht dran, dass das so weit verbreitet ist.
>
> Habe ich selbst bei meinen Kollegen miterleben dürfen.
>
> 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 ist auf jeden Fall ein Teufelskreis, selbst erlebt :-(
Ich hatte da ein Projekt, was leider nicht stabil gelaufen ist. Die Fehler
lagen nicht bei mir, aber es hatte 3-4 Monate gedauert, bis ich sie
rausbekommen hatte. Da hab ich ne Menge Erfahrungen gesammelt und viele
Überstunden gemacht. Irgendwie ist das trotzdem negativ an mir hängen
geblieben. Dazu kommt noch, daß ich der einzige bin, der hier java kann,
also daß ein anderer mal draufschaut, war auch nicht drin. Zum Schluß war
ich dann auch ziemlich am Ende ...

> > 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.
>
> Da ich selbst programmiert habe, und mich nur mal umschauen
> musste, hat das nichts mit Klischees zu tun, sondern mit
> dem erschauderten Erblicken meiner Umwelt.
>
>
> 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... :)

Nicht jeder Programmierer hatte die Chance, Informatik zu studieren,
ältere Semester haben teilweise eine Umschulung beim Arbeitsamt gemacht.

Da lernt man nicht das nötige Handwerkszeug, um abstrakten
wiederverwendbaren Code zu Programmieren. Wenn man aber den Leuten zeigt,
wie es besser geht und langsam bessere Strukturen einführt, dann können
die das auch ...

> > Hast Du schonmal Code geschrieben, der so komplex war, dass Du nach einem
> > Urlaub Deine eigenen Ablaufdiagramme nicht mehr verstanden hast?

deshalb sollen Programmierer ja auch nie mehr als eine Woche Urlaub am
Stück bekommen ;-)

> > >> 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.
>
> Nun gut.
> das ist vermutlich ein Sammelsurium aus if-Anweisungen.
> Au weia. OK, da muß man sich dann was anderes einfallen
> lassen (geht auch; aber das muß ich hier nicht weiter ausbreiten :)).

ist auf jeden fall ein interessantes Problem, um mal drüber nachzudenken ;-)

(ein Glück, dass meine Probleme doch etwas einfacher sind)

> > > 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.
>
> Am besten noch einen Juristen ins Entwickler-Team holen.
> Kunden wissen meist eh nicht, was sie wollen. Und es dauert
> ja auch immer ewig, wenn man sowas klären muss.

oder die eigene Software verwenden und zwar nicht von den Programmierern,
sondern vn den Mitarbeitern

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

Das kommt darauf an, wie aufwendig die Überprüfungen sind. Die Frage ist
auch, ob ich Überprüfungen nur mache, wenn ich neue Daten einpflege oder
auch dann, wenn ich Daten auslese.

Dass der Kunde lieber das System auf einem alten Rechner laufen läßt, als
auf einen neuen raufzuziehen, ist auch verständlich: never change a
(almost) running system.

> > >> 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?
>
> Man muß das tun, man sollte auch, aber es tun ja die wenigsten
> Leute. Im Linux/GPL-Umfeld ist es ja sogar "in", häufig seine
> Updates heraus zu bringen.
> Dann muß man eben nicht gleich als erster solchen Krams
> installieren, sondern wartet auf "stable releases".
> Das ist dann zumindest nicht mehr ganz so drastisch, wie
> der "janz-neu"-Hype.

Die Leute testen ihren Code ja (hoffentlich). Gerade bei Hardware
ist das aber schwierig, da es soviele Kombinationen gibt und nicht alle
alles zum Testen zur verfügung haben.

Als wird der Code als beta gekennzeichnet und rausgebracht, wenn man
meint, alles korrekt programmiert zu haben und auf den vorhandenen
Systemen auch getestet hat.

Dann gibt es erstens Freiwillige, die Mittesten und ihre Bugreports
zurückschicken, auch in der Hoffnung, dass sie dafür irgendwann eine
stabile Version bekommen und dann mag es auch sein, dass einige Leute
beta-Treiber verwenden müssen, um bestimmte fetures zu verwenden. Die
müssen allerdings auch wissen, was sie tun und entsprechend testen ...

Zumindest sollte es so sein, die Praxis mag manchmal anders aussehen. Aber
ich hab immer noch einen riesigen Respekt vor den Kernel-Programmierern,
die Systeme debuggen, auf die sie keinen physischen Zugriff haben, sondern
nur auf Grund vn Bugreports.


mfg,
Guntram

P.S.

soviel Zeit, wie ihr zum emailen habt, macht ihr wohl weder unbezahlte
Überstunden, noch seid ihr im Terminstress. Ich hoffe, ihr seid nicht
unterbezahlt ;-)