Breakpoint Wilson: Minimalismus für Softwareunternehmen

Minimalismus
Kommentare

Minimalismus für softwareentwickelnde Unternehmen? Eine gute Idee!

Welche Schuhe trage ich heute? Soll ich lieber einen Frappuccino Latte Macchiato oder einen Mocha Latte Palermo bestellen? Oh, eine E-Mail. Habe ich heute Morgen wirklich die richtigen Schuhe angezogen? Welche Programmiersprache lerne ich als nächstes? Welches Framework? Oh, eine E-Mail. Gehe ich heute Abend zum Sport oder mache ich doch lieber nur einen Filmabend? Ach nein, ich muss ja das Auto zum Service bringen. Oh, eine E-Mail. Puh, heute schon wieder nichts geschafft. Schreibe ich halt noch schnell E-Mails.

Minimal, agile und lean – die logische Konsequenz aller Dinge?

So oder so ähnlich sehen vermutlich die Tage vieler Menschen in der IT-Branche aus. In einer durch und durch komplexen Welt sieht man sich täglich, bewusst oder unbewusst, mit vielen Entscheidungen konfrontiert. Den einen fällt das mehr, den anderen weniger auf.

Regelmäßig findet man Productivity- und Downshifting-Literatur auf den Top-Listen der Buchhändler, und auch in Zeitschriften sind diese Themen hoch im Kurs. Die Menschheit will Minimalismus, die Welt will minimal, agile und lean werden. Das ist sogar vollkommen ernst gemeint und eventuell sogar die logische Konsequenz aller Dinge. Diese Ausgabe des „Breakpoint Wilson“ nimmt sich deshalb des Themas Minimalismus in der Software-Entwicklung an.

Weniger mit mehr

Wenn dich dieses Thema Interessiert, dann vorab ein kleiner Programmhinweis: In wenigen Wochen findet die IPC 2017 in Berlin statt. Dort wird es eine spannende Keynote von David Zülke mit dem Titel „Doing everything with nothing: Architecture, Ephemeralization, and the Law of Accelerating Returns” geben.

Es wird vor allem um das von Richard Buckminster Fuller fomulierte Konzept der Ephemeralization in Verbindung moderner IT-Infrastruktur gehen. Dieses durchaus schwierige Wort beschreibt die Gesetzmäßigkeit, dass der Mensch im Laufe des technologischen Fortschritts zu immer mehr in der Lage sein wird und dabei immer weniger (Ressourcen) einsetzen muss.

Minimalismus in der Softwareentwicklung

Was hat das nun konkret mit Minimalismus zu tun? Wenn die Definitionen von Minimalismus auch noch so weit gefasst sind, geht es im Kern immer um das Gleiche: Mit so wenig wie möglich gleichbleibende oder sogar noch bessere Ergebnisse erzielen. Sämtliche Definitionen teilen im Kern die Aussage, dass

  • es zu begrüßen ist, Dinge zu entfernen, wenn Sie nicht unmittelbar oder signifikant zum Ergebnis beitragen, und
  • sich stattdessen auf wenige, wesentliche, zielerfüllende Elemente zu beschränken.

Was vom Mehrwert oder Kern ablenkt, wird entfernt.

Wie genau das aussieht, ist dann letzten Endes immer kontextabhängig. In der Design-Branche gilt beispielsweise Dieter Rams These „Gutes Design ist so wenig Design wie möglich“ als gesetzt und anerkannt. Das ist ein Grundsatz, der lange Zeit als der Wettbewerbsvorteil von Apple gehandelt wurde und ebenfalls stark durch Dieter Rams inspiriert ist. Man fokussiert sich dabei auf die wesentlichen Elemente, die den eigentlichen Mehrwert ausmachen. Dinge, die vom Mehrwert oder der Kernfunktion ablenken oder unnötigen Aufwand bedeuten, werden entfernt.

Nach diesem kleinen Exkurs ist jetzt selbstverständlich spannend zu erkunden, wie Prinzipien des Minimalismus im Entwicklungs-Alltag eingebracht werden können. Dazu stelle ich im Folgenden zwei wesentlich wichtige Ansätze vor:

Mehr Systeme und weniger Entscheidungen

Menschen wie Einstein, Jobs und Zuckerberg haben es bereits vorgelebt: sie trugen jeden Tag dasselbe Outfit. Für dritte wirkt das zunächst etwas befremdlich; schließlich kommunizieren wir und identifizieren und differenzieren uns über Kleidung. Wem es finanziell gut geht, zeigt es gerne über Kleidung!

Muss man pro Tag viele Entscheidungen treffen, sinkt auch die Entscheidungskraft entsprechend.

Die gewählte Tristheit hat jedoch einen cleveren Hintergrund: Zuckerberg beispielsweise möchte dadurch seine Energie für wichtigere Entscheidungen aufbewahren. Damit spielt er auf eine psychologische Theorie, das sogenannte „Descision Fatigue“ an. Der Theorie nach sinkt somit die Entscheidungskraft von Menschen, je mehr Entscheidungen Sie pro Tag treffen. Regenerationsphasen können die Entscheidungsfähigkeit wiederherstellen, und genauso können „Entscheidungs-Ressourcen“ durch Systeme eingespart werden.

Im Klartext heißt das: Besitzt man wenige Dinge, oder hat Systeme, die Entscheidungen vereinfachen, kann man mehr Konzentration / Energie / Fokus für Dinge aufwenden, die diese Aufmerksamkeit tatsächlich benötigen.

Automation!

Wer dennoch an seiner Garderobe hängt, kann bereits mit systematischen Arbeitsblöcken viel erreichen. Denn häufig (hintereinander) das Arbeitsmuster wechseln hat hohe Initialkosten und führt zu geistiger Ermüdung. Sprich: Wenn ich von Code, zu Telefonat, zu Meeting, zum Parkplatz und wieder zum Code springe, geht das alles zu Lasten der Arbeitsleistung.

Automation ist eines der Zauberworte. Geht man davon aus, dass die Summe unseres täglichen Handelns die Definition unserer Identität bildet (ein Programmierer programmiert, ein Bäcker backt), dann gilt: Du bist was du nicht bereits automatisiert hast. Will man Beispielsweise ein Bug-Hunter sein, oder dann doch lieber den Vorteil automatischer Software-Tests nutzen? Demnach haben Einstein, Jobs und Zuckerberg vor allem Ihren Kleiderschrank automatisiert.

Doch auch hier ist Vorsicht geboten: Je mehr Automaten man sich anschafft, desto schwieriger wird es an einem Punkt, sich um all diese Automaten zu kümmern.

Was du besitzt, besitzt am Ende dich

Was sich zunächst wie eine kommunistische Parole klingt, ist vor allem als eine Metapher zu verstehen. Was ich damit meine ist, dass je mehr Teile man einem System hinzufügt, umso mehr Teilen muss man langfristig Aufmerksamkeit schenken. Schon ein Teil alleine möchte gerne gepflegt werden. Der Pflegeaufwand steigt jedoch mit jedem Ding an.

Was nämlich oftmals außer Acht gelassen wird ist, dass Dinge neben einem Initialaufwand auch immer Folgeaufwände oder Risiken mitbringen. Nennen wir das Ganze der Einfachheit halber Bedürfnisse.

Die Verlockung, viele Dinge anzuhäufen, ist groß, da die Anschaffung meist mit einem geringen Initialaufwand verbunden ist.

Initialaufwände können finanzielle Aufwände sein. Auch einmalig anfallende Zusatz-Arbeit gehört dazu. Ein Auto ist schnell gekauft, doch muss es mindestens einmal transportiert werden. Anschließend versichert man es oder stellt es irgendwo gut unter (Initialaufwand). Wird es dann regelmäßig genutzt, braucht es Wartung und Benzin. Im Winter möchte es neue Reifen, Kühlflüssigkeit, Enteiser; und überhaupt möchte es eine regelmäßige Innen- und Außenpflege genießen. Andernfalls geht es kaputt und braucht spätestens dann einen Werkstattbesuch. Alles Folgeaufwand.

Vor allem der Folgeaufwand steigt oftmals proportional mit der Anzahl der Dinge, um die es geht. Während das bei Initialaufwand manchmal weniger wichtig ist, macht es bei den Folgeaufwänden schon einen Unterschied. Es mag immer noch wesentlich weniger aufwändig sein, 30 Autos auf einmal zu kaufen als dann 30 Autos „auf einmal“ zu pflegen.

Das ist quasi eine Gesetzmäßigkeit, die sich in allen Handlungen wiederfinden lässt, die Dinge einem Inventar oder Projekt hinzufügen; auch in der immateriellen Branche der Softwareentwicklung. Hier ist vor allem die Verlockung viele Dinge anzuhäufen relativ groß, da der Initialaufwand oftmals verlockend gering ist: Software und Betriebssysteme bekommt man im Internet nämlich ohne Geld dafür zu bezahlen.

Versteckte Folgeaufwände

Klassiker aus den Augen verlorener Folgeaufwände in der Softwareentwicklung sind beispielsweise:

  • Versionssprünge und Sicherheits-Updates von Libraries und Betriebssystemen
  • Spiegeln genutzter 3rd Party Libraries, um jederzeit Deployment-ready zu bleiben
  • Anfälligkeit eigenen Glue-/Framework-Codes, der ggf. regelmäßig auf externe Libraries angepasst werden muss
  • Daten-Backups, Failover, Error-Logging, Monitoring und Resilience selbst gehosteter Dienste
  • Kompatibilitäts-Management eigener Services untereinander
  • Schulung und Wissenstransfer innerhalb des Teams
  • Koordinierte Vertretungsplanung oder Erreichbarkeit bei Mitarbeiterausfällen

Wem also beispielsweise Betrieb und Erhalt einer Anwendung oder Services über den Kopf wachsen, der kann unter anderem:

  1. dafür sorgen, dass (API-) Services weniger kleinteilig werden. Dafür vielleicht immer noch einen sinnig geschnittenen SOA-Ansatz verfolgen.
  2. versuchen, sich auf wesentliche Kompetenzen zu konzentrieren und das Operating einzelner Dienste (Hosting, Mails, Monitoring) externen Anbietern überlassen.

Durch bewusste Entscheidung für schmale Lösungen und Strukturen entfallen zusätzliche Administration, Pflege oder Koordinierung. Somit frei gewordene Ressourcen (Zeit / Geld), können somit auf Dinge gelenkt werden, für die man als Entwickler / Arbeitgeber / Unternehmen wirklich von seinen Kunden bezahlt wird. Zugleich schafft man dennoch mehr seiner eigentlichen Arbeit.

Manchmal ist es in der Tat erst gar nicht so offensichtlich, welche der Entscheidungen den größeren Vorteil bringen. Dazu lohnt es sich durchaus, Beratungen zu konsultieren und einen extern geleitete Workshops abzuhalten.

tl;dr

Nochmal rückblickend: Was hat Ephemeralization in der IT-Branche mit Minimalismus zu tun? Je weniger Dinge man in einer Organisation selbst besitzt, desto mehr kann man sich auf das eigentliche Unternehmensziel konzentrieren. Trenne dich von Dingen, die nicht zu deinen Kompetenzen gehören. Wenn möglich, finde sinnvolle Gruppierungen von Dingen, die einen ähnlichen Folgeaufwand besitzen. Muss man wirklich einen eigenen Mailserver betreiben, nur, weil dieser scheinbar kostenlos ist? Muss das Ticketsystem wirklich selbst gehostet werden?

Oftmals lohnt es sich, Geld für Dienste zu bezahlen, weil die versteckten Folgeaufwände beim selbst machen übersehen werden. Auch hier mag es unter Umständen einen gewissen Schwellenwert geben, ab dem es wesentlich komplexer wird, externe Dienste zu organisieren als interne Wertschöpfung zu betreiben. Doch das verschieben wir mal auf einen späteren Breakpoint Wilson.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -