[linux-l] Dokumentenspeicher

Fr Okt 6 22:06:39 CEST 2006

* Volker Grabsch wrote on Fri, Oct 06, 2006 at 20:01 +0200:
> On Thu, Oct 05, 2006 at 01:02:29AM +0200, Frank Reker wrote:
> > Am Wed 04. Oct 2006 14:20 +0000 schrieb Volker Grabsch:
> > 
> > >Jep. Sowas nennt man "bug for bug compatibility". Im Ernst, einige
> > >Systeme *müssen* das tatsächlich können. Hier ist der Programmierer
> > >an vielen Stelle gezweungen entgegen der Dokumentation zu arbeiten,
> > >und es ist einer der unangenehmsten Aufträge, die man als Programmierer
> > >IMHO haben kann.
> > 
> > also - so etwas DARF nicht sein. erst einmal MUSS man etwas so 
> > schreiben, dass es ohne bug funktionieren wuerde! DANN kann oder
> > muss man ein bug-workaround schreiben.
> 
> Eine gute Idee. Kommt aber darauf an, ob man die "bugfreie Variante"
> überhaupt haben will.

Genau, und ob sie jemand bezahlen will... Viele Fixes existieren nicht,
weil sie unwirtschaftlich wären.

> > aber eine "bug for bug compatibility" vorauszusetzen ist ein
> > gaenzlich falscher ansatz.  und zeugt von einer INKOMPETENZ des
> > programierers!  ich bin programmierer, und hab manchmal mit
> > schraegen systemen oder bugs zu tun. aber so einen miserablen
> > programmierstil wuerd ich mir nicht erlauben.
> 
> Wenn ich die win32-API *benutze*, dann ist es völlig klar, dass
> ich bei Bugs einen extra Layer programmiere, der mir ne "korrekte"
> win32-API vorsetzt. Ich stimme dir vollkommen zu, dass dies kein
> Anwendungsfall für "bug-for-bug-compatibility" ist.

Oft weiss man ja auch gar nicht sooo genau, ob ein "komisches Verhalten"
nu wirklich ein Bug ist, man was falsch verstanden hat oder die Doku nur
blöd ist. Dann sind die Specs missverständlich und so weiter. Am Ende
merkt vielleicht Einer, dass eigentlich alle anderes Verhalten gewünscht
hätten, aber nu ihre Workarounds haben (und geht ja), also warum viel
Geld ausgeben, wofür das Marketing keinen Gegenwert sieht?

> Er ist nicht schön, aber das liegt nicht an den Programmieren,
> sondern am Projekt selbst. Jetzt kann man natürlich argumentieren,
> dass die Emulation von buggigen Systemen kein Projekt ist, das
> ein guter Programmierer jemals annehmen würde.

In der Praxis hat man immer Bugs und wohl fast immer auch bekannte.

> Diese Projekte sind die Ausnahme. Und nicht umsonst habe ich gesagt,
> dass sie die unangenehmsten sind. Es war lediglich ein Beispiel
> dafür, dass die offizielle Doku nochmal neu geschrieben werden muss,
> ergänzt um die "Bugs", die es mit zu implementieren gilt, da sonst
> die für diese Systeme geschriebene Software einfach nicht läuft.

Auch in Release Notes (die ja auch nach dem Erscheinen eines Releases
gepflegt werden sollen) sollte es eine Sektion "Known Bugs" geben....

> > wenn der kunde das nicht will, dann muss er eben einen dilletanten
> > dran setzen. ICH mach nur vernuenftige arbeit - und ende der 
> > diskussion.
> 
> Genau das hab ich ja gesagt. :-)
> Diese Sorte von Projekten gehört zu den unangenehmsten. Ich würde
> sowas auch nicht machen wollen, außer vielleicht aus Nostalgie.

mmm... Also mal ehrlich, in welchem praktischen Projekt werden denn
wirklich ehrlich /alle/ Bugs gefixt? Wenn es libs sind, muss man ja auch
Releases davon machen, was dann schnell das Projekt
verschieben/verlängern würde, also lebt man von vornherein mit
Kompromissen.

> Ich denke, du wusstest einfach nicht, worauf ich hinaus wollte.
> Bei End-User-Anwendungen ist Bug-for-Bug-Kompatibilität natürlich
> *niemals* das, was man will. 

mmm... Das Word z.B. nach "Speichern unter..." dieses Dokument auch
gleich öffnet, ist ein Bug. Aber ich würde mich ärgern, wenn sich das
ändert, weil ich es gewohnt bin, mich ggf. darauf zu verlassen. Gut, ich
würde mich vielleicht nur ganz kurz ärgern und dann freuen. Aber andere
kennen gar kein anderes Verhalten und würden sich noch mehr ärgern.

> OpenOffice sollte niemals Bugs von MS-Office übernehmen. 

Doch, natürlich, man möchte ja MS-Office-Dokumente öffnen können und so.

> > "yes" setzen." - das resultat: der kunde hat die konfiguration nie 
> > veraendert, und auf das "feature" verzichtet... - mit anderen worten
> > auch er hatte keine lust die verantwortung zu uebernehmen...
> > der punkt ist - deligiert ist schnell. aber wenn man selbst vor
> > der entscheidung steht - sieht die welt ganz anders aus...
> 
> Das ist ein guter Tipp. Werde ich mir merken, wenn ich mal vor
> solch einer Entscheidung stehen sollte. Bisher hatte ich aber das
> Glück, wenn auch manchmal erst nach Diskussionen, immer "sauberen"
> Code produzieren zu können.

Dann seid glücklich :-)

Ich kenne es eher, mit Kompromissen leben zu müssen, finde das auch
normal. Gut, kommt natürlich auch auf die Anforderungen an. Ich nenne
vielleicht Sachen Bugs, die für andere vielleicht nur Schwächen oder gar
"nur nicht perfekt gelöst aber prima" sind.

> > ok - meine arbeit ist fuer qualitaet bekannt, deshalb akzeptieren
> > kunden auch meine eigenheiten. auf der anderen seite, waere meine
> > arbeit nicht fuer qualitaet bekannt, wenn ich mich nicht hin und
> > wieder stur stellen wuerde.
> 
> So geht's mir auch. Ich hoffe, zukünftige Auftraggeber werden das
> ebenfalls so sehen. Ich bin ebenfalls nicht sehr schnell und habe
> pedantische Züge. Manchmal muss ich auch gebremst werden, das sehe
> ich dann auch ein. Manchmal muss ich aber auch den Auftraggeber
> bremsen. :-)

mmm... Meine praktische Erfahrung sagt eher, dass Kunden lieber ein paar
Cent "sparen" und dann viele Euros ausgeben, weil das doch nicht so
ideal war. Aber am Markt zählt meiner Meinung nach der Preis leider mehr
als Qualität - ich meine das auch im Alltag zu bemerken...

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.