Ich bin der festen Überzeugung, dass irgendwas in den vergangenen 50 Jahren in der Softwareentwicklung schief gelaufen sein muss. Aus irgendeinem Grund existiert nach wie vor die Ansicht, dass wir auf eine bestimmte Art und Weise Software entwickeln sollten. Genau wie bei der Kindererziehung gibt es Kontrahenten für eine bestimmte Ausprägung und andere Kontrahenten für eine andere.
Über die Jahrzehnte haben sich gewissen Regeln und Erkenntnisse etabliert, die sich einem „Jungspunt“ wie mir nicht erschließen. Ein Beispiel ist meine Erfahrung, die ich zu Universitätszeiten gemacht habe, als ich in einem Kaufhaus gejobbt habe. Während meiner insgesamt 10 Jahre dort, habe ich insgesamt drei unterschiedliche Marktleiter und drei Abteilungsleiter erlebt. Alle hatten unterschiedliche Herangehensweisen.
Während einer Periode, als wir einen neuen Abteilungwleiter bekamen, drückte der damalige Chef eine Anordnung durch, dass Bestellungen nur noch vom Abteilungsleiter und dessen Stellvertretung gemacht werden durften. Die übrigen Mitarbeiter sollten „nur“ noch die gelieferte Ware packen, sowie die Reste verwalten.
Für das Trackensortiment hatten wir zwei Kataloge. Diese umfassten ca. 100 Seiten mit jeweils knapp 25 Artikel pro Seite. Das bedeutete für die Führungsebene, dass sie sich durch 2500 Produkte zweimal pro Woche durcharbeiten mußte. Der Faktor Mensch bei einer derartigen stupiden Tätigkeit – die zudem noch unter dem Termindruck, dass die Bestellung zu einem gewissen Zeitpunkt abgeschickt sein mußte, verschärft wurde – ist allerdings nicht zu unterschätzen. Bis dato hatte ich die Aufgabe, die rund 20 Seiten an alkoholfreien Getränken, Wein, Sekt und Spirituosen zu bestellen. Es brauchte einige Zeit der Einarbeitung, bis ich all die unterschiedlichen Ausprägungen an Weinen kannte, die in der Liste auftauchten. Es brauchte mindestens noch einmal so lange, bis ich wußte, welche Sorte gut lief und welche ich nur ab und an bestellen mußte.
Nun, welche Auswirkung hatte die Anordnung des Chefs? Mittelfristig wurde ich gefragt, ob ich nicht auch Konserven und anderen Produkte packen könne. Da ich eine der Ausnahmen war, die weiterhin bestellen durfte, nahm ich keine Veränderung in meinem Bereich der Getränke wahr. Aber was die Konserven anging, empfand ich zunehmend Unzufriedenheit beim Packen. Ein Beispiel waren Soßen zum Backen. Hier gab es eine Sorte Schokosauce in zwei Größen, klein und groß. Diese spezielle Sorte fiel mir beim Packen auf, da Woche für Woche die kleine Größe stets leer blieb, während die große Größe im Regal voll war, und drei weitere Einheiten kamen.
Es dauerte nicht lange, bis sich das LAger zunehmend mit Beständen füllte, die wir nicht verkauften. Der Faktor Mensch plus Zeitdruck führte dazu, dass viele Fehler unterliefen. Viel schlimmer, diejenigen, die die Waren räumten, und auch später die Reste nachräumten, wußten um die Probleme. Aber wegen des fehlenden Vertrauens gelang dieses Feedback auch nicht in die Führungsriege. Dadurch akkumulierten sich die Fehler immer mehr – nun, bis zu einem Kollaps, den ich aber nicht mehr erlebt habe.
Was können wir daraus lernen? Nun, zunächst einmal ist frühes Feedback wichtig. Je eher ich weiß, dass ich einen Fehler gemacht habe, desto eher kann ich daraus lernen. Wie Jerry Weinberg in „Becoming a Technical Leader“ erklärt, ist Lernen aus Fehlern ein Schritt, der zu Innovation führt. Zweitens schafft Vertrauen das Verhältnis, in dem ich gefahrlos Probleme kommuniziere. Vorwürfe sorgen dafür, dass ich mehr Energie meiner Arbeit darin stecke, diese Fehler zu verheimlichen. Energie, die ich andererseits vielleicht für meine Arbeit aufbringen würde. Und drittens habe ich daraus gelernt, dass die Trennung von Ausführendem und Verantwortlichen in einigen Situationen keinen Sinn macht. In einem Sportverein schreibt ja schließlich nicht der beste Trainer die Trainingspläne für alle Gruppen. Das würde gar keinen Sinn ergeben aus den zwei vorgenannten Gründen.
Nun, drei Jahre später fand ich mich in meinem ersten Job wider. Meine erste Reaktion war, warum in der Softwareentwicklung derartige Praktiken üblich waren. Tester und Programmierer arbeiten in unterschiedlichen Teams und Abteilungen, Analysten und Programmierer sind voneinander getrennt. Kunden und Entwickler sprechen nicht direkt miteinander. Wir nehmen uns dadurch wesentliches Feedback, das uns dabei helfen kann, bessere Software zu entwickeln.
Nun, damals hat mich das vielleicht ein wenig verwundert, und ich habe seitdem daran gearbeitet, dieses Silo-Denken abzuschaffen, wann immer ich es gesehen habe. Bis ich heute morgen das volle Ausmaß der Misere in der Softwareentwicklung wahrgenommen habe. Ich lese momentan ein Buch aus dem Jahr 1961. Der Name des Buchs ist „Computer Programming Fundamentals“ von Leeds und Weinberg. In diesem Buch wird das erste Mal über Softwaretesten geschrieben. Umso dramatischer empfand ich die folgenden Worte auf Seite 67:
In summary, the process of programming is not a fixed set of analyzable steps but rather a series of tentative trials, followed by careful testing of the results of those trials. Each step may be repeated several times before its particular problems are all solves. Sometimes it is necessary to attempt the succeeding steps in order to verify a particular step. […] It occurs far too frequently that a program is completed, only to reveal that the problem it solves is not really the problem of interest. Similarly, if the analysis is incorrect, the answers from any resulting program will not be solutions to the problem.
Das war vor ziemlich genau fünfzig Jahren. Die Autoren sprechen in dem Buch darüber, wie Assembler funktionieren, dass sie numerische Codes aus Assemblerbefehlen generieren, und worauf man aufpassen muss, wenn man diese händisch übersetzt. Wie kommt es, dass wir fünfzig Jahre später, nach weiteren Abstraktionsebenen wie höheren Programmiersprachen, prozeduraler Programmierung und objekt-orientierter Programmierung immer noch der Meinung sind, dass diese Mechanismen nach wie vor funktionieren können? Haben sich unsere Probleme in den letzten fünfzig Jahren denn gar nicht gewandelt?
Ich denke, wir sollten – insbesondere als Tester – kritisch gegenüber Meinungen anderer sein. Wie kommt es dann, dass wir nicht kritisch gegenüber der Methoden sind, die wir tagtäglich einsetzen sollen, nur weil sie ein Trainer uns mal beigebracht hat? Ich denke, wir sollten jede Methoden viel häufiger hinterfragen, und darüber reflektieren, wie sie uns bei der Lösung unseres derzeitigen Problems hilft. Natürlich sollten wir dafür erst einmal wissen, welches Problem wir überhaupt haben.
Und ich hoffe, dass jemand genau diese Sichtweise ebenfalls in Frage stellen wird.