Selten dürften z.B. native XML-Unterstützung, spezielle Transaktionsfeatures etc. etc. auf einmal eingesetzt werden. Ob diese Annahme zutrifft, ließe sich eigentlich einigermaßen leicht nachvollziehen: Man müsste "nur" die zugrundeliegende Software nach Funktionspunkten aufschlüsseln und überprüfen, wie viele Funktionspunkte im Tagesbetrieb verwendet werden. Sicherlich kommen da auf die Kernmodule die meisten Zugriffe. Was aber interessant zu erfahren wäre, ist die Zahl der Funktionspunkte, für die der meiste Programmieraufwand betrieben wird im Verhältnis zu den Funktionspunkten, die am meisten benutzt werden.

Ich wage zu behaupten, dass der überwiegende Teil (~80%) der Anwender die Funktionalitäten, für die der meiste Programmieraufwand (~80%) betrieben wird, zu einem ganz geringen Teil (~20%) nutzen.

Hier möchte ich bezweifeln, dass dieses Argument wirklich greift: Bei der Überprüfung von Userrequest stellte MS meines Wissens bereits fest, dass der überwiegende Teil der Wünsche bereits implementiert, den Anwendern aber unbekannt war. Aus eigener Praxis weiß ich, dass nur ein ganz kleiner Teil der Anwender in der Lage ist, überhaupt mehr als etwa 10-15% der Funktionalitäten der Anwendungen von MS Office Standard (Word, Excel, Powerpoint) zu nutzen.

Das dürfte daran liegen, dass die meisten Anwender nie in der Benutzung der Office-Anwendungen geschult wurden. Unabhängig davon, dass mit Crossover Office eine gut einsetzbare kommerzielle Lösung vorhanden ist, um Office-Anwendungen auch auf dem Linux-Desktop einzusetzen, die durchaus erschwinglich ist, kann man dem Großteil der normalen Office-Anwender einen Umstieg ohnehin zumuten: Die Grundfunktionalitäten sind bei KWord, Abiword oder OpenOffice so selbsterklärend wie bei MS Office…

Immerhin kann ich für diese aus einem allgemeinen Gerechtigkeitssinn und einer Achtung vor jedem Menschen ein Bibelzitat heranziehen: Jeder, der Böses tut, hasst das Licht und kommt nicht zum Licht, damit seine Taten nicht aufgedeckt werden. (Joh, 3, 20).

Da fielen mir aus meiner Berufserfahrung einige ein, die unter Berücksichtung dieses Textes eindeutig Böses getan haben. Offene Kommunikation bedeutet doch: Vor Veränderungen rechtzeitig informieren, Probleme kommunizieren, die eigenen Absichten/Wünsche/Pläne/Motivationen darlegen.

Unabhängig vom Medium denke ich, dass es nicht alleine das Medium ist, das Probleme bereitet. Es ist die allgemein steigende Komplexität der beruflichen Abläufe und das zu den auf dem Markt angebotenen Produkten (jeder Branche) exponential steigende Fachwissen, was beides immer schlechter beherrscht wird.

Natürlich könnte ein Problem des Mediums “E-Mail” schon die abnehmende textuelle Kommunikationsfähigkeit sein, die hiermit aus eigener Sachkunde postuliert wird. Da wäre eine Lösung vielleicht, anstelle des Textes Sprachnachrichten zu versenden und diese dann zusätzlich über Spracherkennung zu textualisieren.

Eine andere wäre, dass alle Mitarbeiter eines Unternehmens nur noch mit einer einzigen Unternehmensschnittstelle kommunizieren, die sämtliche Informationen aufnimmt, indiziert und ggf. routet, wobei die Mitarbeite sich gleich RSS-Feeds die für sie relevanten Informationen “abonnieren” können und selber entscheiden, wann sie sich informieren.

Hach, wie wäre das spannend, derartiges umzusetzen!

Letztens habe ich von einer gegenteiligen Entscheidung erfahren ("nö, haben wir keine Zeit für"), die nur von einem zeugt: Unkenntnis, Dummheit, Vernachlässigung der Firmeninteressen, keine Interesse an stabiler Software.

Then I read a little bit about the semantic web and I wonder why the bigger Wiki systems still don't support it. I mean think of Wikipedia – there people do all the meta-tagging anyway. Why not using the advantages of the semantic web and create clickable topic maps e.g.?

Also MusicXML is interesting to me. AFAIU this standard is basically a translation of the MIDI format to XML. If so, I think it's as useful as MIDI is. But not further and it does not reflect the needs of modern composers or of non-western musicians. From my opionion, a Lillypond equivalent XML standard is necessary.

Finally I'm fully fascinated by Ruby on Rails (hey, the Pragmatic Programmer's book has been released since some weeks, it's as great as every book published within this series). As I like to work more on End User Development stuff (in my free time), one approach could be to write a rails cartridge fro andromda. If that was finished, it'd be great to develop a rule engine based wizard that queries the customer different questions which result in the UML structure that'd be then processed with the rails cartrigde.
Wish one could buy time and I were rich then…