Katas sind bekannt als Übungen aus den fernöstlichen Kampfkünsten, die dem Trainierenden helfen, sein Geschick zu verfeinern. Dies gilt gleichermaßen für Schüler wie auch für Meister. Katas sind keine Trainingseinheiten für Würfe und auch keine Aufwärmübungen, sondern einfache Balancier-, Bewegungs- und Geschicklichkeitsübungen. Sie folgen der Idee, dass nur Geschick und Ausdauer die Grundlage für eine erfolgreiche Ausübung der eigentlichen Sportarten bilden.

Ähnliche „Trainingseinheiten“ beobachten wir auch bei Handwerkern: diese benutzen ihre Werkzeuge neben der Arbeit für kleine Fingerübungen. Manchmal entsteht dabei auch kein Erzeugnis, sondern nur ein Rohling. Aber ein Tischler wird sich seine Möbel eher in der eigenen Werkstatt selbst anfertigen, als sie irgendwo zu kaufen, und ein KFZ-Mechaniker repariert sein eigenes Fahrzeug wahrscheinlich auch eher selbst. Durch ständige Übung verbessert sich nämlich das handwerkliche Geschick, was der Ausübung des Berufes zugute kommt.

Im weitesten Sinne trainiert auch der Softwareentwickler, der zu Hause nebenbei private Projekte programmiert, seine Fähigkeiten. Womit wir über den Handwerker den Bogen zum Software Craftsman geschlagen hätten.

Coding Katas als Fingerübungen

Eine Form der Fingerübungen für Softwareentwickler sind Coding Katas, kleine Programmieraufgaben, bei denen es darum geht, in einer Timebox von beispielsweise einer Stunde einen kleinen Roboter oder ein Spiel wie Tetris zu programmieren. Es geht nicht ums Abschließen der Aufgabe oder um besonders originelle Lösungen, sondern darum, sich am Beispiel von kleinen, spannenden Aufgaben an Entwürfen zu versuchen und dabei Kenntnisse und Lösungskompetenz zu schärfen. Wer schon einmal ein Schachspiel programmiert hat, weiß, dass allein die Modellierung der Figuren eine ganze Menge von Entscheidungen erfordert. Viele von uns werden sich dabei an die Aufgaben erinnert fühlen, mit denen sie in jungen Jahren ihre Faszination für die Programmierung entdeckt haben.

Trainingssession in Hammerbrook

Coding Katas gibt es in vielen Varianten: mal testgetrieben, mal ohne Tests, für Java, Scala, PHP und viele andere Sprachen. Daneben gibt es noch andere Varianten von Katas, beispielsweise Testkatas oder Architekturkatas. Am 17.06. trafen sich in der Hamburger City Süd bei Innogames 18 Software Craftsmen, um letztere Variante bei Pizza und kalten Getränken zu exerzieren. Das Besondere dabei: es wurde nicht programmiert. Pen & Paper war die Devise, die Laptops blieben zugeklappt.

Es durfte diskutiert werden

Architekturentwürfe beschäftigen sich nämlich mit Fragestellungen auf der Metaebene. Und das ist auch der Sinn der Sache, denn vor dem Programmieren gilt es meistens, die Rahmenbedingungen zu klären.

In Vierergruppen wurde sich also nach Feierabend in zwei Timeboxes zu jeweils 30 Minuten an Architekturentwürfen versucht. Die Gruppen waren bunt zusammengewürfelt und die meisten Teilnehmer kannten sich vorher nicht, so dass auch die soziale Komponente gegeben war.

Projekt: 1-800-AMI-SICK

In der ersten Übung sollten die Software Craftsmen eine Callcenterlösung entwerfen, bei der Patienten Krankenschwestern anrufen können und sich Rat zu individuellen Beschwerden holen können. Die Telefonschwestern sind dabei weltweit verteilt, haben Zugriff auf eine externe elektronische Krankenakte und können den Patienten an einen Arzt weitervermitteln. Die entworfenen Lösungsbeschreibungen fielen sehr unterschiedlich aus, von eher technischen Betrachtungen der erforderlichen Systeme und Schnittstellen bis zu umfangreichen Analysen der Stakeholder und der Fachdomäne war alles dabei, was wahrscheinlich auch der bewusst offen gehaltenen Anforderung des Product Owners geschuldet war. Einzelne Gruppen vergaßen auch Anforderungen oder Stakeholder in ihrem Entwurf. Das Ganze wurde abgerundet durch Vorstellung der Lösungen vor Publikum und eine Feedbackrunde.

Vorstellung einer Lösung

Projekt: FoodHero

Nach einer kurzen Pause ging es in die zweite Runde. Die nächste Aufgabe sah vor, einen Vermittlungsservice für Pizzalieferdienste zu entwerfen. Der Kunde soll hier in einer Portallösung auf Essenslieferdienste in seiner Umgebung zugreifen und Menüs bestellen können. Die interessanten Fragestellungen waren dabei die Schnittstellen zu den beteiligten Akteuren und die anschließende technologische Realisierung.

Der Product Owner hatte die Frage dieses Mal deutlich geschlossener formuliert: er wollte konkret wissen, welche Spezialisten man einstellen müsse, um das Produkt zu entwickeln. Um so mehr beschäftigten sich die jetzt vorgestellten Lösungen jetzt noch stärker mit „weichen“ Faktoren wie der Analyse des Umfeldes, so dass einige Gruppen die eingangs gestellte Frage nicht wirklich beantworten konnten. Ein gelungenes Beispiel dafür, dass Kunde und Entwicklungsteam nicht immer die gleiche Sprache sprechen. Um so wichtiger ist es, dies in einer lockeren Atmosphäre zu simulieren, im Kontakt mit einem echten Kunden hätte man nun ein Problem gehabt. Es fiel übrigens auf, dass, obwohl wir über große Benutzerzahlen gesprochen haben, Themen wie Performance und Security eher am Rande diskutiert wurden, diese scheinen erst dann ins Spiel zu kommen, wenn die grundlegende Architektur bereits fest steht.

Es hat Spaß gemacht

Insgesamt war es ein sehr kommunikativer und spannender Prozess, bei dem wir herausfinden konnten, dass eine Architektur eben nicht nur aus den drei Schichten Model, View und Controller sowie ein paar aktuellen Technologien besteht, sondern dass eine Menge Constraints zu beachten und Entscheidungen zu fällen sind. Es handelt sich um einen mehrstufigen Prozess, der eine intensive Beschäftigung mit der Fachlichkeit und Kommunikation mit allen Beteiligten erfordert. Kurz: eine Softwarearchitektur lässt sich nicht in einer halben Stunde entwerfen.

Ich persönlich hätte neben den Komponenten- und Akteurssichten auch gerne über Risiken und Herausforderungen der fachlichen Lösungen gesprochen, aber es hätte den Rahmen wohl gesprengt. Dies daher nur als Anregung für die nächste Veranstaltung dieser Art.

Kommen wir zum Schluss

Denjenigen, die in das Thema tiefer einsteigen möchten, sei das Buch „Effektive Softwarearchitekturen“ von Gernot Starke empfohlen.

… und natürlich der Besuch der nächsten Softwerkskammer-Veranstaltung: http://www.meetup.com/sokahh/

Die beste Begründung für eine Entscheidung war übrigens: „Warum habt Ihr euch für PhoneGap entschieden?“ – „Ehrlich gesagt weiß ich das nicht. Derjenige, der das unbedingt wollte, ist schon nach Hause gefahren“ – Wer kennt das nicht? …. In diesem Sinne: noch frohes Schaffen!