Nach inzwischen einigen Jahren in der Bearbeitung von Fehlern bei CRM Software beginnen sich ein paar klare Linien abzuzeichnen. Man kann es sicher verallgemeinern, aber das laß ich erstmal. Wenn man für ein etwas größeres Projekt verantwortlich ist, bekommt man natürlich auch alle Fehler mit die der Kunde meldet oder die intern entdeckt werden. Durch unser Anfragesystem werden sie in Gruppen klassifiziert, entsprechend den Softwaremodulen bzw. den logischen Einheiten. Beispiel: Materialverwaltung, Kundenstamm, usw.
In diesen zynischen Zeiten der Gewinnmaximierung steht natürlich immer die Begrenzung der Kosten obenan, das ist bei uns nicht anders. Nachdem das nun eine Zeitlang fröhlich ausgewertet wurde kam heraus, was alle schon längst wußten: Die Dauerbaustellen machen die meisten Probleme. Nichts ungewöhnliches soweit. Jetzt werde ich natürlich oft nach der Ursache dieser Probleme gefragt (das ist der unangenehme Teil mit der Verantwortung). Die Antwort ist entweder kurz das Symptom (Schludrigkeit, Verschlimmbesserung, Funktionalität nicht kapiert, Seiteneffekt übersehen, Inkompetenz (ja, gibt es auch), mehrdeutige Konzeption, Verteilungs- oder Runtimefehler, falsche Versionierung, Altlasten) oder ich versuche mich in einem Vortrag über den Grund, weshalb diese Probleme an besagter Stelle gehäuft auftreten. Im Duell zwischen Konzeption und Entwicklung gibt es natürlich kaum eine Chance, diese Probleme der Konzeption zuzuschieben, so attraktiv es auch erscheinen mag. Aber trotzdem gibt es eine Beziehung zwischen gewissen Konzepten und einem Berg von Programmfehlern. Durch geeignete Konzeptionierung lassen sich diese Engpässe nämlich bedeutend verringern. So könnte man es machen:

• Abläufe und Verfahren sollten möglichst gleich sein. Das erwartet der Benutzer und erleichtert der Entwicklung die Verwendung von gemeinsamen Code.
• Der Anwendungsfall sollte so simpel wie möglich sein. Ernsthaft. So simpel wie es geht. Aber wenn es nun mal komplex ist? Dann in primitive Einzelteile zerhacken. Denn die Entwickler sind Simpel, und die Kunden erst recht ;-)
• Nie, gar nie, einfach nie im Leben sollte eine neue Funktionalität quasi als "Trittbrettfahrer" auf eine vorhandene Funktion "aufgepfropft" werden. Das geschieht etwa so: "Huch, der Kunde will gern eine neue Funktion XYZ, aber hier haben wir ein Modul, das macht schon XY, also machen wir doch eine kleine Erweiterung dafür und basteln eine Markierung rein, mit der man unterscheiden kann, ob das Modul jetzt XY wie gewohnt oder XYZ macht". Das ist zunächst sicher plausibel, denn die Kosten bleiben im Rahmen. Doch später geht die Entwicklung weiter und bald wird klar, daß hier zwei ein Bett teilen, die nicht zusammen gehören. Nur ist leider in der Zwischenzeit alles viel zu kompliziert geworden, als daß man sie noch mit vertretbaren Aufwand trennen könnte.
  Ich meine das nicht aus Entwicklungssicht (da ist die Lage anders: gemeinsamer Code in die Basisklasse, usw.) sondern aus konzeptioneller: "Die Extrabonuspunkte sind ja so ähnlich wie die Sonderbonuspunkte.. naja, also, dann könnten wir sie ja zusammen in einer Maske anzeigen nur im Falle von XYZ muß dann in der Spalte ZZZ anders gerechnet werden....". Man ahnt ja, worauf das hinausläuft.

Auf seiten der Entwicklung wird nur zu gern der Fehler gemacht, den Code unter entwicklungsmäßigen Gesichtspunkten in verschiedene Module zu unterteilen. Beispiel: "Diese drei Funktionen verwenden alle die Library XY, von daher müssen sie in ein Modul zusammengefaßt werden". Natürlich gibt es immer wiederkehrende Elemente, die man gut zusammenfassen kann: Datenbankkonnektivität, Kommunikationsmodule, Standardmasken. Aber nur zu oft passiert es, daß zum Beispiel zur Auflösung des Referenzpfads irgendein Modul hinzugefügt wird, nur weil dort eine Methode ist, die man gerne verwenden würde. Die Lösung hieße eigentlich Refakturierung und wird leider nicht von allen Kollegen verstanden und ausgeführt. Das Ergebnis ist dann, daß auf einmal Abhängigkeiten zwischen Dingen bestehen, die aus Anwendersicht nichts miteinander zu tun haben. Der Kunde versteht dann (zu Recht) nicht, warum z.B. für die Funktion des Wareneingangs das Kundendienstmodul benötigt wird.
Hier gilt einfach, die Abhängigkeiten so gering wie möglich zu halten. Das hat den Vorteil, daß man es leichter hat, wenn z.B. nur einzelne Programmteile portiert werden sollen. Ich hab gut reden! Darf ich doch jeden Tag mit einer Codebasis arbeiten, an der o.g. Probleme zuhauf vorhanden sind. Ein Grund brauche ich halt um das mal loszuwerden ;-)