Was Softwareentwicklung vom Handwerk lernen könnte

Ich erinnere mich daran, wie im Dezember 2008 die ersten Gespräche bei 8thLight und Obtiva in Chicago geführt wurden, die im März zum Manifest des Software Craftsmanship führten. Viele der Ergebnisse bekam ich leider nur indirekt über die Software Craftsmanship Mailingliste mit. Dennoch erinnere ich mich an ein Gespräch, das ich zu der Zeit mit einem alten Freund hatte. Mein Freund ist Dachdecker und auch mehr als zwei Jahre später glaube ich noch fest daran, dass wir als Softwareentwickler – Tester wie Programmierer – viel von anderen Handwerksberufen lernen müssen.

Mein Freund Felix und ich unterhielten uns auf der Straße. Er war zu Besuch gekommen und auf dem Weg zum Auto, um wieder heim zu fahren. Felix erzählte von seinem Chef. Damals kränkelte die Firma ein wenig daran, neue Aufträge zu bekommen. Ich erzählte davon, dass wir zum Teil Ausschreibungen in der IT hatten, und wie ich bei meiner damaligen Firma daran beteiligt war. Allerdings kam mir der gesamte Angebotsprozess über Ausschreibungen seltsam vor.

Felix meinte, dass sein Chef auch ab und an bei einer Ausschreibung mitmachen würde, diese aber nie gewinnen würde. Bei einem Ausschreibungsprozess kommt es darauf, den niedrigsten Preis anbieten zu können. Ein Auftraggeber hat eine gewisse Arbeit, die zu erledigen ist. Firmen geben Ihre Angebote für die anstehende Arbeit ab, und der Auftraggeber kann sich dann für denjenigen entscheiden, der seine Anforderungen am besten erfüllt. In den meisten Fällen gewinnt derjenige, mit dem niedrigsten Angebot.

Felix erzählte weiter, dass sein Chef von Zeit zu Zeit das ein wenig stinkt. Dann kommt er zur Baustelle, und brüllt die Kollegen an, dass sie schneller arbeiten sollten. Mal vom sog. blaming abgesehen, steckt hinter dieser Geschichte noch ein wenig mehr.

Felix erzählte mir, dass die Kollegen seinen Chef meistens verstehen können, aber konkret in diesem Fall, fragen sie ihn, wie sie das denn anstellen sollten. Sollten sie einfach statt sechs Nägeln nur drei pro Dachpfanne nehmen? Diese simple Frage genügte, um dem Chef Einhalt zu gebieten. Der Chef hatte nämlich einen klaren Qualitätsstandard. Dieser hielt zwar seinen Preis hoch, aber die Kunden kamen deswegen auch gerne zu ihm. Sechs statt drei Nägeln konnte nämlich im Zweifelsfall bedeuten, dass das Dach 10 Jahre länger hält und auch den nächsten Sturm übersteht.

Im Handwerk gibt es im Deutschen einen Begriff für „drei statt sechs Nägel“: Pfusch. Mein Vater war Automechaniker, mein Opa war Tischler. Bei beiden habe ich beobachtet, dass sie genau wußten, wann sie pfuschen, und wann das unangebracht war. Wenn mein Vater bei seinem Arbeitgeber Geld verdient hat, hat er nicht gepfuscht. Dann hat er den besten Job abgeliefert, den er abliefern konnte. Wenn er aber meinen 16 Jahre alten VW Polo repariert hat, am Wochenende, in der Freizeit, dann wußte er, dass ich als armer Schüler nur wenig Geld zur Verfügung hatte. Er wußte, dass er hin und wieder mal pfuschen mußte, um meinen Kostenrahmen nicht zu sprengen. Er klärte mich aber stets über die Nachteile dieses Handelns auf, so dass ich mir über die Konsequenzen stets im Klaren war.

In der Softwareentwicklung gibt es ebenfalls Pfusch. Programmierer pfuschen, wenn sie ihren gerade geschriebenen Code nur kurz antesten, um die langweiligen Testfälle den Testern zu überlassen. Ein Tester pfuscht, wenn er blindlinks das Anforderungsdokument kopiert, ein paar Wörter von „sollte“ nach „wird“ ändert, um einen Testplan zu erhalten. Ein Projektmanager pfuscht, wenn er dem Kunden Zugeständnisse macht, ohne Rücksprache mit dem Entwicklungsteam zu halten.

Sie mögen Pfusch in der Softwareentwicklung unter anderen Begriffen kennen. „Bananen-Software“ und „Hotfix“sind alles Wörter für den Pfusch, dem wir täglich begegnen. In meinen Augen ist es regelrecht traurig, dass wir selbst unseren Beruf derart herabwürdigen. In meinen Augen ist es nur eine Frage der Zeit, bis wir uns selbst um jegliche Glaubwürdigkeit „gepfuscht“ haben. Wie Cory Foy auf der XP 2010 so schön sagte, ist der Softwarekunde heutzutage froh, wenn er ein Datum bekommen kann – wohl wissentlich, dass dieser Termin noch dreimal verschoben werden wird. Auch daran scheinen 10 Jahre Agile Software Entwicklung nichts geändert zu haben.

Dabei ist die Alternative so einfach. „Nein.“ Üben Sie das mehrmals täglich vor dem Spiegel. Genau wie mein Freund Felix, der „Nein“ zu drei statt sechs Nägeln sagen kann, sollten wir uns an die eigene Nase fassen, und die Konsequenzen unseres Handelns transparent machen. Wir sind diejenigen, die wissen, welche Auswirkungen Abkürzungen im Code und im Design haben können, welche Risiken noch offen sind, nachdem wir getestet haben. Letzten Endes sind wir diejenigen, die unsere Manager benötigen, um informierte Managemententscheidungen treffen zu können. Wenn wir unfähig sind, unsere Sichtweise zu kommunizieren und unsere Position zu verteidigen, dann brauchen wir uns auch nicht wundern, wenn schlechte Entscheidungen gefällt werden, die Überstunden für uns bedeuten.

Stattdessen sollten wir endlich aufwachen aus unserer Opferhaltung. Wenn wir nicht in der Lage sind, die Verantwortung für unsere Miskommunikation zu übernehmen, wer dann soll das bitte schön für uns tun? Das nullte Gesetz der Professionalität besagt schließlich:

We should take responsibility for the outcome of every decision you make.

Wir sollten die Verantwortung für das Ergebnis jeder unserer Entscheidungen übernehmen. Die Entscheidung, Informationen über die Auswirkungen unserer Abkürzungen vorzuenthalten, ist eine Entscheidung, für die wir zu wenig eigene Verantwortung übernehmen bislang. Wenn wir dieser PFlicht nicht nachkommen, dann pfuschen wir auf die schlimmste Art und Weise. Und wir sollten uns nicht wundern, wenn unsere Kunden zukünftig einen anderen Anbieter suchen werden. Jemand, der nicht pfuscht.

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks

2 Gedanken zu „Was Softwareentwicklung vom Handwerk lernen könnte“

  1. wow! Das ist mal ein Blog Post! Ich teile Ihre Ansicht und denke, dass es besser ist dem kunden etwas gutes zu verkaufen mit dem er Glücklich ist. Meist kommen gerade in der Softwareentwicklungen die indirekten „Anweisungen“ zum Pfusch aber von oben…

    1. Danke für den Kommentar. Bei den Anweisungen von oben bin ich der Überzeugung, dass wir uns weniger als Opfer hinstellen sollte. Zu einer professionellen Tätgkeit gehört auch, dass wir uns professionell verhalten und uns gegen „Pfusch von oben“ wehren müssen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert