Der Code ist nicht der Flaschenhals

• Video
• Audio (Podcast)

Peer-to-peer player für bessere Performance

Oder, hole dir diese Serie als Audio-Only Podcast!

Zur aktuellen Episode geht's hier

Wie produktiv ist eine Softwareentwickler*in? Wie produktiv ist ein Team? Oft verbinden wir damit vielleicht nur unterbewusst, wieviel "Code" sie produziert haben. Also wieviele Zeilen sie geschrieben haben oder wieviele Function Points sie geliefert haben. Und ich behaupte: Das spielt gar keine so große Rolle.

OK, es spielt schon eine Rolle, wie produktiv wir sind. Und im "Software Crafting" und "Agile Engineering" legen wir Wert darauf, schnell gute Software liefern zu können. Wir arbeiten am und im Code. Wir versuchen, unsere Werkzeuge besser zu beherrschen, um keine Zeit zu verlieren. Wir führen alle paar Minuten einen Red-Green-Refactor Zyklus aus, haben alle paar Stunden ein Ergebnis, das wir mit dem Rest des Systems integrieren können. Wir liefern ständig lauffähige Software an unsere Benutzer.

Wir arbeiten sehr viel daran, schnell und produktiv zu sein. Obwohl man diese Produktivität gar nicht vernünftig messen kann. Trotzdem ist der Code nicht der Flaschenhals. Oder, wie Kent Beck in "Tidy First?" schreibt:

The shortest path to instructing the computer is not an interesting end goal

-- Kent Beck, Tidy First?

Mein Name ist David Tanzer und ich helfe seit fast zwei Jahrzehnten Entwicklungsteams dabei, bessere Software in höherer Qualität schneller zu liefern. Wir befinden uns im Kapitel "Warum Agile Engineering" der Serie "Quick Glance At: Agile Engineering". Im vorigen Teil habe ich erklärt, wie man zwischen "Jetzt tun" und "Den richtigen Zeitpunkt" abwägen kann. Heute spreche ich über kurzfristige, mittelfristige und langfristige Ziele von "Agile Engineering" und "Software Crafting".

Bevor wir loslegen, mach bitte eine kurze Pause, lade dir die aktuelle Notizblock-Seite herunter, drucke sie doppelseitig aus und beantworte die folgenden Fragen:
Was tust du / was tut dein Team im Moment, um produktiver zu werden?
Was ist deiner Meinung nach der Flaschenhals in der Softwareentwicklung?

Software Crafting

Ein paar Jahre nach der agilen Softwareentwicklung ist eine Bewegung rund um "Software Crafting", von manchen auch "Software Craftsmanship" genannt, entstanden. Hier geht es darum, den Fokus mehr auf das Schreiben, Ändern, Warten und Betreiben von Software zu legen—also, auf den Code, die professionelle Softareentwicklung und uns Softwareentwickler. Oder, wie GeePaw Hill es formuliert, "The made, the making and the makers".

Das "Manifesto for Software Craftsmanship" beginnt mit den Worten "Raising the Bar". Als software crafters wollen wir die Messlatte für professionelle Softwareentwicklung höher legen, indem wir uns stetig selbst verbessern und anderen helfen, das Handwerk zu erlernen. Danach listet dieses Manifest 4 Werte auf:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

Diese Bewegung will also keine Gegenbewegung zur agilen Softwareentwicklung sein, sondern eine Ergänzung. Die Wichtigkeit von agilem Engineering geht zwar bereits, wie in einem früheren Teil der Serie erwähnt, aus dem agilen Manifest hervor, Aber für viele ist das nicht eindeutig genug.

Software crafting legt den Fokus eindeutig auf die Softwareentwicklung und die Softwareentwickler als "Community of Professionals". Und software crafting is ein wichtiger Teil der Praktiken und Vorgehensweisen, die ich hier als "Agile Engineering" zusammenfasse.

Schneller coden

Wie schnell können wir tippen? Wie gut beherrschen wir unsere Werkzeuge und wie schnell können wir diese bedienen? Wie effizient können wir Änderungen am Code vornehmen und kennen wir alle Möglichkeiten, die uns unsere Werkzeuge dafür bieten? Zum Beispiel alle Refactoring-Tools?

Alle diese Fragen sind wichtig, da wir uns nicht ständig von Dingen aufhalten lassen wollen, die schneller gehen würden. Wenn wir ständig manuell Code an verschiedene Stellen des Systems kopieren, obwohl es dafür ein automatisiertes Refactoringwerkzeug geben würde, hält uns das unnötig auf.

Und diese unnötigen Verzögerungen brechen unseren flow: Wenn wir alleine arbeiten, stören sie unsere Konzentration. Wenn wir zu zweit oder mit noch mehr Personen an einem Problem am selben Rechner arbeiten, stören sie die Konzentration von allen Beteiligten und verhindern noch dazu eine effektive Kommunikation.

Ich werde in dieser Serie also immer wieder darüber sprechen, wie wir gewisse Aufgaben schneller erledigen können. Und wie wir dieses schnellere Arbeiten auch üben können. Denn kurzfristig ist das wichtig: Wir müssen dieses Hindernis der Konzentrations- und Kommunikationsstörungen aus dem Weg räumen.

Aber dazu später mehr. Heute soll es darum gehen, dass diese Dinge, obwohl sie wichtig sind, trotzdem nicht der Flaschenhals der Softwareentwicklung sind. Sie betreffen unsere tägliche Arbeit und sind hier sehr wichtig, aber mittelfristig und langfristig gibt es Dinge, die noch wichtiger sind.

Mittelfristig: Konsistent hohe Qualität liefern

Mittelfristig ist es wichtig, Konsisten hohe Qualität zu liefern. Dadurch werden wir in diesem Zeithorizont begrenzt. Wir müssen an den richtigen Problemen arbeiten, Fehler vermeiden oder schnell ausbessern, auf Feedback reagieren und die interne Qualität der Software so hoch halten, dass wir über die Zeit nicht langsamer werden.

Dazu gehört, dass wir unsere Werkzeuge nicht nur beherrschen und effizent einsetzen können, sondern auch, dass wir sie taktisch einsetzen, um diese Ziele zu erreichen. Dass wir, zum Beispiel, nicht nur die Tastaturkürzel unserer Refactoringwerkzeuge kennen, sondern auch kontinuierliches Refactoring so einsetzen, dass die interne Qualität der Software hoch bleibt.

Dass wir schnell, sicher und ohne viel nachzudenken den Test-Driven-Development-Zyklus Red-Green-Refactor durchführen können, ermöglicht es uns, Test-Driven-Development dafür einzusetzen, das Design und die Funktionalität unserer Software in die richige Richtung zu führen. Und durch die Tests erhalten wir noch dazu ein Sicherheitsnetz für zukünftiges Refactoring, was uns weiter hilft, die Sofware änderbar zu halten.

Und ähnliches gilt für die anderen Praktiken des Agile Engineering: Wir setzen sie taktisch ein, um unsere mittelfristigen Ziele zu erreichen.

Die Dinge, die in unserer täglichen Arbeit wichtig waren—also, schnell Programmcode und automatisierte Tests schreiben und ändern zu können—legen den Grundstein dafür, was wir mittelfristig erreichen wollen. Dieses effiziente Arbeiten ermöglicht es uns, Maßnahmen zu treffen, um konsistent hohe Qualität zu liefern.

Langfristig: Gemeinsam lernen

Dave Farley sagt in seinen Videos immer wieder,

Software development is a process of learning and discovery!

-- Dave Farley

Langfristig ist der Flaschenhals das Lernen. Wie gut sind wir selbst, wir als Team, wir als Firma darin, zu lernen? Und darin, das Wissen, das wir während der Entwicklung aufgebaut haben, zu behalten, zu verteilen und zu managen?

Und traditionelle Softwareentwicklung ist nicht besonders gut darin. Jede Entwicklerin, jeder Tester, usw. arbeiten an ihrem eigenen Teilbereich, wo sie großes Spezialwissen haben. Wenn Wissen gesammelt wird, landet es in irgendwelchen Wikiseiten. Es wird versucht, Kommunikation durch schriftliche Dokumentation zu ersetzen. Dort ist das Wissen allerdings schwer zu finden und es ist noch schwieriger, es aktuell zu halten.

Es gibt wenig Budget und so gut wie keine Zeit in der täglichen Arbeit dafür, selbst als Entwickler zu lernen und besser zu werden. Oder dafür, als Team gemeinsam zu lernen und das Wissen zu behalten und zu verteilen.

Und jemand kündigt? Ein Teil ihres Wissens ist weg.

Nicht nur wir, in den Engineering Teams, müssen lernen und Wissen verteilen. Im Idealfall sollte auch der Rest der Organisation—Benutzer, Kunden, Betrieb und weitere Stakeholder—mit der Zeit Wissen und Vertrauen aufbauen. So können wir es schaffen, effizienter zu kommunizieren. Wir verbessern uns sowol in "doing things right" als auch in "doing the right thing", den beiden Dimensionen effektiver Arbeit, die ich in einem früheren Teil der Serie vorgestellt habe.

Fazit

Der wirkliche Flaschenhals der Softwareentwicklung ist gemeinsames Lernen. Oder, wie es Jason Gorman sagt:

The most important product of software development is software developers

-- Jason Gorman

Softwareentwicklung ist ein Designprozess und ein Lösungsfindungsprozess. Dabei erstellen wir nicht nur Software und Dokumentation, wir lernen auch, in diesem Prozess besser zu werden.

Der wahre Flaschenhals in der Softwareentwicklung ist, wie gut wir lernen, in unserer Fachdomäne in Zukunft schneller, bessere Lösungen zu liefern. Es ist das gemeinsame Lernen.

Heute habe ich darüber gesprochen, dass der Code und das Programmieren nicht der Flaschenhals der Softwareenticklung sind. Im nächsten Teil werde ich das Kapitel "Warum Agile Engineering?" mit ein paar finalen Überlegungen abschließen. Danach geht es dann weiter zum nächsten Kapitel, den Engineering-Praktiken.

Weitere Informationen

• Aktuelle Notizblock-Seite
• Kent Beck, "Tidy First?"
• Manifesto for Software Craftsmanship
• GeePaw Hill, Re-Balancing Made, Making, and Makers
• Dave Farley, It's Time For Waterfall To DIE