Archiv

Archive for November 2010

Buch-Rezension zu “The Economics of Iterative Software Development”

30. November 2010 1 Kommentar

The Economics of Iterative Software Development – Steering Toward Better Business Results” von Walker Royce, Kurt Bittner und Mike Perrow erschien 2009 bei Addison Wesley. Ein Buch über den wirtschaftlichen Wert von iterativen Vorgehensmodellen bei der Software-Entwicklung tönt interessant. Und mit unter 200 Seiten erwartete ich eine kurze, aber doch fundierte Auseinandersetzung mit dem Thema.

 
Klein – aber fein?
Bei dem geringen Umfang war mir klar, dass ich keine grosse theoretische Abhandlung erwarten konnte. Die 3 Autoren haben fundierte Kenntnisse in der Projektführung und sind mit RUP(Rational Unified Process) bestens vertraut – einer war sogar bei der Entstehung massgeblich beteiligt. Bei diesem Hintergrund erwarte ich einerseits Werbung für RUP und andererseits eine praxisbezogene Darstellung wie man zu den besseren Resultaten kommt.

 
Ein schöner Vergleich
In der Einleitung wird die Planung eines Software-Projekts mit der Planung einer mehrmonatigen Reise verglichen. Dort wird man zu Beginn nur grob die wichtigsten Stationen planen und erst vor Ort sich mit Details wie dem Mittagessen oder der Parkplatzsuche beschäftigen. Mir hat dieser Vergleich sehr gefallen, da dieser mit wenigen Worten die Sache auf den Punkt bringt. Leider ist dies das Highlight des Buches.

 
Aktuell ja, aber zeitgemäss?
Die Resultate vom CHAOS-Report 2007 zeigen, dass dieses Buch nicht all zu alt ist. Hätte man den dazugehörigen Abschnitt weggelassen, könnte man als Leser auf die Idee kommen, das Buch stamme aus dem letzten Jahrtausend.

Wäre das Buch vor 20 Jahren erschienen, hätte man viele der Ideen aus dem Buch wohl als Meilenstein bezeichnen können. Iteratives Vorgehen gab es schon vorher, aber nun hätte man ein Buch gehabt das diese Vorgehensmodelle mit einem Mehrwert fürs Geschäft kombiniert.

Aber schon vor 10 Jahren hätte man mit den Ideen nicht mehr wirklich viel Beachtung erhalten. Der Trend zeigte schon stark in Richtung der agilen Methoden (wie XP). Wer sich vom Wasserfall aber erst in Richtung iterative Methoden verabschieden wollte, hätte damit doch noch einiges anfangen können.

Da das Buch aber 2009 erschienen ist, muss man es auch danach bewerten. Und das sieht schlecht aus. Die Probleme mit dem Wasserfall-Modell sind in jedem halbwegs brauchbaren Fachbuch in unzähligen Varianten beschrieben worden. Gleiches gilt für Iterative Vorgehensmodelle sowie deren Vorteile und wie man diese Einführt.

Es scheint fast als ob man irgendwo ein verstaubtes Manuskript gefunden hätte und dies nun doch noch veröffentlichen wollte.

 
Fazit
Das Buch war für mich nach der Einleitung ein kompletter Reinfall. Den Autoren gelingt es trotz ihrer Praxiskenntnisse nicht, ihre Ideen und Thesen (messbar) zu belegen. An Zahlen fehlt es nicht, aber woher die kommen und was man da eigentlich gemessen hat bleibt im Dunkeln.

Wer sich für das Thema interessiert, sollte sich “Was man nicht messen kann…” von Tom DeMarco anschauen. Dies ist trotz seines Alters noch immer ein Must-Read. Wer es gerne kürzer hätte, sollte sich unbedingt den Blogpost von Trond Wingard anschauen.

 
Zum Buch
The Economics of Iterative Software Development – Steering Toward Better Business Results” von Walker Royce, Kurt Bittner und Mike Perrow, 2009 bei Addison Wesley, ISBN 978-0-321-50935-2, 192 Seiten

Schlagworte: ,

Buch-Rezension zu “Debug It!”

7. November 2010 1 Kommentar

Debug It!” von Paul Butcher erschien 2009 bei The Pragmatic Programmers. Wie es der Titel ahnen lässt, geht es um das Debuggen von Programmen. Braucht es dazu ein ganzes Buch? Ja! Und es verwundert wieso dies nicht schon früher geschrieben wurde.

Unter debuggen verstehen viele Entwickler die Zeit, in der sie mit Hilfe eines Debuggers versuchen zu verstehen, was ihr Programm gerade falsch macht. Butcher beschränkt sich nicht auf diesen kleinen Teil sondern behandelt den ganzen Ablauf der Bugbeseitigung. Dies reicht vom 1. Aufblitzen des Fehlers über die Bugmeldung, der Beseitigung des Bugs bis hin zum Verbessern der Abläufe um solche Fehler nicht erneut zu machen.

Damit sollte klar sein wieso für diesen Teil der Software-Entwicklung ein eigenes Buch angebracht ist.

 
Reproduzierbarkeit ist die Grundlage
Viel zu oft vermutet man die Ursache eines Bugs an einer bestimmten Stelle. Da man ja weis was es ist, beginnt man gleich zu reparieren. Das Problem tritt danach nicht mehr auf, also muss es gelöst worden sein. Was aber, wenn man mit einem Datensatz testet, bei dem der Fehler gar nicht auftaucht? Dann ist die ganze Aussagekraft des Nachtests dahin.

Der Hinweis von Butcher ist da sehr simpel: Bevor man etwas macht, muss der Fehler reproduziert werden. Ist dies zu komplex oder zu aufwändig, muss man weiter suchen bis man eine einfache, reproduzierbare Möglichkeit gefunden hat, um den Bug ans Tageslicht zu befördern. Dabei genügt es nicht, dass der Bug ab und zu auftritt. Denn wer sagt einem später, dass man den Fehler wirklich behoben hat und nicht nur gerade den Fall erwischt, wo der Bug sich mal wieder nicht zeigt?

Auf den ersten Blick mag dies zu aufwendig erscheinen. Nur wie viel Zeit verliert man wenn man den gleichen Bug ein 2. Mal beheben muss? Oder was ist wenn der Bug erst wieder in der Produktion auftritt? Ist angesichts der möglichen Auswirkungen wirklich keine Zeit für eine genaue Problemanalyse?

 
Ursachen bekämpfen statt nur Symptome behandeln
Ein weiterer Punkt der viel zu wenig beachtet wird ist was den Bug eigentlich auslöst. Ist es wirklich nur ein Problem des Entwicklers der bei einer Methode mit mehreren Strings als Argumente 2 davon vertauscht? Oder sollte man die Methode nicht ebenfalls anschauen und die Strings reduzieren?

Im Gegensatz zur Reproduzierbarkeit ist die Ursachenbehebung schon deutlich komplexer. Sobald sich die Bugs bei der Methode häufen, kann eine tiefgreifende Anpassung aber wiederum deutlich günstiger sein.

 
Wann sollen Bugs gefixt werden?
Im Buch werden 2 gegensätzliche Verfahren beschrieben, wie in der Praxis Bugs gefixt werden. Die einen beheben die Bugs sobald sie entdeckt werden, die anderen gehen diese erst am Ende der Entwicklungsphase an. Butcher bevorzugt klar die Variante mit der sofortigen Behebung des Fehlers. Dies gibt einem Vertrauen in den Code, da man weiss wir haben keine Bugs und funktioniert etwas nicht muss es ein bisher noch nicht bekannter Bug sein. Sind die bekannten Bugs gefixt, wird in der regulären Weiterentwicklung festgestellt, dass der Bug behoben ist.

Beim anderen Ansatz vermutet man den Fehler in einem bekannten Bug und ignoriert dies fürs erste. Hat man am Ende der Entwicklungsphase endlich die bekannten Bugs behoben, muss man nachtesten. Dann stellt sich zu oft heraus, dass ein Teil der Probleme nicht durch die gesammelten Bugs verursacht wird, sondern durch neue. So wiederholt sich der Kreislauf mit den Bugfixes, Nachtests und dem finden weiterer Bugs. Nur ist dafür in den meisten Projekten keine Zeit geplant worden und so kommt es zu grossen Verzögerungen.

Ich bin hier ganz der Meinung von Butcher. Die Bugs müssen so oder so behoben werden und dann kann man dies auch gleich machen.

 
Die Ideale Umgebung fürs Debuggen
Ein ganzes Kapitel ist der Umgebung gewidmet. Dies ist eines der Kapitel, bei dem man nicht einfach als einzelner Entwickler etwas ändern kann. Als unverzichtbar für eine dauerhafte Qualitätssicherung führt Butcher auf:

  • Ein Versionierungssystem für Quellcode
  • Automatische Tests
  • Test-Attrappen (Mocks, Stubs, Testdoubles)
  • Automatische Builds
  • Continous Integration
  • Statische Codeanalyse

Je nach Programmiersprache variieren die dafür zu verwendenden Werkzeuge. Im Appendix gibt es eine Liste mit zahlreichen Tools für Java, C# und C++.

 
Fazit
Das Buch bündelt eine ganze Reihe von Best-Practices. Vieles hat man schon gehört und etliches kennt man eigentlich schon lange. Die Kombination zusammen mit guten Beispielen gibt einem aber einen Ruck es auch endlich umzusetzen. Zumal ein Grossteil der Tipps unabhängig von Team, Programmiersprache und Vorgehensmodell ist. Put it in Action!

 
Zum Buch
Debug It!: Find, Repair, and Prevent Bugs in Your Code” von Paul Butcher, 2009 bei The Pragmatic Programmers, ISBN 978-1-9343-5628-9, 232 Seiten

Schlagworte: , , ,
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 245 Followern an