Thoughts on agile software development
Christmas is a contemplative time. You meet up with friends and family and enjoy being together. Until a family member gets in touch and asks for a new printout of the family tree. Family trees were a topic on this blog in 2018 and since then it has been rather quiet on the subject.
Tunnel constructions are classic waterfall projects in which extensive planning is carried out and then construction can be completed without major changes. There are geological surprises from time to time, but a tunnel plan is, quite literally, set in stone.
Wer sich schon einmal mit dem Thema Zeitmanagement beschäftigt hat, kennt vermutlich schon die Eisenhower-Methode. Sie ist eine populäre Technik, die sich auf die Priorisierung von Aufgaben konzentriert. Sie ist nach dem ehemaligen US-Präsidenten Dwight D. Eisenhower benannt, der für seine effiziente Arbeitsweise bekannt war. Wer eine einfache Methode sucht, sich auf die wirklich wichtigen Dinge zu konzentrieren, sollte an dieser Stelle einfach weiterlesen.
Beginnt man sich mit einer agilen Methode wie Scrum zu beschäftigen, dann lernt man relativ schnell, dass viele Dinge vom Team entschieden werden. Das hört sich im ersten Moment für die Team Mitglieder sehr gut an, bedeutet aber auch, sich einmal mit dem Thema Entscheiden zu beschäftigen.
Das von John Gall schon 1975 in seinem Buch Systemantics: How Systems Work and Especially How They Fail aufgestellte Gesetz, ist eine der vielen wichtigen Faustregeln, die jeder System-Architekt und Software-Entwickler kennen sollte. Obwohl schon fast 50 Jahre alt, wird es von vielen Kollegen stoisch ignoriert.
Zu den ersten Komponenten der FreshMarker Template-Engine gehörte ein einfaches Plug-In System. Durch diese Komponente wurde die Ergänzung um neue Built-Ins, Formatter und Mapper vereinfacht. Zwei neue Plug-Ins zeigen dabei Stärken und Schwächen des bisherigen Ansatzes.
Bei der Diskussion welche Methodik am besten geeignet ist, um die Softwarequalität von Legacy Software zu verbessern, wird häufig das Pfadfinder Prinzip hochgehalten. Die Vertreter diese Methodik möchten die Software in kleinen Refactoring Schritten während der Implementierung neuer Features verbessern. Die Idee ist einfach und einleuchtend, denn wenn ich sowieso gerade zur Stelle bin, kann ich in der Umgebung auch gleich aufräumen.
Das Zitat „Die Unit Tests schreibe ich immer zum Schluss“ hat vermutlich schon jeder Entwickler von einem Kollegen hören müssen. Üblicherweise, wenn man bei einem schwerwiegenden Problem während der Implementierung helfen möchte. Ein kurzer Blick auf die Testergebnisse hilft dann enorm. Häufig zeigen die fehlgeschlagenen Unit Test direkt auf das Problem. Fehlen die Unit Tests, dann müssen sich die Entwickler solange durch GIT Historie und Debugger quälen, bis der eingeschleppte Fehler gefunden ist.
Welcher Software Entwickler kennt nicht die Geschichte vom neuen Tool, das seine Arbeit enorm voranbringen soll. Die Firma schafft für jeden Entwickler eine Lizenz an und alle werden auf das neue Tool geschult. Drehen wir die Uhr dann einige Monate weiter, dann hat sich die Gruppe der Entwickler in mehrere Fraktionen aufgespalten. Eine kleine verschworene Gruppe von Nutzern, eine großen Fraktion von Kollegen, die das Tool unter Ihresgleichen verdammen und einer kleineren Fraktion von Entwicklern, die das Tool nicht mehr benutzen.
Beim Aktualisieren von Bibliotheken finden sich immer wieder Methoden, die nicht mehr zeitgemäß sind. Denn häufig ermöglichen neuere Ansätze kompakteren, einfacheren oder eleganteren Code. Um den Nutzern der Bibliothek das Leben nicht zu erschweren, werden solche Methoden als veraltet (@Deprecated) markiert. Damit beginnt eine Gnadenfrist, in der die Nutzer ihren eigenen Code auf die neuen Alternativen umbauen müssen. Diese Frist endet, wenn die Entwickler der Bibliothek die veralteten Methoden löscht.