Shipping Shit vs. Berufsethos
16.09.2006 Permalink Auf Roberts Blog gibt es eine interessante Diskussion zu lesen. Der Punkt, den ich aufgreifen möchte, ist: wie steht man zur Auslieferung eines Software-Systems, das unter so großem Zeitdruck entstanden ist, dass durch eine geringe Testabdeckung (sowohl automatisierter Unittests als auch Integrations- und Systemtests) eine halbwegs ausreichende Qualität im Betrieb nicht gewährleistet werden kann.Cedric sagt, dass es unprofessionell ist, gar nichts, zu spät oder zu wenige Features zu liefern.
Robert ist der Meinung, dass "shipping shit" unprofessionell ist. Mit "shit" meint er Software unzureichender Qualität, die also von Fehlern nur so strotzt.
Wie stellt man sich als professioneller Software-Entwickler dazu?
"deliver no matter what" oder "deliver either nothing (in-time) or high quality
(late)"?
Mein Herz schlägt natürlich für die hohe Qualität. Ich weiss, dass miese Qualität immer zurückkommt, und dass es sehr schmerzhaft und teuer ist, ein System, das sich im Betrieb befindet, sauber zu debuggen. Und "sauber" ist dann auch sehr relativ: mehr als den schlimmsten Schaden wird man so nicht verhindern, und das Unternehmen wird auf lange Sicht ein Vielfaches der Software-Kosten zu tragen haben, die man durch eine weniger agressive Zeitplanung hätte aufbringen müssen.
Aber wir Software-Spezialisten sind nicht alleine auf der Welt (zum Glück, wer würde sonst die Rechnung bezahlen?) und die Ziele des Geschäfts, für das eine Software gebaut wird, und des Managements, das dafür verantwortlich ist, sind maßgeblich, nicht die der Software-Entwickler. Es kann politisch oder aus Marketing-Gründen erforderlich sein, mit einer schlechten Software früh an den Start zu gehen, nur um zu behaupten, man sei bereit. Das ist nicht schön und bisweilen verlogen. Und die Frage, ob das die richtige Management-Strategie ist, um einem Unternehmen und seinen Kunden zu dienen, ist berechtigt. Sie kann aber z.B. auch beantwortet werden mit: "Ein Börsengang, der ein Geldbeschaffungsinstrument ist, steht bevor. Wenn das Unternehmen jetzt ernste Schwächen bei Prestige-Projekten zeigt, dann steht das Vielfache der potentiellen Software-Schadenskosten zur Disposition." So gibt es auch trifftige Gründe, Software-Mist zuzulassen.
Was ist unter diesen Umständen professionelles Verhalten?
Nun, zu hoher Zeitdruck zwingt uns dazu,
- die vernünftige Vorgehensweise, die vorhersagbare Qualität produziert, zu verlassen,
- Arbeiten auszulassen oder nicht abzuschließen,
- mehr Fehler zu machen, als bei normalem Arbeitspensum passieren würden.
Also
- Professionell ist, dies konkret und verständlich dem Management gegenüber darzulegen und konsistent die resultierenden Konsequenzen sowie den Status und Fortschritt zu berichten.
- Professionell ist, zusammen mit dem Management nach Wegen der Schadensvermeidung zu suchen (ok, manchmal erscheint das aussichtslos, aber der Versuch zählt).
- Am Ende ist professionell, wenn man seinem Auftraggeber fest in die Augen blicken kann, und folgender Satz gilt: "Wir haben Dir immer gesagt, was passieren wird. Du kanntest die Konsequenzen, es war Deine Entscheidung, und wir haben das Beste daraus gemacht." (Ob man den aber so ausspricht, steht auf einem anderen Blatt.)
Wenig professionell ist
- Nicht wissen, wo man steht.
- Nicht wissen, was die korrekte Vorgehensweise ist.
- Nicht wissen, was man durch den Verzicht darauf riskiert.
Ganz und gar unprofessionell ist:
- Die Klappe halten, wenn man sieht, dass Ziele nicht erreicht werden.
- Commitments eingehen, von denen man weiss, dass man sie nicht halten wird.
- Aussagen und Berichte schönen oder fälschen.
Das befriedigt nicht, ich weiß. Wir wollen Dinge liefern, die was taugen. Aber wenn das nicht geht, dann muss der Auftraggeber wenigstens eine faire Möglichkeit erhalten, eine bewusste Entscheidung für "shit" zu treffen.