[linux-l] Dokumentenspeicher

[Frank Reker]

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. dieses aber in ein makro
kapseln, dass dann vom makefile aktiviert, bzw. deaktiviert werden
kann. dass ganze kapselt man dann im config script in einen 
automatischen test ob besagter workaround noetig ist, und gut ist!
wenn ein bug-workaround noetig ist, dann sollte dieser im config file
aktivier-/deaktivierbar sein, so dass ein austausch des binaries
bei bugbehebung des systems unnoetig wird. 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. und wenn die korrekte programmierung
mehr arbeit macht, dann dauerts eben laenger fuer die fertigstellung.
wenn der kunde das nicht will, dann muss er eben einen dilletanten
dran setzen. ICH mach nur vernuenftige arbeit - und ende der 
diskussion. wenn der kunde meine arbeit nicht will, dann geh ich
eben. aber ich liefere keinen scheiss ab. unabhaengig ob der kunde
das will oder nicht. denn im endeffekt faellt soetwas doch wieder
auf den programmierer und nicht auf den auftraggeber zurueck.
also bin ich da _SEHR_ stur.
ok - ich bin nicht unfehlbar. auch ich mache fehler. aber ich mache
keine fehler _willentlich_. ich produziere auch nicht _wissentlich_
sicherheitsluecken. und wenn der kunde es hundert mal nicht einsieht,
dass seine forderung eine sicherheitsluecke darstellt - ich mach
es nicht!!!
einmal kam ich nicht umhin. da musste ich etwas programmieren,
obwohl ich genau wusste, dass es eine sicherheitsluecke ist. nach
stundenlangen diskussionen hab ich mich schliesslich drauf eingelassen,
aber! ich habe den kram konfigurierbar gemacht. die standardeinstellung
war die ohne sicherheitsluecke. hab dann ins handbuch einen _riesen_
warnhinweis geschrieben, dass es absolut unratsam waere dieses
"feature" zu aktivieren. dann hab ich selben hinweis auch ins 
config-file geschrieben und besagtes "feature" deaktiviert. dann bin
ich zum kunden gegangen und hab gesagt. "wenn du dieses feature willst,
dann aktiviere es selbst, du musst nur besagte variable von "no" auf
"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...

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.

jeder programmierer muss hier eine entscheidung treffen (das gilt
nich nur fuer programmierer, aber insbesondere). entweder man ist
befehlsempfaenger und macht exakt was der kunde/chef will, oder 
man geht seinen eigenen weg. letzterer ist nicht immer leicht.
auch ich hatte schon meine kaempfe. - ok - ich bin freiberufler,
aber arbeite zu mehr als 90% fuer _eine_ consulting-firma. und da
war ein neuer chef, der mit meinem arbeitsstil nich klar kam. der
wollte lieber marionetten. aber ich bin stur geblieben. er hat
versucht mich zu mobben. natuerlich haette er mir einfach keine
auftraege mehr geben brauchen, aber da ich mich mit dem chef da
drueber gut verstand, war die situation fuer ihn etwas schwieriger
mich los zu werden. die zeit war fuer mich nicht angenehm. aber
im endeffekt ist er gegangen worden und ich bin immer noch.
meine sturheit hat mir recht gegeben.


-- 
Don't worry be happy ...
Ciao Frank
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20061005/16f1cc16/attachment.sig>