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

[Oliver Bandel]

On Thu, Feb 20, 2003 at 11:27:53PM +0100, Carsten Posingies wrote:
> 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.


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


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

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



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






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



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



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

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.





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

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


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


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




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

Ja, das kann ich dann sehr gut nachvollziehen, daß die dann keine
Böcke mehr haben. ;-)



> 
> > Tut mir leid, aber das ist leider Bullshit.
> 
> Tut mir leid, aber ich empfinde DEINE Sicht als nunja... rosarot und sehr
> theoretisch.

Ach, ich habe das in der Praxis sehr oft erlebt.
Das ist garnicht theoretisch. Das ist pure Empirie.
Die will nur niemand glauben.

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




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



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




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

Nein?

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.

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?




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

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

GERADE bei sehr komplexen Problemen/Programmen ist es so,
daß die hausgemachten Bugs den größten Anteil der Probleme
verursachen.

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




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




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



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


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


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

Das steht Dir natürlich frei.


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

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.


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


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



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

Ja, und die 120% zusätzlicher Debugging-Zeit, die man
einrechnen muß, weil man nur halb so viel testen will.

Und dann nochmal 500% (oder mehr!) zusätzliche Debugging-Zeit,
die man für Debugging von schludrigem Code braucht,
der einem wegen des Verzichts auf Fehlerabfragen
vielleicht 3 % bessere Performance zur Laufzeit
beschert.

Und wenn der Kunde dann die Nase voll hat,
wird's nicht mehr teurer, sondern billiger - für
den Arbeitgeber, wenn er Lohnkosten spart,
weil er betriebsbedingte Kündigungen ausspricht.

(Ja, ich weiß, meine rosarote Weltsicht.)




[...]
> 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? ;-)


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

Und man muß das auch nicht unbedingt als eigene Philosophie
übernehmen, fünfmal am Tag seine Updates durch die gegend zu
ballern.


> *staun*

Wieso staunst Du?

Ich habe nicht behauptet, daß es im Allgemeinen weit
verbreitet ist, seinen Code erst raus zu geben, wenn
man ihn ausgiebig getestet hat.

BTW: Wenn man öffentliche cvs-Server betreibt... da muß
man sich dann auch nicht wundern. Lieber mal ein
check-in mehr, als eines zu wenig. Also kann da auch schon
mal Mist eingecheckt sein. Deswegen muß man es ja nicht
unbedingt genauso machen!



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


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!


Ciao,
   Oliver