Geek’s Guide to the working Life: Kapitel 10

Die Coaches: Kenner aller dunklen Geheimnisse der Softwareentwicklung

Pavlo Baron

Es kam, wie es seit einiger Zeit fast immer kommt: Man dachte bzw. man war sich ganz sicher, dass die Geeks zu schlecht performen, zu unstrukturiert arbeiten und überhaupt das Falsche liefern. Also holte man sich einen Coach.

Man holte sich einen Coach. Einen Coach für eine spezielle Methodik, mit der man die Software ganz besonders schnell und erfolgreich entwickeln können soll. Nennen wir sie mal Tauziehen. Und dieser Coach ist zweifelsohne in jeder Hinsicht ein absoluter Kenner aller dunklen Geheimnisse der Softwareentwicklung, natürlich auch der Technik. Und was macht ihn zum ultimativen Kenner der letzten IT-Wahrheiten?

Natürlich seine Ausbildung und sein Werdegang. Denn bei einem solchen Coach kann der Geek fast schon felsenfest davon ausgehen, auf einen Soziologen, Archäologen, Psychologen, Meteorologen oder Kunsthistoriker zu treffen. Also jemanden, der einen extrem seltenen und vor allem nützlichen bzw. gefragten Beruf erlernt hat. Und durch diesen beruflichen Hintergrund mit seinem erstaunlich direkten Bezug zur Softwareentwicklung drängt sich so jemand als Coach für Geeks geradezu automatisch auf. Und wenn dieser unangefochtene Kenner mit all seinem tiefen Wissen der Materie erst mal loslegt und seine weisen Ratschläge auspackt, gibt es kein Halten mehr und der Erfolg ist quasi nur ein Abfallprodukt seiner Tätigkeit. Aber warum sollten wir nicht versuchen, seine Weisheiten ein bisschen zu übertrumpfen? Vielleicht lernt er etwas Neues.

Der Coach sagt: Architektur bzw. Design (ist egal, denn es ist eh dasselbe) macht man nicht vorher. Du setzt dich hin und programmierst los, und währenddessen machst du deine Architektur. Genau! Aber warum so schüchtern? Keine halben Sachen bitte! Warum nicht künstlerisch an die Sache herangehen? Machen wir es doch wie bei Jazz: das Schönste daran sind nicht die gespielten Töne, sondern die ungespielten Pausen. Übersetzen wir es mal in die Softwareentwicklung und erhalten: das Schönste an der Architektur ist nicht ihre Präsenz, sondern ihre gänzliche Abwesenheit.

Der Coach sagt: Softwareentwicklung ist wie Basketball – jeder sieht jeden. Aha. Es gibt noch bessere Vergleiche, z.B. Softwareentwicklung ist wie ein Wies’n-Besuch – die erste Maß schaffst du, während du die Jacke ausziehst, die zweite beim Hinsetzen, die dritte ist die Gemütliche zum Händ’l. Bei der vierten weißt du nie, wo sie hin ist. Und nur die Besseren machen ab hier weiter. Und nur die wirklich Guten können dann das in sich behalten, weswegen sie auf die Wies’n gekommen sind.

Der Coach sagt: das Team muss sich committen, selbst wenn die Anforderungen unklar sind. Ja, dann löst es doch mit einer Art Rahmenvertrag: einem Schwur, einem Eid oder gar dem feierlichen Gelöbnis. Alle stellen sich zum Großen Zapfenstreich auf und es hallt umher: „Ich, Peter Maier, committe mich heilig darauf, mich für immer und ewig zu commiten.“

Der Coach sagt: Das Faszinierende an TDD ist, dass man loscoden kann, ohne sich vorher Gedanken über das Design gemacht zu haben. Jawohl! Aber man sollte es noch etwas optimieren und ausweiten: man soll loscoden, ohne sich generell Gedanken gemacht zu haben. Auch während des Codings ist das Sich-Gedanken-Machen sehr störend, also sollte man es tunlichst komplett abstellen.

Der Coach sagt: Bugs werden behoben. Sie werden nicht priorisiert oder diskutiert. Einfach behoben, und das bei gleich bleibendem Commitment. Schon wieder zu vorsichtiges Vorgehen. Erklärt doch alles pauschal zum Feature, dann muss man nicht mal zwischen Bugs und Nichtbugs unterscheiden! Und dann erklärt man folgende Grundregel: Alles, was hereinkommt, ist ein Feature und wird sofort ungesichtet gemacht. Keine Diskussion, keine Priorisierung. Einfach gemacht, und das bei gleich bleibendem Commitment.

Der Coach sagt: Gemeinsames Schätzen (nennen wir es mal Schafkopf) ist zu zeitaufwändig – die Entwickler diskutieren zu lange, überlegen sich zu lange, wie sie etwas lösen würden etc. Stattdessen soll immer nur der Bauch entscheiden bzw. die Schätzung abgeben. Klar, aber warum dann auf dem Weg vom Kopf abwärts beim Bauch halt machen und nicht die tiefer gelegenen Köperregionen entscheiden lassen?

Der Coach sagt: Wenn man eine Iteration plant, müssen alle Anforderungen restlos bekannt und klar sein. Sicher, das sind sie ja auch meistens. Sogar erfahrungsgemäß weit vor Projektstart. Sogar so weit davor, dass man auch diesen Umstand nutzen und folgende Optimierung des Prozesses anstreben sollte: wenn man eine Iteration plant, müssen alle Anforderungen restlos erfüllt und abgenommen sein. Die Iteration ist ausschließlich dazu da, managementwirksame Erfolgspräsentationen abzuhalten.

So. Nun. Wenn die Coaches die hier präsentierten Ratschläge beherzigen, können sie zu ungeahnten Höhen aufsteigen und prompt in den Gurustatus wechseln. In jedem Kurs werden ihnen die Geeks auf jede Phrase nur noch mit einem ehrfürchtigen Om antworten. Doch die Universitäten sollten sich langsam an die modernen IT-Herausforderungen anpassen und in Zukunft mehr Kunsthistoriker für funktionale Sprachen oder Anästhesisten mit verteilten Systemen als Schwerpunkt in die Welt schicken.

Und die Geeks ihrerseits können ihren Kenner-Coach gerne darum bitten, jedem Ratschlag eine Tat folgen zu lassen. Möge sich der Herr wie jeder andere hinsetzen und ein paar Tickets (oder G’schichtl oder wie auch immer er sie nennt) persönlich abarbeiten. So mit echten Codezeilen und Tests und allem Pipapo. Oder er könnte das Entwicklerzimmer sauber halten. Sollen doch alle alles mitmachen beim Tauziehen, oder? Und für irgendwas muss der Junge doch gut sein, oder?

Pavlo Baron ist Speaker auf verschiedenen Konferenzen und Autor der Bücher „Pragmatische IT-Architektur“ und „Fragile Agile“ sowie zahlreicher Artikel. Twitter: @pavlobaron
Geschrieben von
Pavlo Baron
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.