Moin Ernst,

> Von: "Ernst Hügli" <[email protected]>
> Aussagen von Euch beiden, denn sie kolportieren weit verbreitete Mythen:

Mythen werden dann dazu, wenn man nur die Headlines liest, ohne auch
die Hintergründe zu kennen ...

> 
> - André, Du schreibst: „Die Zahl dieser Fehler steigt stetig (... es 
> sind ca. 300-400 Fehler, die pro Releasezyklus hinzukommen).“ Vor kurzem
> konnte man in einer Computerzeitschrift sinngemäss lesen: mehr als 1800 
> Fehler im neuen MSO 2010 gefunden, bevor es veröffentlicht wurde. 

Schöne Headline. Wen du diese schon zum Vergleich mit OOo heranziehen 
willst, dann muss man auch den Hintergrund sehen. 

Die Fehler, die ich bei uns nannte sind alles von Anwendern (bzw. 
testern) gefundene Fehler, die in einem regulären Arbeitsablauf
auftreten (es sei mal dahingestellt, dass einige der Arbeitsabläufe
nur von relativ wenigen Anwendern so benötigt werden).


Die 1800 Fehler in MS-Office wurden gefunden, indem man MS Office in 
tagelangen Tests auf hunderten von Rechnern (die auch absichtlich
keine "Clean-Room" installation hatten) automatisiert mit mehr oder 
weniger sinnlosen eingaben bombardiert hat. Es ist extrem unwahrscheinlich
, dass ein normaler Anwender tatsächlich über einen solchen Fehler
 stolpert. *Trotzdem* hat MSO diese Tests gemacht, die Fehler erfasst und
arbeitet an Korrekturen.

Das Verfahren ist ansatzweise vergleichbar mit dem, was auch bei uns
per automatischen Tests gemacht wird. Nur - unsere Tests folgen 
wohldefinierten Wegen und testen in der Regel erwartete Arbeitsabläufe.
Massive Tests hinsichtlich unsinniger Eingaben finden kaum statt.
Auch finden unsere automatischen Tests in wohldefinierten umgebungen
statt. Erzeugt ein Test einen Fehler, der in der durch eine 
geänderte Umgebung provoziert wird, ist es per Definition unserer
QA-Prozesse erstmal kein fehler im Programm.

Wenn wir solche Tests fahren würden - analog zu denen von MS - würde ich
wetten, dass die Anzahl gefundener Fehler um einiges höher ist.
Nur - keiner kann bei uns den entsprechenden Aufwand treiben.
Theoretisch wär es möglich, da wir eigentlich eine unmenge von Helfern 
haben, die entsprechende Tests auf ihren Rechnern laufen lassen könnten.
Nur bräuchte man dazu die Tests (und die müssen Experten schreiben) und
man bräuchte Methoden, um die Tests auszuwerten (was wiederum eher
Expertenwissen benötigt). 
Solches Expertenwissen ist unter freien Helfern kaum zu finden. Ich
schätze mal, dass es in der Community aktuell 5 Helfer gibt, die sowas
umsetzen könnten. Nur - 5 Helfer können in der Freizeit nicht an etwas 
arbeiten, was nicht mit den (ca.?) 10 Leuten abgestimmt ist, die
hautpberuflich an dem Thema arbeiten. Ohne Abstimmung hätten die 5
Freiwilligen nach 2 Jahren etwas auf die Beine gestellt, was mit der
 Arbeit der 10 Hauptberufler nichztmehr vereinbar ist. DA müssen
sich schon alle einig sein, in welche Richtung man geht.

Das Thema wurde von mir schon mehrfach angesprochen (seit meiner
Zeit als QA-Lead im OOo Projekt) - und ich habe regelmäßig die 
Antwort bekommen, dass dieses Ziel nicht dem der Hauptberufler entspricht.





> glaubt Ihr beiden wirklich allen 
> Ernstes, die Entwickler bei MS, Sun, Oracle, all die freien Mitarbeiter, 
> die bei OOo mitmachen, und andere seien derart verbohrt, engstirnig und 
> unfähig, wie Ihr mit dem ewigen Herumhacken auf ihnen suggeriert? 


Nein - Ich rede hier keineswegs von den Mitarbeitern bzw. Entwicklern.

Ich rede hier von deren Vorgesetzten bis hinauf ins Top-Management.
Diese sind dafür verantwortlich, zu regeln woran die Entwickler arbeiten.
Diese sind dafür verantwortlich, wie sich ein Unternehmen in eine
Community einbindet. 

Und auch hier ... Mythen entstehen nur wenn man keine Hintergründe kennt.
Ich war lange Zeit Projektleiter in verschiedenen Teilprojekten hier,
war Councilmitglied habe aufgrund der damit verbundenen Erfahrungen
leider die Einschätzung, dass es im höheren Management der an OOo
beteiligten Firmen doch arge Verständisprobleme gibt, wie man mit einer
Community zusammenarbeitet. In dr Regel ist nichtmal die Erkenntnis 
vorhanden, dass man das tun sollte. (Es gibt einige Ausnahmen)


> Dann 
> überlegt mal folgende kleine Rechnung: wenn eine Software nur zwei 
> Features hätte, und jedes Feature hätte 5 verschiedene Optionen und jede
> dieser Optionen bestünde wiederum aus 5 Varianten – nicht viel, wenn
> ich 
> mir so eine konkrete Software ansehe. Dann muss ich schon bei diesem 
> simplen Beispiel 50 (= 2 x 5 x 5) Möglichkeiten durchprobieren und 
> austesten. 


Wie man sowas unter kontrolle bekommt bzw. Probleme schon frühzeitig
vermeidet gehört schon zum Informatik-Grundstudium (zumindest hat es 
das bei mir). 

 
> Wollte man Euren Anspruch zum puren Nennwert nehmen, so wie Ihr ihn 
> absolutistisch hier vertretet, dann gäbe es nur eine Lösung: OOo auf 
> einem absoluten Minimalstand einfrieren, keine Entwicklung, sondern 
> sämtliche Fehler fixieren und auf mögliche neue Störungen testen –
> die 

Das ist Unsinn .. nie habe ich das *absolutistisch* vertreten.
Nur - der Fakt, dass keine Software absolut fehlerfrei sein kann,
kann doch nicht die ewige Entschuldigung dafür sein, dass die Zahl der
Fehler ständig wächst. 


> 
> - Der zweite Mythos, dem v.a. Du Matthias aufsitzt: gute Qualität setzt 
> sich quasi von allein, nur mit Mund-zu-Mund-Propaganda durch. 


Keine Angst .. dem Mythos sitze ich nicht auf. 
Ich sehe nur gute Qualität für eine Voraussetzung für eine erfolgreiche 
Software. Zumindest in der gegenwärtigen Marktsituation.
Stark beworbene Software mit immer wieder kritisierter Qualität
(oft übrigens zu unrecht) haben wir schon. Gegen >90% Verbreitung,
gebündelt mit einer extremen Marketing-Maschinerie kommen wir nicht an,
wenn wir auch noch in der Qualität der Software unterlegen sind.

Natürlich müssten wir nicht dagegen ankommen, wenn wir nicht den
Anspruch hätten, die international führende Office-Suite zu entwickeln.

> Firmen würden MS-Produkte wählen, weil man damit 
> weniger Probleme habe als mit OOo? 

Das ist doch gar nicht die Frage .. die Frage ist doch, warum sollten 
Firmen OOo wählen statt MSO.

Die Frage ist nicht einfach zu beantworten ... technische Gründe
gibt es wenige .. und wenn man dem Marketing folgt ... verliert OOo
sowieso :(

> 
> Nein, wenn OOo wirklich marktführend werden will, dann sollte man 
> schleunigst alle Ressourcen in den Entwicklungsabteilungen auf einen 
> kleinen Bruchteil zusammenstreichen und dafür die freiwerdenden Gelder 
> ins Marketing stecken. Dann in regelmässigen Abständen etwas 
> „Revolutionäres“ wie Ribbons oder so entwickeln, das zwar keine
> Probleme 
> löst, aber mit dem man in die Schlagzeilen kommt. 

Jupp .. du hast recht :)
Aber *das* wäre definitiv nichts, an dem ich mitarbeiten möchte.

In diesem Falle würde ich sogar mienen zweiten Patch für OOo erstellen
und meinen Namen aus der Liste der Beitragenden löschen.

Aber so weit sind wir noch nicht.
> 
> Nehmt mir bitte diese Standpauke nicht übel, aber es musste raus. Ich 
> habe – obschon ich theoretische Physik studiert habe – schon immer
> eine 
> Aversion gegen abgehobenes Theoretisieren gehabt. 


Oh .. ich auch. Und drum würde ich sagen Probleme verschwinden nur, indem
man sie korrigiert - und nicht indem man Entschuldigungen dafür sucht,
warum sie doch eigentlich gar nicht so schlimm sind ;)

Gruß,

André
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Antwort per Email an