Schlagwort-Archive: konferenz

5 Fallen in der Softwareentwicklung

Mit einer sehr eindrucksvollen Keynote hat Dr. Carola Lilienthal das derzeitige Software Architecture Summit in Berlin eröffnet. In ihrem Vortrag nannte sie einige Fallen, in die die Softwareentwicklung immmer wieder gerät. Dieser Artikel beschreibt meine Top 5 Fallen sowie meine persönlichen Erfahrungen dazu.

1. Das Modell-Monopol

Die Entwicklung benutzt Modelle, die der Kunde bzw. der Anwender nicht versteht. Problem dabei ist, dass damit Feedback vom Kunden über das Modell praktisch unmöglich ist. Als Lösungsmöglichkeit wurde Domainstorytelling genannt.

Obwohl ich Lösungen sehr oft zusammen mit Kunden und Anwendern entwickle, kann ich hier vermutlich noch viel lernen. Gerade das Thema
Ubiquitous Language
und Domainstorytelling sind mir zwar bekannt, ich wende sie aber noch zu wenig in Kundenprojekten an. Meist werden Modelle relativ informell entwickelt – dieses Wissen z. B. in ein Glossar zu überführen würde wahrscheinlich nochmal ordentlich Klarheit schaffen.

2. Die Soll Falle

Man Fokusiert sich viel zu schnell darauf, was der SOLL-Zustand sein soll, nachdem die neue Anwendung eingeführt ist. Dabei vergisst man, erst einmal genau zu analysieren, was der IST-Zustand ist.

Dies ist meiner Erfahrung nach eine Falle, in die sowohl Kunden, als auch Entwickler sehr oft geraten. Wenn ich an ein neues Projekt herangehe, versuche ich deshalb immer zuerst zu verstehen, wie der Kunde derzeit arbeitet und wo der wirkliche Bedarf liegt. In den seltensten Fällen möchte der Kunde eine Software, nein er möchte vielmehr eine Lösung für ein Problem (siehe auch Nobody wants to use software).

3. Zu starker Fokus auf Wiederverwendung

Man fokusiert sich beim Design von Komponenten darauf, dass diese Komponente auf jeden Fall wiederverwendet werden kann. Das führt zu generischen Lösungen, die für die eigentliche Problemstellung zu kompliziert sind. Besser ist es, einfache Lösungen, die konkret auf das eine Problem zugeschnitten sind, zu bauen.

Oft hat man im Unternehmen bestimmte Bibliotheken oder sogar ganze Plattformen, die oft benötigten Code bündeln. Problem dabei ist, dass diese meist erweitert/geändert werden müssen um ins aktuelle Projekt zu „passen“. Oft werden diese Bibliotheken von externen Teams betreut, die z. B. andere Releasezyklen haben als das eigene Team. Somit hat man sich durch den Fokus auf Wiederverwendung eine zusätzliche externe Abhängigkeit geschaffen.

4. Fokus auf einzelne Komponenten

Einzelne Komponenten werden Komplett „fertig“ gebaut, während das Gesamtsystem aus dem Blick gerät. Werden die Komponenten dann (relativ spät im Projekt) zusammengefügt ergeben sich oft Probleme durch unterschiedliche Schnittstellen oder inkompatible Konzepte.

Ich sehe hier sogar noch ein weiteres Problem: sehr spätes Anwenderfeedback. Fertigt man eine Komponente nach der anderen, so hat man sehr spät eine erste lauffähige Version und kann sich somit sehr spät Feedback einholen. Die Lösung sind hier Durchstiche oder sog. „Minimum Viable Products“. D. h. man beschränkt sich auf das absolute Minimum an Features die dem Anwender einen Mehrwert bringen, entwickelt die als Durchstich und liefert diese aus. Ich kann aus eigener Erfahrung bestätigen, dass Kunden begeistert sind wenn sie bereits nach 2 Wochen eine erste funktionierende Version mit minimalem Featureset bekommen.

5. Die Expertenfalle

Die Entwickler sehen sich als die wahren Domänenexperten und reden nicht mit dem Anwender. Dies führt dazu dass die Entwickler nicht wissen, wie der Anwender mit ihrer Software arbeitet und die Anwendung am Bedarf vorbei entwickelt wird.

Hier stimme ich voll zu. Anwender benutzen die Software oft ganz anders, als man es sich als Entwickler vorstellt. Deshalb ist es essentiell, von Anfang an Kontakt zum Anwender zu haben. In einem Beratungsprojekt lieferte ich einmal eine Version meiner Software aus und begleitete anschließend einen Anwender durch seinen Arbeitstag. Die meiste Zeit schaute ich ihm einfach über die Schulter um herauszufinden, wie unsere neue Lösung seine Arbeitsprozesse beeinflusst. Dabei stellte sich heraus, dass durch die suboptimale Sortierung der Felder eines Eingeabeformulars immer wieder Fehler passieren – solche Details stehen in keinem Anforderungsdokument.

Fazit

In einem komplexen Projekt lauern Fallen an jeder Ecke. Wichtig ist dabei, regelmäßig zu reflektieren um diese Fallen zu erkennen. Ich denke nicht, dass es sich verhindern lässt in die eine oder andere (unbekannte) Falle zu tappen. Wichtig ist aber, diese Falle im nachhinein zu erkennen und daraus zu lernen sowie seine Erfahrung zu teilen, damit andere nicht auch in diese Falle geraten.

Resümee zur Clean Code Days Konferenz

In der vergangenen Woche war ich zum ersten mal auf den Clean Code Days in München.

Workshoptag

Los ging es am ersten Tag mit einem Workshop zum Thema „Testgetriebene Analyse von Legacy Code“, den ich zusammen mit einem Kollegen hielt. Die Teilnehmer bekamen dabei eine C# Code Basis mit diversen Problemen „vorgesetzt“. Gemeinsam analysierten wir den Code mit Hilfe von Experimenten, die wir als Unit Tests implementierten. Dabei waren natürlich diverse Hürden z. B. durch Abhängigkeiten zu überwinden. Hier zeigten wir den Teilnehmern, wie man sich im sogenannten „Brown Field“ nach und nach ein Sicherheitsnetz schafft, das komplexere Refactorings möglich macht. In einer abschließenden Diskussionsrunde tauschten wir Erfahrungen Tipps & Tricks aus.

Das Feedback der Teilnehmer war durchweg positiv und auch uns machte der Workshop viel Spaß.

Tag 1: Clean Code mit dreihändigen Affen

In seiner Keynote „Von Clean Code zu Clean Software“ stellte Dr. Elmar Jürgens klar, dass sich Qualität nicht nur auf Code beschränkt. Insbesondere die Organisation und Umgebung in der Entwickler arbeiten hat massive Auswirkungen auf die Qualität einer Software. Interessanterweise lassen sich diese Auswirkungen im Code finden, was Jürgens eindrucksvoll an realen Beispielen demonstrierte. Netterweise stehen die durchaus sehenswerten Slides online zu Verfügung.

Remy Loy zeigte anschließend, wie man Clean Code im Bereich funktionale Programmierung erweitern kann. In seinem Vortrag gab er viele Tipps, wie sich die Code Qualität mit funktionalen Erweiterungen verbessern lässt.

Nach einem leckeren Mittagessen kam mein persönlicher Höhepunkt des Tages. Lutz Marquardt und Frank Blendinger präsentierten Clean Code Konzepte in einer ganz neuen Form – als Rollenspiel. Das Publikum schlüpfte dabei in die Rolle eines Programmierers und konnte an entscheidenden Stellen durch Handzeichen den Verlauf der Geschichte beeinflussen. Hierbei begegnete uns ein Ork als unser Chef, ein dreihändiger Affe der sich für Testautomatisierung aussprach sowie ein Staubsauger, der durch einen Bug plötzlich Menschen tötet („Code Reviews können Leben retten!“). Glücklicherweise erschien uns ein Geist namens „Bob“, der uns einen alten Folianten namens „Clean Code“ schenkte. Auch wenn ich dabei wenig neues gelernt habe war dieses Event purer Spaß und macht Lust auf mehr.

In seinem Vortrag „Clean Code for the Front End“ zeigte Mathias Arens, wie moderne Web Frontend Entwicklung funktioniert. Hier konnte ich am Meisten mitnehmen, da ich nicht primär Frontend Entwicklung betreibe, trotzdem aber immer mal wieder damit konfrontiert werde. Mathias zeigte hier viel Erfahrungswissen sowie verbreitete Patterns. Insbesondere die CSS Namenskonvention Block Element Modifier (BEM) erscheint simpel, ist aber sehr mächtig – diese Methodik kommt auf jeden Fall in meinen Werkzeugkasten.

Mike Kaufmann zeigte wie man mit Sonar Cube Kennzahlen zur technischen Schuld berechnen kann. Trotz der durchaus beeindruckenden Präsentation bezweifle ich allerdings, dass man so ein komplexes Thema in ein paar wenigen
Zahlen erfassen kann. Seiner Aussage „Clean Code ist Team Sport“ stimme ich allerdings voll zu.

In einer sehr unterhaltsamen Live Coding Session zeigte uns Roland Golla, wie man mit dem PHP Framework Codeception komplette End-to-End Tests für Webanwendungen implementiert.

Beim anschließenden Feierabendbier erzählte mir Roland über seine Initiative Never Code Alone in der er soziale Einrichtungen mit Software-Entwicklungsprojekten unterstützt und gleichzeitig den Austausch in der Entwicklercommunity fördert.

Tag 2: Clean Code ist mehr als nur Code

Frisch ausgeruht legte ich an diesem Vormittag den Fokus auf Themen, die über das codieren hinausgehen.

Stark war hier die Aussage von Steven Kolbenschlag, dass die Einführung von agilen Vorgehensweisen oft scheitert, wenn die Code Qualität nicht stimmt. Er schloss seinen Vortrag „Wie agil ist ihr Code?“ mit der Aussage, dass die Vorteile des agilen Vorgehens ohne Clean Code Development nicht voll ausgeschöpft werden können.

Francois Lorioux teilte Erfahrungen aus seinem 30-jährigen Berufsleben und zeigte worauf es ankommt, wenn Software über viele Jahr(zehnte) wartbar und erweiterbar sein soll. Neben vielen Tipps und Anekdoten gefiel mir hier der Satz „If you want to kill software, use inheritance“ besonders gut.

Im Vortrag „Erfolgsfaktor Mensch“ zeigten Claudia Simsek-Graf und Christoph Meyer, dass Software letztlich von Menschen gemacht wird und dass Projekte meist an menschlichen Konflikten scheitern statt an technischen Problemen. Die sehr interaktive Session bot viel Raum zum Erfahrungsaustausch und Diskussion. Gerade die Aussage „Clean Code funktioniert nicht im Alleingang“ kann ich aus eigener Erfahrung voll unterschreiben.

Da es ganz ohne Code doch nicht geht hörte ich mir zum Abschluss Gregor Trefs Vortrag „Combinator als funktionales Entwurfsmuster in Java 8“ an. Positiv überraschte mich, dass der Vortrag von Anfang an sehr praxisorientiert war und die oft etwas trockene Theorie der funktionalen Programmierung weggelassen wurde. Am Beispiel Eingabevalidierung zeigte Gregor, wie man mit Hilfe von primitiven Funktionen und Kombinatoren immer komplexere Regeln realisieren kann ohne die Lesbarkeit zu verschlechtern. Neben der Präsentation hat er die Methode auch in einem Blogartikel beschrieben.

Fazit: Gerne wieder

Insgesamt ziehe ich von den Clean Code Days ein sehr positives Fazit. Insbesondere die familiäre Atmosphäre war super – da geht es bei größeren Konferenzen oftmals anonymer zu. Ich hatte viele spannende Gespräche während und lernte viele neue Leute kennen.

Die Räumlichkeiten sowie die Organisation waren toll. Das Essen schmeckte allerdings mal wieder zu gut – was der schlanken Linie nicht gerade förderlich ist ;-).

Ein kleiner Wermutstropfen war lediglich, dass sich relativ viele Vorträge eher am Einsteigerniveau und der bekannten Literatur orientierten. Hier wäre es schön, in Zukunft mehr fortgeschrittene Themen sowie Spezialthemen (z. B. Anwenderberichte über Refactoring in regulierten Bereichen wie Medizintechnik) zu sehen.

Insgesamt waren es drei super Tage in München, die Lust darauf machten sich noch mehr mit dem Thema auseinanderzusetzen. Ich freue mich schon auf eine Wiederholung im nächsten Jahr.