Thomas Much
Technical Agile Coach. Tech. People. Together.
Technical Agile Coach. Tech. People. Together.
Hamburg, Germany
Actions
Thomas works as a Technical Agile Coach at Techniker Krankenkasse in Hamburg. Together with his coaching colleagues, he supports teams in always getting a little bit better at collaboration and agile programming practices – by encouraging (and doing!) pair and team programming, TDD, test automation and the like. Over the years, Thomas has contributed to various software systems large and small, many of which had to and have to be maintained for many years, even decades.
Thomas ist Technical Agile Coach für die Techniker Krankenkasse in Hamburg. Zusammen mit seinen Coaching-Kolleg:innen unterstützt er Teams dabei, in der Zusammenarbeit und den agilen Programmierpraktiken immer besser zu werden – unter anderem durch die Förderung von Pair- und Team-Programming, TDD und Testautomatisierung.
Area of Expertise
Topics
Modern Software Development – Stand der Dinge 2024
In Büchern wie „Release it!“ und „Continuous Delivery“ war seit Ende der Nullerjahre – also seit 10, eher 15 Jahren – beschrieben, wie man Software zum Vorteil des Unternehmens und zum Nutzen der Kunden kontinuierlich und mit kontrolliertem Risiko ausliefern kann. Seit 2018 ist dies in „Accelerate“ mit wissenschaftlichem Unterbau publiziert, seit 2022 in „Modern Software Engineering“ auch auf technischer Ebene und aktuell für die 20er-Jahre dokumentiert.
Ist das in unseren Projekten alles schon Realität? Auf welche wesentlichen Aspekte sollten wir Wert legen? Welche Ideen aus den genannten Publikationen haben sich bewährt, was wurde im Laufe der Jahre an die sich ändernden technischen Möglichkeiten angepasst?
Anhand ausgewählter Kernfähigkeiten schauen wir uns an, was bei professioneller Softwareentwicklung heutzutage selbstverständlich sein sollte – und warum. Und an welchen Stellen es vielleicht auch im Jahre 2024 immer noch Schwierigkeiten gibt.
Dabei geht es vor allem um die technischen Grundlagen. Manches davon wirkt trivial. Anderes unerwartet. Und einige Augenöffner sind garantiert auch dabei!
Mocks, Fakes, Stubs – ist da ein Unterschied? Braucht man das noch?
Automatisierte Tests sind eine große Hilfe, wenn sie brauchbar schnell ausgeführt werden. Das geht meistens nur dann, wenn nicht immer die gesamte Anwendung getestet wird, sondern wenn man Teile davon ausblenden oder mit einem klar vorhersagbaren Verhalten simulieren kann. Dafür kommt üblicherweise "Mocking" zum Einsatz, egal ob bei Unit- oder bei Integrationstests.
Allerdings stehen "Mocks" zunehmend in der Kritik. Mock-Tests seien fragil und hätten einen hohen Wartungsaufwand – würden also eher stören als helfen. Andere dagegen halten Mocking nach wie vor für unverzichtbar. Wie soll man nun damit beim Schreiben neuer Tests umgehen? Braucht man Mocks überhaupt noch?
Meiner Erfahrung nach ist häufig nicht klar, was mit einem "Mock" gemeint ist. Denn es gibt unterschiedliche Arten von "Test Doubles", die alle nützlich und hilfreich sind – wenn sie passend eingesetzt werden. In dieser Grundlagen-Session geht es daher um die Klärung der Begriffe, die vor 15-20 Jahren durch die "xUnit Patterns" geprägt wurden.
Wir schauen uns mit ein paar Folien und viel Live-Coding die verschiedenen Arten von "Test Doubles" an und werden sehen, welche Auswirkungen das auf die Wartbarkeit bzw. Stabilität von Tests hat; gerade auch im Hinblick auf Änderungen im zu testenden Code. Dabei geht es nicht darum, ob eine Variante besser ist als die andere. Sondern darum, die Unterschiede zu kennen und jede Art passend einsetzen zu können. Am Ende gibt es noch einen kurzen Ausblick auf das neue Konzept der "Nullables", als Ergänzung und Weiterentwicklung der bekannten Patterns.
Fitness Functions for Your Architecture – in Practice
Fitness functions are an essential part of evolutionary architectures. But how do they look like in practice? What kinds of fitness do they check and assert? And can you leverage fitness functions in your architecture, that maybe you deem not even evolutionary?
After a brief introduction we'll do a deep dive into some concrete examples, covering use cases for common architectural styles. We'll see examples in Java code (yes, code!), based on ArchUnit and jMolecules. But the basic ideas and concepts are applicable to other languages and technologies as well. Don't be afraid of the code – the simple examples are more about general structure and not about code details. There'll be accompanying, easy to understand diagrams for each example. This way, you'll get tangible, practical insights into fitness functions.
The session closes with a short discussion about when and where to write fitness functions and who should write them. And we'll see why this enables agility and continuous thinking about architecture in your software development teams. All these aspects will be easier to grasp once you've seen concrete examples.
Einfach gut testbar – Die Grundlagen von Code-Design und Architektur für gute Testbarkeit
Manche Softwareentwicklungsteams sind agiler als andere, aus den unterschiedlichsten Gründen. Bei meiner Arbeit mit zahlreichen Teams habe ich während der letzten Dekade ein wiederkehrendes Muster beobachtet: Teams mit guter, schneller Testautomatisierung liefern oftmals bessere Lösungen kontinuierlicher ab – und besitzen dabei auch noch einen besseren Team-Spirit. Aber warum erreiche manche Teams eine gute Testautomatisierung, während sich andere damit über Jahre abmühen?
Meiner Erfahrung nach hängt dies davon ab, ob der Code einfach testbar ist. Oft denkt man dann sofort an Programmierpraktiken wie Test-Driven Development (TDD), durch die ein besseres – besser testbares! – Code-Design entsteht. Aber es gibt auch einige Architekturstile bzw. -muster, die ein einfacheres Testen mit schnelleren Feedback-Schleifen ermöglichen.
Wir schauen uns in dieser Session an, was es bedeutet, Geschäftslogik von Integrationscode zu trennen, welche unterschiedlichen Code-Designs und Architekturmuster es gibt, um dieses Ziel zu erreichen – und warum damit kleinere und schnellere automatisierte Tests möglich sind.
Es geht dabei um die absoluten Grundlagen von testbarem Code und testbarer Architektur. Wer sich nicht täglich mit diesen Themen beschäftigt, wird Anregungen und Tipps bekommen, wie man sofort morgen im eigenen Projekt die ersten Verbesserungen vornehmen kann. Die Session wird eine ausgewogene Mischung sein aus Folien und Live-Coding.
Einfach gute Tests
Vorträge drehen sich meist um neue Tools und Bibliotheken. Das ist gut und wichtig, damit wir nicht stehenbleiben. Aber was ist mit den Grundlagen, die zu diesen Neuentwicklungen geführt haben? Gerade beim Thema "Testautomatisierung" ist mir aufgefallen, dass Neu- und Quereinsteiger:innen oft das vorhandene (gute oder schlechte) Testvorgehen hinnehmen, nachahmen und zu wenig hinterfragen.
In dieser Live-Coding-Session schauen wir uns daher folgende Fragen an: Wie strukturiere ich meine Tests? Wie mache ich meine Tests lesbar, verständlich und wartbar? Wie teste ich etwas, das noch gar nicht da ist? Und wie hilft mir das alles für einfache Design-Refactorings? Ideologie lassen wir außen vor. Ich möchte Erfahrungen aus der Praxis zeigen, natürlich mit ein paar Anleihen aus TDD, Clean Code und auch vom Domain Driven Design.
Test-Profis werden nicht viel Neues entdecken. Aber wer sich beim Schreiben von Tests unsicher fühlt, bekommt pragmatische, praxiserprobte Anregungen. Damit die Tests uns im Entwicklungsteam unterstützen und nicht nur den Chef durch das Erfüllen irgendeiner Testabdeckungs-Metrik zufriedenstellen.
Wir schauen uns vor allem Unit-Tests in Java an, die Ideen können aber auf andere Testarten und Programmiersprachen übertragen werden. Neben viel Live-Coding gibt es ein paar wenige, einleitende Slides.
How Testability Supports Your Agility
... or the other way around: If your code and architecture aren't designed for testability, there easily might arise problems in your agile, continuous workflow. So it might help to know some patterns and anti-patterns regarding testability, even as someone who isn't deeply into coding – you will be able to ask your teams suitable questions to help them find better testable implementations.
So much for the TL'DR, here's the longer story:
Some software development teams are more agile than others, for a number of reasons. While working with many teams during the last decade, I observed a recurring pattern: Teams (and products) with good, fast testautomation often deliver better solutions sooner, while keeping a better team spirit – a combination that many agile coaches wish for their teams. But how do some teams achieve good testautomation, while others struggle for years?
In my experience, this depends on if the code is easily testable or not. You might know programming practices like test-driven development (TDD) which yield better designed - testable - code. But there are some architectural patterns as well that support easier testing with fast-feedback loops.
We'll have a look at what it means to separate business logic from integration code and what different architectural styles and patterns exist to reach this goal - and why this enables smaller and faster automated tests. To keep this broad topic as comprehensible as possible, you'll see simplified visualizations of the different architectural styles and code designs.
The goal of this session is that you get a basic understanding what distinguishes testable architectures and code designs from less testable ones. And why testability is a fundamental building block that enables true - continuous - agility.
Simply Good Tests – A Practical Approach
You're constantly learning new tools and technologies. That's important since this is the foundation of our progress. But what about the old (probably still valid) ideas behind new developments? Especially when it comes to test automation, I noticed that newcomers often accept existing procedures, copy them and question them too little. So I prepared this talk to share some of the old ideas.
We'll consider the following questions: How do I structure my tests? How do I make my tests readable, understandable and maintainable? How do I test something that isn't there yet? And how does all of this support easy design refactorings? We'll see basic, pragmatic, good practices – and of course we'll borrow some ideas from TDD, Clean Code and even a little bit from Domain Driven Design.
Testing professionals won't discover much new. But if you're unsure about writing tests, you'll get tried and tested suggestions. For tests that support our team and our software development – and not just fulfil some test coverage metric.
The session will be mostly live coding, with only a few introductory slides. We'll cover unit tests in Java, but the underlying ideas can easily be transferred to other test types and programming languages.
Mob-Programming. Zusammen lernen. Zusammen liefern!
Wenn man die Ideen von Lean, Agile, XP etc. ernst nimmt, müsste man alles daran setzen, seine Aufgaben zu priorisieren und die wichtigste Aufgabe möglichst zügig und gut zum Kunden auszuliefern. Leider sieht die Realität oft anders aus: Die individuelle Auslastung wird maximiert, die Entwickler arbeiten an vielen Aufgaben gleichzeitig. Die Features landen halbgar beim Kunden, die Entwickler müssen ständig Bugs fixen und für fachliche Weiterentwicklung fehlt leider die Zeit.
Als Lösung dieses Problems setzen wir auf Team-Building, arbeiten an der Kommunikation, machen Pair Programming, suchen Collective Code Ownership. In Zeiten von zunehmend komplexen Problemen ist das vielleicht nicht mehr genug - weil die Teams nicht nur das Ergebnis gemeinsam verstehen müssen, sondern auch den Weg der Problemlösung.
Vor einigen Jahren kam die Idee auf, Softwareentwicklung wirklich durch das gesamte Team durchführen zu lassen - und zwar zusammen, Aufgabe für Aufgabe. "Mob Programming" war geboren. Die Blockaden während der Entwicklung verschwinden, weil sich alle nötigen technischen und fachlichen Ansprechpartner im selben Raum befinden. Klingt verrückt? Funktioniert aber!
In diesem Talk werde ich die Grundlagen von Mob Programming vorstellen, die Gemeinsamkeiten und Unterschiede zum Pair Programming und wann sich das Arbeiten als "Mob" lohnt. Dazu gibt es Tipps aus der Praxis.
Agile ist tot. Lang lebe Modern Agile!
Agile ist erwachsen geworden: Vor über 18 Jahren wurde das Manifest für Agile Softwareentwicklung veröffentlicht. Mittlerweile ist Agilität im Mainstream angekommen. Doch oft fühlt sich das nicht besser an - es geht wieder um Prozesse, Geschwindigkeit und Kontrolle. Dabei wollte das Agile Manifest doch etwas ganz anderes.
Die Prinzipien und Werte, die hinter erfolgreicher Agilität stecken, sind so wichtig wie nie zuvor. Kunden erwarten zügig neue Features, die sie von der Konkurrenz kennen. Gleichzeitig muss die Qualität stimmen. Entwickler findet man nicht mehr wie Sand am Meer - und sie haben keine Lust auf unnötige Bürokratie, suchen einen Sinn in ihrer Arbeit und möchten dabei nicht ausbrennen.
Bekannte Agilisten haben sich vor einiger Zeit daran gemacht, die Agilität mit ihren eigenen Methoden weiterzuentwickeln: Ausprobieren und lernen. Alte Zöpfe abschneiden, Neues versuchen. Und an guten Ideen festhalten. Herausgekommen sind Bewegungen wie "Heart of Agile" und "Modern Agile".
Wir machen eine Bestandsaufnahme, wo Agile heute steht. Vor allem schauen wir uns die vier Prinzipien von "Modern Agile" an, warum gerade sie den Weg in die agile Zukunft ebnen. Dieser Vortrag liefert Anregungen und Impulse zur Bewertung des eigenen agilen Vorgehens - und zur Orientierung, wenn jemand gerade vor der Einführung von Agilität im eigenen Unternehmen steht.
ArchUnit: Testen von Architektur und Design
In den meisten Projekten gibt es irgendwo eine Dokumentation der Architektur und der Code-Conventions. Die Frage ist nur: Wo? Und sind die Beschreibungen aktuell? Hält sich der Code wirklich daran? In der Praxis ist solche Dokumentation leider allzu häufig "write-only" und hat mit der Realität nur noch entfernt zu tun.
Viel schöner wäre es doch, wenn die Vorgaben automatisiert geprüft werden könnten. Beispielsweise in Form von Unit-Tests, die von den Entwicklern zusammen mit der Anwendung gepflegt und angepasst werden, als Teil einer "Living Documentation".
Mit der Java-Bibliothek "ArchUnit" können die typischen Architekturvorgaben mit einer Fluent-API als Regeln definiert und z.B. in JUnit getestet werden. Dazu gehören Schichten und fachliche Schnitte, deren erlaubte und verbotene Abhängigkeiten sowie Zyklenfreiheit. Außerdem können Code-Conventions wie Namen von Elementen, die Zuordnung von Klassen zu Packages und die Verwendung von Annotationen und Exceptions geprüft werden.
Bestehende Regeln können so nicht nur mit Unit-Tests festgezurrt werden, es können auch Ausnahmen definiert werden. Vorhandener Code kann so nach und nach an die Vorgaben angepasst werden, z.B. als Vorbereitung einer Modularisierung - und das auch mit älteren Java-Versionen.
Neben der allgemeinen Vorstellung von ArchUnit bietet dieser Vortrag Tipps aus der Praxis - inkl. Live-Coding.
Mob Programming: Learn Together. Deliver Together!
Mob Programming is a way of truly collaborating for whole teams. But - why should we care? We are a team already, aren't we? Well ... Our aim with software development is to deliver the most important feature quickly and in good quality to our customers. Reality looks different, though: Individual workload is maximized, the developers work on too many tasks at the same time. Half-baked features annoy our customers. Developers are fixing bugs around the clock, there's just no time for feature development.
Some years ago, the idea arose of having the entire team carry out software development - together, task by task. "Mob Programming" was born. Blockages during development disappear because all the necessary specialists are in the same room. And if that room is a virtual one, this practice becomes Remote Mob Programming - quite important these days for distributed teams or when working from home.
In this talk I'll show the basics of (remote) mob programming. We'll discuss when working as a "mob" pays off. And I will offer insights and good practices from almost four years of programming "mob style" (and coaching it to various teams in all kinds of companies).
ArchUnit - Unit Testing Architecture and Design
Most projects probably have some kind of documentation of the architecture and code conventions. It's just a question of: Where? And are these documentations up to date? Does the code really adhere to these standards? In the field, documentation is all to often "write-only" and bears only faint resemblance to reality.
Wouldn't it be nice if your architectural and coding rules were checked automatically, as part of your continuous integration build? And if architecture wasn't just an occupation of some distant architect, but rather a team sport for all developers, like in an agile, cross-functional team?
With "ArchUnit" it's possible to code your architectural decisions as plain Java (or Kotlin) rules, using an easy to read fluent API. These rules can check for layered architectures, vertical slices, hexagonal (onion style) architectures, acyclic package dependencies, and for coding conventions like namings, containment of classes in packages and the use of annotations and exceptions. The rules can be checked by any unit testing framework, as for instance JUnit.
You'll see the basics of ArchUnit along with practical tips and tricks, including how to write custom rules. There will be some slides, but mostly live coding.
Agile meets Architecture 2023 Sessionize Event
Java Forum Nord 2023 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top