Motivation

Der Softwareentwicklung fehlt etwas. Was fehlt, ist eine Form von Klarheit und vor allem Gelassenheit. So ist zumindest mein Gefühl, wenn ich Softwareentwickler in meinen Clean Code Trainings oder auch an ihrem Arbeitsplatz beobachte.

Wo Klarheit und Gelassenheit sind, da ist der Tritt sicher, da ist die Zuverlässigkeit hoch, da stimmt die Qualität von vornherein umfassend und die Stimmung ist entspannt. Leider scheint mir das aber nicht die Atmosphäre in den meisten Softwareentwicklungsteams zu sein. Oder wie empfindest du es in deinem Team?

Stattdessen herrscht oft Verwirrung angesichts dessen, was der Kunde will, es sind die Backlogs voll mit Bugs und das sprichwörtliche “What the fuck?!” ist ständig hinter den Monitor-Triptychons im Team Room zu hören (oder zumindest auf den Gesichtern der Entwickelnden zu lesen).

Was mögen die Gründe dafür sein? Es gibt sicher viele. Ein ganz grundlegender scheint mir jedoch dieser: Die Softwareentwicklung ist ins Ungleichgewicht gekommen. Sie erfüllt nicht in gleicher Weise systematisch und kompetent alle Anforderungen des Auftraggebers. Sie starrt auf die einen und lässt dabei einen blinden Fleck für die anderen entstehen. Das führt früher oder später zu einem für den Auftraggeber sehr spürbaren Qualitätsdefizit, dessen Ausgleich schwerer und schwerer wird. Das Kind ist tief im Brunnen. Es fehlt einfach an Nachhaltigkeit.

Gelassenheit ist in solcher Situation nicht mehr möglich, wenn Klarheit über so lange Zeit so eklatant gefehlt hat. Programmierung mit Leichtigkeit sieht anders aus.

Mehr Technologie, mehr Infrastruktur ist darauf keine Antwort. Vielmehr ist - horribile dictu! - ein Kulturwandel nötig. Ohne grundsätzliches Umdenken geht es nicht. Die Grundhaltung ist zu verändern: Es braucht ein Bewusstsein dafür, dass auch soetwas immaterielles wie Software, Nachhaltigkeit braucht.

Wenn in deinem Team schon agil gearbeitet wird, hast du eine Ahnung, was Kultur und Kulturwandel bedeutet. Doch leider ist Agilität nicht genug für nachhaltige Softwareentwicklung. Sie ist zwar notwendig für die Nachhaltigkeit, die ich meine, aber nicht hinreichend.

Wie wichtig Nachhaltigkeit ist, weiß zwar schon lange jeder Koch und jeder Chirurg - doch die Softwareentwicklung hinkt leider noch hinterher. Die oberste Priorität haben bei Ersteren Sauberkeit und Hygiene; ohne sie sind Erfolge nur von kurzer Dauer. Wer eine Küche am Ende des Tages mit dreckigem Geschirr und voller Abfall zurücklässt, beschädigt die Grundlage für die Arbeit morgen. Wer heute Operationsbesteck nicht sterilisiert und am Ende einer Operation nicht zählt, riskiert Komplikationen morgen. Sauberkeit und Hygiene sind der Rahmen, in dem das Kochen und chirurgische Eingriffe stattfinden.

Ich bin überzeugt, dass für die Softwareentwicklung ein Nachhaltigkeitsrahmen erst noch solide aufgespannt werden muss. Korrektheit und Ordnung sind noch nicht in gleicher Weise als Grundanforderungen in der Softwareentwicklung anerkannt wie Sauberkeit und Hygiene in anderen Branchen. Das ist die fehlende Klarheit, die die Entwicklung von Gelassenheit verhindert.

Diese Situation verbessern zu helfen, ist mein Anliegen. Ich möchte dir helfen, klarer und gelassener zu programmieren. Weniger Stress durch mehr Nachhaltigkeit für deine Softwareentwicklung ist mein Ziel. Wie das erreicht werden kann, damit habe ich mich in den vergangenen 15 Jahren intensiv auseinandergesetzt. Ich hoffe, du empfindest das, was ich hier nun “an einem Ort” zusammentrage, als Hilfe in deinem Entwickleralltag.

-Ralf Westphal, 2020, Bansko (BG) / Hamburg (DE)

Programming with Ease

Nachhaltigere Softwareentwicklung in Klarheit und Gelassenheit umfasst für mich mehr, als ich dir in diesem Buch vorstellen kann. Mit ein paar Tipps&Tricks ist es nicht getan. Es geht durchaus ans Eingemachte: an deine Glaubenssätze und Gewohnheiten.

Die vielfach fehlende Nachhaltigkeit in der Softwareentwicklung ist ein so tiefliegendes Problem, dass einige Anstrengungen nötig sind, die Situation zu ändern. Du wirst Zeit brauchen, anders wahrzunehmen, zu denken und dann zu handeln. Dein Team wird Zeit brauchen, denn in der Zusammenarbeit muss sich einiges ändern. Und schließlich wird sich sogar dein Management und dein Auftraggeber ebenfalls ändern müssen in den Erwartungen an dich und dein Team.

Das klingt nach einigem Aufwand, oder? Ja, stimmt. Leider kann ich dir den nicht ersparen. Das Wurzelproblem von “schwer wartbarer Software” liegt zu tief, als dass es dafür eine schnelle Lösung gäbe. Wenn du aber dran bleibst, dann bin ich gewiss, dass sich die Mühe lohnt.

Vermitteln möchte ich dir - und deinem Team - Programming with Ease als umfassende Herangehensweise an die Softwareentwicklung, die dich abholt bei der Konfrontation mit Anforderungen und begleitet bis zur Ablieferung von hochqualitativem Code.

Um moderne Technologien und technische Feinheiten geht es nicht. React, NoSql, GraphQL, Docker, Kubernetes, Kafka… all das ist darin kein Thema. Oder wenn, dann nur indirekt in Form von Prinzipien und Konzepten, die dir helfen sollen, solche Technologien einzuordnen.

Stattdessen geht es um Prinzipien und Praktiken der Softwareentwicklung. Das hört sich zwar nach “theoretischem Kram” an, doch sei gewiss, mir ist es sehr, sehr wichtig, dass die Theorie in der Praxis gegründet ist. Theoretische Überlegungen müssen zu praktisch hilfreichen Effekten führen. Deshalb kann ich es dir nicht früh genug mit auf den Weg geben:

Welche Empfehlungen du auch immer hier lesen magst, egal wie sehr ich sie begründe, sie stehen nie höher als der Zweck. Wenn du in einer bestimmten Situation also meinst, einem Zweck nachhaltig besser dienen zu können, als durch Befolgung einer Empfehlung… dann - by all means - weiche von der Empfehlung ab. Allerdings: Du solltest schon wissen, was du da tust. Habe also eine belastbare Begründung parat - wenn schon nicht mir gegenüber, dann aber für deine Teamkollegen.

Das Gesamtthema Programming with Ease ist also umfangreich. Wie ich es dir nahebringe, habe ich lange überlegt. Am Ende habe ich mich dann für 3 Bücher entschieden, die 1+3 Themenblöcke behandeln.

Test-first Codierung ist der erste Themenblock, auch wenn Codierung die letzte Hürde ist, die du in der Programmierung nehmen musst. Dennoch macht dieses Buch den Anfang in der Trilogie, weil es thematisch dir als Entwickler wahrscheinlich am nächsten liegt. Codierung ist praktisch, Codierung wahrlich unausweichlich, Codierung hat technisch-technologischen Reiz. Ich hoffe, dort kann ich dich am besten abholen, wenn es schon so ans Eingemachte geht.

Im ersten Band geht es darum, dass Codierung aus meiner Sicht eben ausschließlich test-first stattfinden sollte. Das zu akzeptieren und dann auch zu leben, ist die erste Herausforderung auf dem Weg zu nachhaltiger Programmierung. Ich hoffe, dass ich dir die Gründe dafür im ersten Band ausführlich genug darlegen und dir diese Praxis mit verschiedenen Problemlösungsansätzen auch schmackhaft machen kann.

Softwareentwurf mit Flow-Design ist der zweite Themenblock, auch wenn Entwurf als Planung von Code der Codierung vorausgehen sollte. Weil “Planung” sich für dich aber vielleicht nicht so attraktiv anhört, wollte ich das Thema nicht im ersten Band der Reihe behandeln, auch wenn ich es für das wichtigste der drei Themen halte.

Ja, tatsächlich, ich hänge dem Glauben an, dass wir in der Programmierung mehr denken sollten. Mehr denken vor dem Codieren, ist der Nachhaltigkeit absolut zuträglich. Nicht, dass nicht gedacht würde - doch mein Eindruck ist, dass gewisse Themen dabei unberücksichtigt bleiben. Es wird z.B. viel über den rechten Einsatz von Technologien und Infrastruktur nachgedacht. Es wird auch viel über Agilität nachgedacht oder über DevOps. Und das ist alles gut und richtig. Doch es bleibt ein blinder Fleck. Um den dreht es sich bei Programming with Ease im Allgemeinen und bei Flow-Design im Speziellen: das ist die visuelle Modellierung von Softwarelösungen.

Der letzte Themenblock unter dem Bogen, den Programming with Ease spannt, ist dann die Software Anforderungsanalyse mit Slicing. Damit gehe ich noch einen Schritt vor den Entwurf und möchte dir empfehlen, Anforderungen durch eine spezielle Entwicklerbrille zu betrachten. Durch die Brille der Agilität siehst du Anforderungen als User Stories, Storyboards, Epics oder gar Event Storms. Auch das ist alles wunderbar. Du sollst davon nichts aufgeben. Doch in meiner Erfahrung ist auch durch diese Brille etwas nicht sichtbar, das dir das Programmiererleben aber leichter machen würde.

Der agilen Herangehensweise fehlt eine gewisse technische Sicht. Das finde ich ganz verständlich, allemal da sich inzwischen Scrum und Kanban als Vorgehensmodelle etabliert haben und von XP nur noch wenig zu hören ist.¹ Damit haben die “Softwarelaien” gewonnen, so dass Anforderungen von ihnen definiert werden, wie es für sie nachvollziehbar ist. Das soll natürlich auch so sein - nur darf eine Sichtweise, die dir als Programmierer dient, deshalb nicht vernachlässigt werden. Das scheint mir jedoch der Fall, so dass nachfolgende Phasen in der Programmierung dir schwerer fallen als nötig.

Insgesamt wird durch die Dominanz der “Softwarelaien” sogar mangelnder Qualität und Unzuverlässigkeit Vorschub geleistet. Ja, du liest richtig: Real existierende Agilität führt durchaus noch zu suboptimalen Ergebnissen. Das wird auch nicht besser, wenn du die Zähne noch tiefer in das agile Manifest schlägst. Es braucht einfach verschiedene Perspektiven. Agilität ist die eine. Das, was ich dir in Programming with Ease vermitteln will, ist eine zweite.

Codierung, Entwurf, Anforderungsanalyse sind die drei großen Themenblöcke in Programming with Ease. Damit verrate ich dir noch nicht zuviel an dieser Stelle. Ausführlicher begründet wird das in einem kleineren, übergreifenden Themenblock. Den umfasst die Einleitung und das erste Kapitel. Beides inklusive dieser Motivation wiederhole ich in allen Büchern, um dir zu ermöglichen, sie doch in einer anderen Reihenfolge zu lesen, als der hier vorgestellten. Zwar habe ich mir bei der Ordnung etwas gedacht - doch auch dafür gilt: zu eng solltest du das nicht sehen.

Einleitung und erstes Kapitel liefern den Hintergrund, vor dem ich die anderen Themen entfalte. Sie werden zuerst ganz grob in einem Zusammenhang entwickelt, damit du weißt, wie sie miteinander verbunden sind. Danach kommt die blockweise Vertiefung, bei der du diesen Hintergrund im Hinterkopf haben solltest.

Insgesamt ergibt sich hoffentlich für dich ein Gesamtrahmen, in dem du dich gut aufgehoben fühlst. Einfach(er) soll dir die Programmierung ja werden.

Das Softwareuniversum

Wenn Programming with Ease ein Bogen ist, den ich über deinen Softwareentwicklungsprozess spannen möchte, also ein Bogen in der Zeit, dann ist das Softwareuniversum der dazugehörige Raum für Softwarestrukturen

In diesem Raum spielt sich für mich alle Softwareentwicklung ab. Darin bewegst du dich mal langsamer mal schneller, mal in die eine Richtung, mal in die andere.

Allerdings ist der Raum des Softwareuniversums kein dreidimensionaler, sondern ein vierdimensionaler. Er besteht aus vier Dimensionen, die jede Logik auf eine andere Weise in Container fassen und zu Strukturen verbinden.

Was Logik ist, verrate ich dir in der Einleitung. An dieser Stelle nur soviel: sie ist die Essenz von Software. Dass du Logik in hoher Qualität schreibst, ist für den Kunden von höchster Wichtigkeit, denn sie bestimmt das Softwareverhalten. Du kannst sie also nicht einfach “hinklieren”, sondern musst sie sorgfältig schneiden und verpacken.

1. Zunächst musst du das, was die Logik leisten soll, in möglichst feine Anforderungsscheiben schneiden beim Slicing. Darum geht es im dritten Band von Programming with Ease.
2. Dann musst du dir überlegen, wie du vor allem funktionale Anforderungen mit Logik so erfüllst, dass du sicher sein kannst, dass deine Lösung korrekt ist. Du musst dabei aus unzähligen fremden und eigenen Bausteinen Kompositionen herstellen, die du testen kannst. Das geschieht mit Funktionen und ist Thema des ersten Bandes und auch des zweiten Bandes.
3. Um nicht den Überblick über deine Komposite zu verlieren, teilst du sie in zweckvolle Gruppen auf mehreren Ebenen ein, die Zusammengehöriges aggregieren und von anderem entkoppeln; das sind die Module deiner Software. Darum geht es vor allem im zweiten Band, aber auch schon im ersten.
4. Und schließlich musst du dich leider noch einigen nicht-funktionalen Anforderungen widmen, die du auch mit sorgfältiger Komposition von Logik nicht lösen kannst. Es bleibt dir nichts anderes übrig, als Logik auf verschiedene Hosts zu verteilen. Darum geht es vor allem im zweiten Band, aber auch im dritten.

Zweck des Softwareuniversums ist es, die Strukturelemente, die du im Grunde schon aus deiner Programmierpraxis kennst - Beispielsweise Klasse, Thread, Service, Message, Funktion -, in einen Zusammenhang zu stellen. Sie bekommen alle einen klaren Zweck im Hinblick auf die umfassenden Anforderungen des Auftraggebers. Vor allem möchte ich dir jedoch zeigen, welche Rolle sie spielen in Bezug auf die Nachhaltigkeit.

Die vier Dimensionen des Softwareuniversums sind für mich:

• Delivery: Logik in Scheiben (slices) unterschiedlicher Dicke geschnitten für die iterativ-inkrementelle Lieferung an den Kunden.
• Composition: Logik zu Funktionen zusammengestellt, um funktionale wie nicht-funktionale Anforderungen zu erfüllen.
• Decoupling: Funktionen zu Modulen (z.B. Klassen) aggregiert, um Ordnung in die Vielfalt zu bringen. Testbarkeit und Wandelbarbeit sind der Gewinn.
• Distribution: Funktionen verteilt auf Hosts (z.B. Threads) und entkoppelt über asynchrone Kommunikation um weitere nicht-funktionale Anforderungen zu erfüllen.

Jede Zeile Logik, jeder Tropfen Essenz deiner Software, lässt sich im Softwareuniversum als Punkt im vierdimensionalen Raum verorten, da Logik immer gleichzeitig Teil einer Funktion in einem Modul in einem Host in einem Slice ist.

Das muss dir im Moment abstrakt vorkommen. Es fehlen ja auch noch viele Definitionen von Begriffen. Dennoch wollte ich dir das Softwareuniversum als Ausblick nicht vorenthalten. Als ich es das erste Mal erblickt habe, war es für mich ein wenig wie beim Overview Effect: Ich konnte nun von außen überblicken, wovon ich vorher immer nur Teile gesehen hatte. Das hat mein Verständnis von Softwareentwicklung grundlegend verändert.

Deshalb gehören die Bände von Programming with Ease zu einer umfassenderen Reihe, die alle “im Softwareuniversum spielen”.