Individuelle Anwendung von Software Engineering Sprachen oder Werkzeugen führt auf Dauer zu Unzufriedenheit und erhöhtem Aufwand.

Diese Erkenntnis hatte ich Anfang der 90er Jahre. Damals wurde seit einigen Jahren ANSI C eingesetzt, ich arbeitete bei der Firma Tasking und war zuständig für den Support deren C-Compiler. Damals fiel mir auf, dass nach der Auslieferung von Compiler Updates häufig die selben Kunden massive Supportprobleme meldeten, während andere Kunden signifikant weniger Probleme zu haben schienen.

Damals ging ich dieser Auffälligkeit auf den Grund und sah mir die Supportanfragen, speziell nach Compiler Updates, genauer an. Das Ergebnis: Die meisten Supportanfragen konnten eigentlich nicht eindeutig als Compiler-Fehler angesehen werden. Sie begründeten sich eher in der Anwendung der Notation C außerhalb des ANSI Standards. Bei noch genauerem Hinsehen stellte ich fest, dass der Programmierstil der Problemkunden sehr individuell und weit von dem entfernt war, was man als defensive Programmierung bezeichnen würde.

Individuelle Anwendung von Software Engineering Sprachen oder Werkzeugen erhöht die Unzufriedenheit

Auf Grund dieser Erkenntnis habe ich damals angefangen, wann immer sich die Gelegenheit ergab, den Code der Kunden genauer hinsichtlich des Programmierstils anzusehen und der Häufigkeit der Supportanfragen gegenüber zu stellen. Schnell stellte sich heraus, dass es eine erstaunlich deutliche Korrelation zwischen individuellem Programmierstil und der Anzahl der gemeldeten Supportproblemen gab.

Seit dieser Erkenntnis schaue ich grundsätzlich darauf, wie Anwender Notationen und Werkzeuge einsetzen. Außerdem ist immer wieder zu beobachten, dass Anwender, die die Arbeitsmittel nicht in deren eigentlichen Sinn einsetzen, deutlich mehr Probleme haben. Und nicht nur das: Sie sind mit den Arbeitsmitteln auch deutlich unzufriedener.

Zum Beispiel: IBM Rational DOORS-Erweiterungen auf Basis von DXL

Sehr prägnante Beispiele zeigen sich bei langjährigen DOORS Anwendern. Einige von ihnen haben DOORS durch eigene DXL Scripte um individuelle Funktionalität extensiv erweitert. Das hat über die Zeit dazu geführt, dass heute viele von ihnen seit Jahren auf der inzwischen veralteten Version 8.x Arbeiten. Ein Update auf die V9.x wird immer wieder verschoben, da der Wartungsaufwand der eigenen DXL-Erweiterungen (auf Grund von Inkompatibilitäten zu neuen Versionen) nicht geleistet werden kann.

Erschwerend kommt oft hinzu, dass die Personen die die DXL Erweiterungen erstellt haben, nicht mehr verfügbar oder in anderen Projekten eingebunden und dort unabkömmlich sind.

Diese Anwender müssen inzwischen mit vielen Nachteilen und Einschränkungen leben. Ich befürchte, dass diese Einschränkungen die Vorteile der individuellen Erweiterungen längst zunichte machen.

Mit dem Hammer in der Hand sieht die Welt aus wie ein Nagel

Mein Rat: Setzen Sie sich grundsätzlich mit der Philosophie auseinander, in dessen Kontext ein Arbeitsmittel entstanden ist, und wenden Sie es nicht zu stark abweichend von dieser Philosophie bzw. diesem Kontext an. Machen Sie sich vor jeder individuellen Erweiterung oder Anpassung kundig, ob es nicht einen dem Arbeitsmittel eigenen Weg gibt, um das Gleiche oder ein gleichwertiges Ziel zu erreichen.

Individuelle Anwendung, Erweiterung oder Anpassung bergen grundsätzlich ein latentes Risiko für Probleme mit dem Werkzeug oder der Notation in sich. Diese Probleme zeigen sich häufig erst bei Updates, Wiederverwendung, Migrationen oder anderen Änderungen in der Engineering Infrastruktur und schränken die Flexibilität ein. Sie erhöhen das Risiko für nicht eingeplanten Aufwand – und dieser ist in der Regel erheblich größer, als ursprünglich erwartet. Und zu guter Letzt kommt er grundsätzlich zum denkbar ungünstigsten Zeitpunkt auf Sie zu.

Die Entwicklung einer Software verursacht 30% des Aufwandes, Wartung und Pflege verursachen 70% des Aufwandes

Und das gilt auch für individuelle Erweiterungen von Werkzeugen.

Nicht das ich falsch verstanden werde: Viele Werkzeuge müssen individuell an Projektanforderungen angepasst und konfiguriert werden und das ist in ihrer Philosophie auch so gedacht. Dagegen spricht absolut gar nichts, ganz im Gegenteil: Ich spreche von Situationen, in denen Werkzeuge nicht innerhalb des Kontextes ihres eigentlichen Sinnes eingesetzt werden. Zum Beispiel:

• Compiler und C ausserhalb des ANSI Standards
• FMEA, Projekt Management oder Team Kollaboration Werkzeuge für Anforderungs-Management und umgekehrt.
• Die Entwicklung von DSL’s wo standardisierte Notationen wie UML einsetzbar wären.

Oder im ganz Speziellen:

• DOORS für Workflow-Management
• MS TFS für Anforderungs-Management
• Matlab Simulink und/oder Stateflow zur Erstellung eines Software-Designs