Artikel zur agilen Architektur in Objekt-Spektrum

In der aktuellen Ausgabe der Objekt-Spektrum (Juli/August 2009) haben Martin Lippert und ich einen Artikel über agile Architektur veröffentlicht. Der Artikel ist Bestandteil einer Kontroverse, in der wir die Position einnehmen, dass man viele (aber nicht alle) Aspekte des Entwurfs mit geringen Kosten auch noch während der Projektlaufzeit ändern kann – und daher nicht alles vorher wissen muss.

Call for Sessions für die XP-Days Germany online

Der Call-For-Sessions für die XP-Days Germany im November 2009 ist jetzt Online: http://xpdays.de/2009/callforsessions.html

Wie letztes Jahr wird es auch dieses Jahr wieder einen offenen Review-Prozess geben. Das bedeutet, dass alle Interessierten die eingereichten Beiträge bewerten können. Die Einreicher haben die Möglichkeit, auf Basis des Feedbacks ihre Beiträge zu verbessern. So können die Vortragsvorschläge schrittweise immer weiter verbessert werden.

Als Conference Chair 2008 kann ich sagen, dass dieser Review-Prozess sehr viel gebracht hat. Vortragsvorschläge, die man in der ersten Version nicht akzeptiert hätte, wurden schrittweise so verbessert, dass sie es dann doch ins Programm geschafft haben.

Also: Alle bitte mitmachen beim Einreichen aber auch beim Reviewen!

XP and Frameworks

At the XP2000 conference I had a talk about eXtreme Programming and frameworks. Some people archive things for a really long time. One of them reread my article and asked me a few days ago if I did further research on it. I didn’t really do research but I collected some experiences which lead me to some simple conclusions (which didn’t changed too between 2000 and now):

  • Use before reuse. First you have to use some code successfully and than you can think about generalizing it for reuse. That means that you have to invest effort to refactor application code to framework code. A lot of teams try to avoid this “rework” but in most cases the effect is that the framework becomes bloated and hard to use.
  • Running application: You always have to have a running application on top of your framework that proves that the framework is useful. This application may be a demo application but that would restrict the “prove”. A real application is much better.
  • Supporting framework team: This is the really hard one. When your framework grows larger and supports more than one application team you normally need an own framework team. That is easy part, here is the hard part: The framework team has to have a perspective that the application teams are their customers and that they have to listen to the application teams and support them. Most frameworks teams I met had another attitude. They thought that they understand much better how to implement applications than the application developers know and that the application developers are dumb and foolish to a certain degree. That results in the attempt to prescribe how to develop with the framework. And that doesn’t work, especially not if you try to support agile teams that should be self organized and empowered.

Color Modeling

Color Modeling ist die Modellierungstechnik, die Feature-Driven-Development (FDD) vorschlägt – aber nicht verpflichtend macht. Aber auch außerhalb von FDD kann Color Modeling sehr nützlich sein. Ich habe es (in adaptierter Form) in Scrum/XP-Projekten eingesetzt.
Insgesamt finde ich, dass die Technik zu wenig bekannt ist und unterschätzt wird. Daher freut es mich, dass jetzt eine gute Erläuterung zu Color Modeling mit ein paar Erfahrungswerten aufgetaucht ist.

W-JAX: Hochperformante Webanwendungen

Heute habe ich auf der W-JAX einen interessanten Vortrag von Peter Roßbach gehört. Es ging um Tipps und Tricks, wie man Webanwendungen schneller machen kann. Besondere interessant fand ich, dass man sehr viele Dinge ohne Programmierung, einfach durch Konfiguration (z.B. in Apache) regeln kann – Caching, Zippen etc.
Die meisten Dinge kann man sofort umsetzen und sie versuchen keinen oder nur wenig Zusatzaufwand. Ein paar Beispiele sind:

  • Bilder sollten nicht im Browser skaliert werden, sondern in der benötigten Größe vom Server geliefert werden.
  • GET-Requests (ohne Parameter) können häufig gecacht werden und damit kann man leicht mal 50% Bandbreite sparen.
  • Man sollte immer erst die CSS-Dateien in seine HTML-Seiten einbinden und dann die Java-Script-Dateien. Sonst wird mitunter doppelt gerendert.
  • Man sollte Links ohne Ziel vermeiden (z.B. Favicons, die es nicht gibt). Diese führen intern zu 404 und 404 kann nicht gecacht werden.
  • etc.

Software-Putzer?

Nico Josuttis schreibt in seinem Blog über Software-Putzmänner und die nächste IT-Revolution. Er schlägt darin vor, schlechte Softwarequalität einfach als Fakt hinzunehmen und nicht immer zu versuchen, die Qualität zu verbessern. Vielmehr ginge es darum, mit dieser schlechten Qualität umzugehen. Als eine mögliche Alternative schlägt er Software-Putzkolonnen vor, die hin und wieder kommen und dann im Code aufräumen.

Dazu fallen mir gleich ein paar Sachen ein.

Zuerst zum Akzeptieren schlechter Qualität: Wenn die Qualität wirklich schlecht ist, wirkt sich das mannigfaltig unangenehm aus. Selbst der Product Owner bemerkt es. Nicht nur durch die langsame Entwicklungsgeschwindigkeit sondern auch dadurch, dass er aus technischen Gründen seine Priorisierungen ändern und seine Stories anders aufschreiben muss.

Und ich habe auch gerade ein aktuelles Projektbeispiel zur Hand, dass sich das Aufräumen lohnt. Beim Kunden dümpelte ein Team bei 30 Story Points je Sprint rum. Irgendwann hat das Team festgestellt, dass umfangreichere Refactorings im Bereich CSS notwendig sind, um schneller zu werden. Sie haben die Refactorings in Angriff genommen und die haben viel länger gedauert als zunächst gedacht – das ist nach meiner Erfahrung fast immer so bei größeren Refactorings. Aber sie haben es durchgestanden, obwohl es sogar soweit ging, dass nicht mehr alle Entwickler während des Sprints beschäftigt werden konnten. Nach dem Refactoring hat die Geschwindigkeit des Teams deutlich zugelegt. Heute liegt die Geschwindigkeit bei 80 Story Points je Sprint.
Mindestens in diesem Fall hat sich das Aufräumen schnell gelohnt und es wäre finanzieller Irrsinn gewesen, das Refactoring nicht durchzuführen.

Und zu den Putz-Kolonnen kann ich gleich zwei Erfahrungen beisteuern.
Erstens: Wir hatten bei it-agile mal so ein Dienstleistungsprodukt im Angebot. Das war ein Ladenhüter. Daher gibt es das jetzt nicht mehr als explizites Produkt bei uns. Wenn jemand sich dafür interessiert, beleben wir es aber jederzeit gerne wieder 🙂
Zweitens: Wir hatten in einem Projekt mal sowas wie eine Putz-Kolonne in ganz zarten Ansätzen. Das hat in meinen Augen nicht funktioniert. Zum einen liefern die Projekte dann noch schlechtere Qualität – die Putz-Kolonne wird es schon richten. Zum anderen musste die Putz-Kolonne ständig bei den Entwicklern nachfragen, was bestimmter Code bedeutet. Und damit wurde das Team dann doch wieder mit Putzarbeiten belastet.

Langer Rede kurzer Sinn: Ich vertrete genau den konträren Ansatz. Wir als Entwickler sind für die technische Qualität des Systems verantwortlich. Wer schlechte technische Qualität abliefert, verstößt aus meiner Sicht gegen den Code of Ethics unserer Zunft und sollte sich was schämen. Niemand wird uns die Zeit und das Geld zum Aufräumen geben und die Putz-Kolonne wird auch nicht kommen. Wir als Entwickler müssen die Sache selbst in die Hand nehmen und zu unserer Verantwortung stehen!

P.S.: Zum Code of Ethics: Punkt 3 lautet: “PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.” Das bedeutet meiner Meinung nach auch, hohe Qualität abzuliefern.

P.P.S.: Wer mehr darüber erfahren möchte, wie guter Code für agile Entwicklung aussieht und wie man den schreibt: ich werde auf der OOP darüber einen Vortrag halten.

Wie misst man technical debt?

Das Konzept des Technical Debt (technische Schuld) ist schon alt: Wenn man Qualität opfert, um einen bestimmten Termin zu halten, geht man eine technische Schuld ein. Diese technische Schuld bezahlt man zunächst mit einer reduzierten Entwicklungsgeschwindigkeit. Wenn man die technische Schuld dann irgendwann zurückzahlen will, kostet es i.d.R. ein Vielfaches von dem, was man ursprünglich “eingespart” hat.

Soweit so gut. Leider hilft das Konzept in der Projektpraxis nicht so fürchterlich gut. Es gibt kein vernünftiges Verfahren, um Höhe und “Zinssatz” der technischen Schuld zu messen.

Hier gibt es jetzt mal einen Vorschlag, technische Schuld zu messen und zwar in WTFs pro Minute.

Lustig? Klar!
Ernsthaft verwendbar in der Projektpraxis: Da sollte man vielleicht mal drüber nachdenken…