themen

themen

Meine Erkenntnisse aus der Analyse von Konzepten/Methoden der Softwareentwicklung versuche ich mit ganz anderen Begriffen zu verknüpfen, um zu noch besseren Ansätzen zu kommen. Wir können in der Softwareentwicklung viel von anderen Disziplinen lernen. Theory of Constraints, Konstruktivismus, Soziokratie, Suchtprävention, Psychotherapie uvm. können uns Impulse geben, um unsere Arbeit noch besser, noch leichter zu machen.

Auch wenn ich also Begriffe aus aktuellen Strömungen der Softwareentwicklung benutze, bemühe ich mich stets um Offenheit. Meine Arbeitsweise ist insofern eklektisch: Ich füge zusammen, was mir hier und dort und da nützlich erscheint. Weniger Dogma, mehr Lernen, mehr Experiment – das ist es, was wir brauchen, um immer besser zu werden.

The Architect's Napkin

So arbeite ich aus Überzeugung. Mehr als drei Jahrzehnte Erfahrung in der Softwareentwicklung haben mich gelehrt, dass nichts wichtiger ist, als der stetige Wille zum Lernen. Das bedeutet nicht, im Theoretisieren steckenzubleiben. Im Gegenteil: Lernen braucht Handlung. Deliberate practice: Praxis, die sich reflektiert und dann den weiteren Weg immer wieder neu bestimmt.

Hersteller wie Microsoft, Oracle, Apple, OMG lösen unsere Probleme nicht. Auch der Hype du jour wie OOP, C++, Java, CORBA, UML, Agilität, XP, Scrum, Lean, Kanban, NoSql, CQRS, Funktionale Programmierung usw. usf. bringt keine Rettung. Das alles sind nur Angebote. Aus denen müssen wir auswählen. Aber wie?

Es hilft nur beobachten, ausprobieren, analysieren, synthetisieren – und dann wieder von vorn zu beginnen. Sobald wir damit aufhören und meinen, endlich, endlich angekommen zu sein… entstehen systemrelevante Größen, kommt es zur Bildung von monolithischen Strukturen. Dann wird es immer schwerer, auf Veränderungen zu reagieren. Und die klopfen garantiert an die Tür.

Deshalb ist mir an den Hintergründen so gelegen. Deshalb hänge ich nicht an einem Begriff, Ansatz, Werkzeug.

Leichtgewichtiger Softwareentwurf

Ich habe keine Lösungen in der Tasche. Aber ich bin sicher, dass ich Ihnen wertvolle Impulse geben kann, um Softwareproduktion von der Anforderungsanalyse bis zur Auslieferung des Codes einmal anders zu versuchen. Denn wenn es heute bei Ihnen nicht so flüssig laufen sollte, wie Sie es sich wünschen, dann ist eines klar: Irgendetwas muss anders werden. Mit den selben Rezepten wie bisher ist eine Besserung kaum zu erwarten.

Aber wo ansetzen? Was verändern? Wir brauchen mehr Systematik. Dazu habe ich auf der Basis bekannter Ansätze und Begriffe viele Ideen entwickelt, die Antworten auf Fragen wie diese näherrücken:

  • Wie können Sie systematisch von Anforderungen zu Code kommen?
  • Wie können Sie systematisch dafür sorgen, dass Code über die Zeit wandelbar bleibt, d.h. die Softwareproduktion zukunftsfähig ist?
  • Wie können Sie systematisch Architekturstrukturen aus nicht-funktionalen Anforderungen ableiten?
  • Wie können Sie systematisch Nutzen für den Kunden ohne Verschwendung herstellen?
  • Wie können Sie systematisch im Team zusammenarbeiten?

Softwarezellenarchitektur

Working smart, not hard. Softwareentwicklung muss sich von einer Kunst von Individuen zu einer systematischen Teamdisziplin entwickeln. Deshalb habe ich mit Kollege Stefan Lieser z.B. auch die Clean Code Developer Initiative gegründet. Sie systematisiert Prinzipien und Praktiken für zukunftsfähige Codierung.

Auf diesem Weg sind allerdings noch einige Mythen zu enttarnen und heilige Kühe zu schlachten. Die wiederkehrende und leitende Frage für mich lautet daher „Warum?“ Warum soll etwas so oder anders gemacht werden? Was ist der Nutzen? Was ist vor allem am Ende der Nutzen für Ihre Kunden? Denn auf handfesten Nutzen für Ihre Kunden muss sich alles zurückführen lassen, was wir in der Softwareentwicklung tun.