tkdmatze

eat your own dogfood

In der IT bedeudet das, daß man seine eigene Software selbst einsetzen soll. So macht es z.B. Google mit Blogger und Microsoft mit .NET.  Aber auch im Web 2.0 Zeitalter gibt es dafür gute Beispiele 37signals.com: BaseCamp und Co sind unter der Prämisse entstanden, es selbst nutzen zu wollen. Und offensichtlich wollen auch viele andere die Produkte benutzen. Und das, obwohl viele Experten sich über den Erfolg solcher Entwicklungen wundern.

kenne dich selbst

Qualität von Software hat viele Gesichter, genau wie die Art Software wahrzunehmen. Jeder hat seine eigenen Prioritäten und Vorlieben.  Um in einem Team gute/benutzbare Software zu schreiben, sollte also für jeden Faktor ein entsprechender Typus Mensch vorhanden sein. Denn manche Kriterien schliessen sich normalerweise aus, dort ist es wichtig einen Mittelweg zu finden.  Betrachten wir einmal, bei welchem Entwickler man welchen Kompromiss eingehen muss, denn jeder Entwickler wird seine Prioritäten auf die Prioritäten des Projektes anwenden. Sonst wird das Projekt zwar einen Aspekt von Softwarequalität übererfüllen, andere jedoch vernachlässigen.  Aber betrachten wir einfach mal die Typen Entwickler und ihre Vorstellung von “guter Software”.

Zweckdienlichkeit

Eigentlich überflüssig zu erwähnen, daß ein Programm seinen Zweck erfüllen muss. Allzu oft gibt es aber Projekte, in denen ein Teilprojekt, zB ein CRM in einer Auktionsplattform, zu einem Selbstläufer wird und viel mehr Entwicklungsarbeit bekommt als nötig, um den eigentlichen Zweck zu erfüllen. Entwickler halten sich gerne mit solchen Nebensächlichkeiten auf, deswegen an das Ziel erinnern.

Einfachheit/Übersichtlichkeit

Als Beispiel nenne ich hier einfach mal die ganzen IPhone- Apps. Wer hätte gedacht, daß Programme, welche jeweils nur einen einzigen Verwendungszweck haben, zu Millionen gekauft werden? Aber Menschen, die nicht so erfahren mit Computern sind, sind weit weniger verwirrt. “Wo muss ich klicken?” erübrigt sich die geringe Anzahl an Menus und Icons. Eine geringe Anzahl an Optionen, von denen die meißten aber “oft” bis “stets” benutzt werden, runden das Ganze ab. Der Benutzer kann in einem Satz genau sagen, was die App macht.
Entwickler handeln hier gerne nach dem “YAGNI – You ain’t gonna need it” – Prinzip. Dabei wird übersehen, daß die nach der “MoSCoW” -Methode aufgestellten “Should have” Anforderungen den Erwartungen bestimmter Benutzergruppen entsprechen.

Geschwindigkeit

GMail durchsucht E-Mails in Bruchteilen von Sekunden. Die gleiche Aktion dauert in Outlook ein Vielfaches. Es gibt diese Performancefreaks, die zB tagelang bei ORM- Frameworks alle Möglichkeiten der Cache- Konfiguration ausprobieren, um noch ein paar Millisekündchen herauszuholen. Die Geschwindigkeit muss akzeptabel sein. Gerade im Web gilt: alles unter einer Sekunde ist gut. Ob 987 ms oder 612 ms  -  der Benutzer bekommt den Unterschied gar nicht mit. Deswegen bei akzeptabler Geschwindigkeit stoppen.

Portabilität und Flexibilität

Es gibt Programme, dort kann man die Daten nur in einem Format abspeichern, zB der gute alte Editor. Andere wiederum können Daten(zB Bilder) in hunderten Formaten speichern. Fakt ist: Wenn man über 90% der standardisierten und/oder vom Benutzer erwarteten Formate unterstützt, ist alles in Ordnung. Ist es ohne großes Refactoring unmöglich ein anderes Exportformat zu implementieren, läuft was falsch. Der Kompromiss bleibt: so viele implementieren wie nötig – so viele zusätzlich erstellbar wie möglich.