Kontraste ausgleichen

„Wofür werdet ihr eigentlich bezahlt?“ Wenn ich das in Clean Code Developer Schulungen frage, antworten Entwickler regelmäßig mit einer Liste von Tätigkeiten wie „im Meeting sitzen, „Kollegen helfen“, „Bugs fixen“, „einen Supportfall lösen“, „telefonieren“.

Dass die Liste so Konkretes enthält, verstehe ich. Eine Abstraktion kann ich nicht sofort erwarten. Aber um die geht es mir. Denn ohne Abstraktion und zugehörige Definition bleiben all diese und viele andere Tätigkeiten willkürlich.

Also nochmal: Wofür werden Softwareentwickler bezahlt? Wofür ist ein Kunde bzw. der Arbeitgeber gewillt, Geld auszugeben?

Ich formuliere das mal so:

Softwareentwickler gleichen Kontraste mittels Code aus.

„Mittels Code“ ist einfach zu verstehen. Wenn nicht Code das Mittel wäre, würden nicht Softwareentwickler gefragt, sondern vielleicht Elektrotechniker, Maschinenbauer, Mediziner oder Tischler.

Das bedeutet natürlich nicht, dass Code in beliebiger Menge produziert werden sollte. Mehr Code ist nicht per se besser. Aber überhaupt Code wird bei Beauftragung von Softwareentwicklern als Mittel angesehen, ein Ziel zu erreichen.

Doch was meine ich mit „Kontraste“?

Ein Kontrast ist für mich eine sichtbare, spürbare Differenz. Da ist kein sanfter Übergang, kein gleiten, keine Spannweite, kein Spielraum. Im Kontrast steht sich zweierlei deutlich Verschiedenes gegenüber.

In Bezug auf die Softwareentwicklung meine ich damit, dass das, was Code heute leistet und das, was dem Kunden heute dienlich wäre, in „ins Auge springendem Gegensatz“ (Duden) steht.

Dem Kunden würde Code dienen, mit dem er z.B. sein Ersatzteillager verwalten kann - aber es gibt noch keinen Code. Das ist der größte Kontrast. Später, ist schon Code vorhanden, mit dem der Kunde Lagerbewegungen buchen, allerdings noch keinen Inventurbestand eintragen kann. Dann ist der Kontrast geringer, wenn auch immer noch deutlich. Noch später erlaubt der Code dann die Erfassung eines Inventurbestandes, stürzt jedoch bei Eingabe einer Zahl mit Dezimalpunkt statt Dezimalkomma ab. Der Kontrast ist nun wiederum geringer, doch er ist immer noch sichtbar.

Kontraste treiben die Softwareentwicklung an. Die „Potentialdifferenz“ zwischen dem, was sein soll, und dem, was ist, übt Kraft auf die Softwareentwicklung aus.

So weit zum Begriff „Kontrast“.

Ich hoffe, dir erscheint nun meine Beschreibung der Aufgabe von Softwareentwicklern plausibel: Sie sind ihr Geld wert, wenn sie Kontraste ausgleichen. Je mehr Kontraste pro Zeiteinheit sie ausgleichen, desto besser. Zeit, die in den Ausgleich von Kontrasten fließt, ist gut aufgewandte Zeit, also keine Verschwendung. Mehr davon!

Allerdings… so einfach ist es dann doch nicht. Kontraste lassen sich in verschiedenen Dimensionen verorten. Mir fallen zumindest drei ein:

• Blockadedimension
• Bekanntheitsdimension
• Schadensdimension

Und je nach dem, wo in diesem Raum Kontraste sich befinden, gehört ihr Ausgleich mehr oder weniger zur Kernaufgabe des Softwareentwicklers.

Blockierende vs. durchlässige Kontraste

In der ersten Dimension geht es darum, ob Kontraste eine Blockade darstellen. Wird der Kunde durch den Kontrast behindert, etwas (sehr) Wichtiges oder gar (sehr) Dringendes tun erreichen?

Wichtig ist, was mittel- bis langfristig bewältigt werden muss, um die Existenz zu sichern. Beispiele: die jährliche Steuererklärung, Fortbildung, Vorsorgeuntersuchung beim Arzt.

Dringend ist, was akut bis kurzfristig bewältigt werden muss, um die Existenz zu sichern. Beispiele: Tanken, wenn die Tankanzeige aufleuchtet, zum Arzt mit starken Unterbauchschmerzen, die Diplomarbeit fertigstellen, wenn morgen Abgabetermin ist.

Software dient im geschäftlichen Umfeld der Bewältigung von Wichtigem und/oder Dringendem. Ein Kontrast, der anzeigt, dass das noch nicht in nötigem Umfang geschieht, ruft nach Ausgleich. Wie laut er jedoch ruft, hängt davon ab, wie stark das Empfinden des Kunden ist, dass der Kontrast ihn bei der Bewältigung behindert.

Der Kontrast „fehlende Inventurbuchungsmöglichkeit“ mag bei einer Lagerhaltungssoftware über längere Zeit keine Blockade darstellen, der Kontrast ist „durchlässig“. Am Tag der Inventur jedoch stellt der Kontrast sicher eine Blockade dar.

Du siehst, die Position eines Kontrastes in der Dimension kann sich verschieben. Was vor einem Monat noch durchlässig erschien, ist heute eine Blockade. Auch anderes herum ist Bewegung möglich: eine fehlende Auswertung, die dem mittleren Management vor einem Monat noch als gravierend blockierend erschien, ist inzwischen durchlässig geworden, weil das obere Management die Strategie geändert hat.

Nach Eliyahu Goldratt, dem Vater der Engpasstheorie (Theory of Constraints), wird Wert dadurch Geschaffen, Blockaden für den Kunden aus dem Weg zu räumen:

Value is created by removing a significant limitation to an extent no other can […]

Die erste Frage bei einem Kontrast ist also, inwiefern er einen Engpass darstellt. Auf dem Weg zu welchem Ziel stellt er eine wie große Blockade dar (im Vergleich zu anderen Kontrasten)?

Bekannte vs. überraschende Kontraste

Kontraste, die in ein Spezifikationsdokument nach reiflicher Überlegung einfließen, sind geplant. Der Kunde ist sich ihrer Existenz bewusst, bevor es die Software gibt oder auch, bevor er die Software bedient, solange ihr Ausgleich nicht beschlossen wurde.

Etwas weniger geplant sind Kontraste, die während der Diskussion von Spezifikationen mit der Entwicklung sichtbar werden. Du weist den Kunden z.B. darauf hin, dass seine Spezifikation eine bestimmte Datenkonstellation nicht abdeckt. Dem Kunden ist damit ein Kontrast bekannt, der ihm vorher unbekannt war.

Gänzlich überrascht wird ein Kunde jedoch von einem Kontrast, der zur Laufzeit auftritt. Er hat eine Erwartung an das Softwareverhalten, die plötzlich enttäuscht wird. Ein Programmabsturz ist dafür ein gravierendes Beispiel.

Bei der zweiten Frage zu Kontrasten geht es darum, inwiefern der Kunde um ihre Existenz weiß. Wann wird ihm ein Kontrast bewusst?

Schädliche vs. harmlose Kontraste

Ein Programmabsturz bei einer Division durch 0 in einer Taschenrechner-App ist ein überraschender Kontrast. Das ist nervig, aber harmlos.

Ein Programmabsturz während einer Umbuchung, der Daten in einem inkonsistenten Zustand hinterlässt, ist schon nicht mehr so harmlos. Wenn die Inkonsistenz nicht entdeckt und behoben wird, können sich weitere Fehler einschleichen, die gravierende Konsequenzen haben können.

Und ein Programmabsturz, bei dem Daten gelöscht werden, der ist deutlich schädlich. Werte werden zerstört, die nun mühsam erneut zu schaffen sind.

Ein blockierender Kontrast erschwert zwar das Vorankommen, aber im schlimmsten Fall tritt der Kunde „nur“ auf der Stelle. Ist ein Kontrast jedoch schädlich, wird der Kunde sogar zurückgeworfen. Werte werden vernichtet, das Fundament, auf dem die Arbeit ruht, wird instabil.

Kontraste auf dem Radar

Mit diesen Dimensionen im Anschlag nehme ich mal einige Kontraste aufs Korn. Ganz einfach ordne ich ihnen in jeder Dimension eine Position 1, 2 oder 3 zu. 1 bedeutet schwach/wenig, 3 bedeutet stark/viel/sehr.

Eine Division durch 0 blockiert nicht, ist aber sehr überraschend, weil der Kontrast zur Laufzeit auftritt, wenn er auch keinen Schaden hinterlässt.

Anders die Kundenauswertung: die erscheint im Moment blockierend, ist aber nur mäßig überraschend, da sie in der ursprünglichen Spezifikation schon enthalten war, jedoch auf die lange Bank geschoben wurde. Schädlich ist ihr Fehlen bei aller künstlichen Dringlichkeit ebenfalls nicht.

Wenn ich diese Beurteilungen der Kontraste nun in ein Radardiagramm eintrage…

…dann wird klar, warum Kontrast nicht gleich Kontrast ist. Im Radardiagramm haben die Kontraste nämlich eine sehr unterschiedliche Fläche. Die korreliert nicht mit dem Aufwand zum Ausgleich der Kontraste, sondern steht für mich für deren Einfluss auf den Softwareentwicklungsprozess.

Je größer die Fläche, einen desto größeren Brocken stellt der Kontrast für den Entwicklungsfluss dar. Kleine Brocken stören ihn nicht, große Brocken verwirbeln ihn.

Genau: Für mich wird der Fluss der Softwareentwicklung nicht negativ durch Aufwand beeinflusst, der zunächst einer Anforderung zugeschrieben wird. Kontraste, die großen Aufwand zu ihrem Ausgleich brauchen, lassen sich erstens in kleinere zerlegen. Zweitens ist erstmal egal, ob konzentrierte Arbeitszeit auf viele kleine oder wenige große Brocken entfällt, solange das in entspannter, ruhiger Weise geschieht.

Schädlich für eine konzentrierte, zügige Softwareentwicklung ist nicht Aufwändiges, sondern das, was als Kontrast überraschend, blockierend, schädlich daherkommt.

Je größer die Fläche für einen Kontrast im Radardiagramm, desto störender ist er für einen ruhigen Fluss der Softwareentwicklung. Je überraschender und auch noch blockierender und auch noch schädlicher, desto dringender stellt es sich dar. Das führt zu ad hoc Entscheidungen, das erzeugt Druck, das führt in einen Reaktionsmodus. Die Softwareentwicklung wird zur Feuerwehr.

Natürlich ist es der Job, der Softwareentwicklung, Kontraste jeder Art auszugleichen. Wenn jedoch dabei ein Ziel angesteuert werden soll, dessen Kontrast insgesamt nicht überraschend, nicht blockierend und nicht schädlich ist, dann braucht es dafür einen möglichst freien Weg.

Mehr oder weniger blockierende Kontraste stehen dem auch noch nicht gleich im Wege, solange sie bekannt sind. Dann kann der Kunde sie priorisieren für eine flüssige, entspannte Abarbeitung.

Sobald jedoch Überraschungen zu Blockaden hinzutreten oder gar Schäden entstehen… wird aus einem ruhigen Fluss ein reißender. Aus einem Softwareteam, das eben noch gemeinsam gerudert ist,

(Bildquelle: pixabay)

wird eine Flotte von Wildwasser-Kajakfahrern:

(Bildquelle: pixabay)

Als dicke Kontrastbrocken rollen insbesondere überraschende und überraschend blockierende Kontraste in die Softwareentwicklung, weil sie danach heischen, unmittelbar ausgeglichen zu werden.

Bei ihnen ist das Was und das Warum für den Kunden glasklar. Hier sind Anforderungen für ihn und die Softwareentwickler viel greifbarer, als bei anderen Kontrasten.

So verständlich das ist, es steht einer verlässlichen und zügigen Softwareentwicklung massiv entgegen. Hauptsymptom der entstehenden Verwirbelung: eine große Zahl von Kontrasten in Arbeit (work in progress), häufiger Aufmerksamkeitswechsel, nicht eingehaltene Vereinbarungen (von Terminversprechen über Prozessschritte bis Definition of Done).

Kontrastmittel

Es gibt einiges, was getan werden kann, um „großflächige“ Kontraste zu vermeiden oder zumindest ihre negativen Effekte auf die Softwareentwicklung zu dämpfen. Davon will ich heute nicht weiter schreiben.

Viel wichtiger ist mir, dir zu vermitteln, wie wichtig zuerst einmal zu erkennen ist, welche Kontraste bei dir heute im Tagesgeschäft vorliegen.

Du könntest dir ein paar Wochen lang vornehmen, jedes Issue, jede User Story, an der du arbeitest, im oben vorgestellten Kontrastraum zu verorten.

Frage dich:

• Wie überraschend ist diese Aufgabe, an der ich arbeite? Ist sie vom Kunden lange geplant gewesen oder ist ihm etwas bei Anwendung der Software aufgefallen?
• Wie stark blockiert der Kontrast, den ich ausgleiche, die Arbeit des Kunden? Arbeite ich an etwas Wichtigem oder Dringendem?
• Ist durch den Kontrast, den ich ausgleiche, ein Schaden entstanden oder drohte zu entstehen?

Versuche mal, ein Radardiagramm deiner aktuellen Aufgaben zu zeichnen. Ganz grob, das reicht.

Arbeitest du eher an kleinflächigen oder großflächigen Aufgaben? Sind die Flächen gleichmäßig oder gibt es eine „Ausreißerecke“?

Wie passt das Radardiagramm zu deinem Gefühl, wie die Entwicklung bei dir im Team läuft?

Und schließlich: Hast du die Chance, dein Geld wirklich Wert zu sein, indem du vor allem an kleinflächigen Kontrasten arbeitest? Denn dann bist du am agieren, statt am reagieren.

PS: Hast du gemerkt, dass bis hierher die Begriffe „Bug“, „Defekt“ und „Fehler“ nicht vorgekommen sind? Das habe ich natürlich ganz bewusst gemacht. Ich finde diese Begriffe nämlich wenig hilfreich. Sie polarisieren. Ihnen haftet die Frage nach dem Verursacher an.

Auch wenn ich eine Reflexion über Ursachen (bei negativen Folgen) immer sehr nützlich finde, halte ich sie beim Ausgleich von Kontrasten erstmal für hinderlich.

Wer ist schuld daran, dass die Lagerverwaltung bei Eingabe einer Zahl mit Dezimalpunkt statt Dezimalkomma abstürzt? Hast du als Softwareentwickler fahrlässig gehandelt? Oder hat der Kunde versäumt, genau genug zu spezifizieren?

Solche Erörterungen sind im besten Fall zweitrangig. Erstrangig ist die Frage, wie blockierend und wie schädlich der Kontrast ist, der da überraschend entstanden ist. Denn das bestimmt seine Position in der priorisierten Kontrastliste.

Indem du auf ein Urteil verzichtest, das schon in „Bug“ oder „Fehler“ steckt, beruhigst du den Fluss der Softwareentwicklung. „Ah, wieder mal ein Kontrast. Interessant. Lasst ihn uns kurz verorten im Kontrastraum und dann seinen Ausgleich priorisieren.“ Das ist alles, was nötig ist, wenn ein Kontrast auftaucht. Ohne Zorn und Eifer ganz entspannt wahrnehmen, einordnen, abarbeiten.