The One Thing You Need to Know … About Software Development
„Korrektheit kann zu jedem Zeitpunkt bestätigt werden“ ist der Untertitel von Marys Keynote und er startete mit einem klaren Statement, dass „Wasserfall“ einfach nicht funktioniert. Also, dann mal hören, was funktioniert 🙂
Die Frage ist, wie man mit der Komplexität umgeht, und die Antwort ist zu einem gewissen Grad „Teile und Herrsche“. Es folgten ein paar geschichtliche Hinweise, wie das zu erreichen sei. In den 70er-Jahren war alles „Strukturiert“ (Strukturiertes Design, Strukturierte Maintenance, etc), aber das hat das Problem nicht wirklich lösen können, wie wir heute wissen. Was wir wirklich wollen, ist das man gar nicht erst anfängt, die Probleme zu injezieren. Eine frühe Antwort darauf kam von Edsger Disjkstra in der Form einer mehrschichtigen Architektur, jede Schicht ist eine virtuelle Maschine zu der darüberliegenden Schicht.
Nach langen Diskussionen über Architektur mit Tom Gilb gestern Abend in der Hotel-Lobby, zittern meine Finger ein wenig, wenn ich hier über Architektur schreibe 🙂 … aber zurück zu Mary. Die Frage ist, wie Software auf den verschiedenen Ebenen funktioniert; z.B. Unit Testing und Business Level Testing.
Der nächste in der geschichtlichen Abfolge ist Harlan Mills mit dem Ansatz des Top-Down-Programming, der helfen sollte die Schwierigkeiten bei der Integration zu verhindern. Es ist eine Schrittweise integration, die als eine frühe Version von Continuous Integration angesehen werden kann, welche wir heutzutage diskutieren. Zusammengenommen mit der Diskussion mit Tom Gilb gestern abend sieht es so aus, als ob einige agilen Ideen nicht sooo neu sind.
Nächster ist Dave Parnas und seine „Kriterien zur Dekomposition“. Das erinnert mich daran, was Rom gestern gesagt hat, dass viele Architekten in Wahrheit nur Dekomposition betreiben, und keine Architektur, aber das ist schon wieder eine andere Geschichte. Die Idee ist, das Programm aufzuteilen, um zukünftige Änderungen einfacher durchführen zu können … das kommt dem Nahe, was Uwe anpreist: „Architektur, um Maintenance zu unterstützen“ (Sorry Uwe, falls das zu sehr verkürzt ist). Oh, sorry, ich muss zugeben, dass ich zu langsam war, um mit der geschichtlichen Betrachtung mitzuhalten, aber wir werden aufholen (Ab jetzt werden Andreas und ich am Blog post pairen, sehr cool).
1976 wurde festgestellt, dass das Hauptplroblem in der Softwareentwicklung die Wartungskosten (schon wieder!) sind und die Lösung zu dem Problem ist natürlich die Fehler zu früh wie möglich zu finden. Und dafür braucht man kürzere Entwicklungszyklen, als man mit dem Wasserfallprozess bekommen kann.
1981 betritt Tom Gilb die Szene mit dem Konzept ein System mit einer kurzen Zusammenfassung von messbaren Geschäftszielen anzufangen. Diese müssen unmissverständlich und testbar sein, und dürfen kein Design vorwergnehmen (das ist ja Aufgabe der Architekten). Hmm, das hört sich sehr vertraut an, das war der Kernpunkt seiner Keynote gestern. Es ist immer hilfreich diese Kreuzzusammenhänge zu sehen. Also zurück zu
„Prevent defects injection in the first place!“
Wie lernt man denn die Fehler nicht zu injizieren? Ok, was ist ein „Defect Injection Process“? Er fängt mit einer Spezifikation an, und ein Team schreibt den Code und ein anderes Team schreibt die Tests. Sorry, aber das passt am Ende einfach nicht zusammen, wir haben einen „Defect Injection Process“. Nächste Idee: Kombiniere das Schreiben der Tests zusammen mit der Spezifikation und schreibe dann den Code, um die Erwartungen des Tests zu erfüllen.
Zurück zur Komplexitätsbewältigung und der Frage wie man mit der Komplexität umgeht. Die Antwort ist nicht (nur) „Teile und Herrsche“ sondern „Teile entlang Verantwortlichkeiten und Werten“ (auch etwas, was Uwe uns immer wieder predigt, vertikale Teilung statt horizontaler). Dies hat sich zu den drei Regeln schlanker (lean) Entwicklung fortgesetzt:
- Design macht einen Unterschied
- Korrektheit kann zu jedem Zeitpunkt bestätigt werden
- Fehler sind eine Möglichkeit, um daraus zu Lernen
Mary führt einige high-level Beispiele an, wie man ein System entwickeln kann. Natürlich macht sie ein paar Bonuspunkte, weil sie das iPhone als gutes Beispiel für ein solches, gutes allumfassendes Systemdesign.
Jetzt wird es wieder konkreter und die Frage ist wie viel Zeit eines Release-Zyklus dafür benutzt wird Fehler zu finden und zu beheben (System hardening). Die Antwort ist, dass die besten Unternehmen höchstens 10% dafür aufwenden, während andere dafür bis zu 50% aufwenden. Aber das Ziel kann nicht sein, so viel wertvoller Entwicklungszeit darauf zu verwenden, also muss man die Fehler schon früher im Prozess finden. Und damit kommt Mary zurück zum Thema die Korrektheit zu jedem Zeitpunkt bestätigen zu können, und nicht erst am Ende des Release-Zyklus.
“No correlation between size of the code base and bug rate: Complexity handled completely.” (from an example developing an embedded system)
Jetzt wird es Agil: wir haben kurze und stabile iterationen. Und die Interessenten (Stakeholder) bekommen und geben Feedback in jeder Iteration. Und es wären nicht die „Agile Testing Days“ ohne ein gutes Beispiel wie automatisierte Unit Tests der IBM zu einem sehr erfolgreichen Projekt bei der Einführung von Agilität geholfen hätten. Hört sich an wie Continuous Integration und frühes automatisiertes Testen, auch ohne FitNesse und Robot.
“People do not want software, they want something else.”
Grundsätzlich wollen Kunden ihre höchstprioren Ziele umgesetzt sehen, und damit deren Probleme gelöst bekommen. Mary bewirbt TDD um das zu erreichen:
“The biggest defect is tolerating defects.”
Mary betont, dass man aus Fehlern lernen muss, weil sie fehlendes Verständnis andeuten. Es ist immer eine Gelegenheit zu Lernen. Trotzdem, in einem sehr disziplinierten Programm entwischen nur einige, wenige Fehler.
Ok, da wir hier ja über „lean“ sprechen kommen natürlich noch ein paar Beispiele von Toyota :). Mary beschreibt wie Toyota von der aktuellen Situation ihrer Vision näher kommen. Dazu muss mit jedem Schritt ein Hinderniss überwunden werden, also mit jedem Schritt näher zu Vision gelern werden.
Zusammenfassend (sagt Andreas), vieles davon wurde auch schon in dem Tutorial am Montag besprochen, aber was war gut, dass nochmal verdichten in Erinnerung gerufen zu bekommen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Thomas Jaspers
22.2.2019 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Thomas Jaspers
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.