Leitsätze

Aus meiner Erfahrung haben sich die folgenden zwei Leitsätze bewährt:

1. Keep it simple

Man sollte sich auf das konzentrieren, was bekannt ist und nicht für alle Eventualitäten bereits Vorkehrungen treffen wollen. Denn diese Vorkehrungen erhöhen immer die Komplexität eines Projekts, und damit die Kosten.

Zum Beispiel wird oft angeraten, die Anbindung an die Datenbank separat zu behandeln. Dadurch soll später ein eventueller Austausch der Datenbank leichter möglich sein. Ob mit solchen vorbeugenden Maßnahmen auch wirklich die richtigen Vorbereitungen getroffen werden, ist eher fraglich. Und wie viele Projekte oder Produkte kennen Sie, in denen tatsächlich die Datenbank getauscht wurde?

Der Verzicht auf derartige vorbereitenden Maßnahmen bedeutet übrigens nicht, dass hierdurch ein späterer Austausch ausgeschlossen ist. Er bedeutet nur, dass diese Änderungen erst dann durchgeführt werden, wenn sie notwendig sind. Mit der Kenntnis um die konkrete Änderung ist es außerdem möglich, zielgerichteter und punktgenau die Änderungen durchzuführen. Dies trägt auch zu geringeren Kosten bei.

Es hat sich bewährt, einerseits mit der Implementierung der konkreten Anforderungen zu beginnen und andererseits parallel dazu die unklaren Anforderungen zu konkretisieren. Dabei ist es oft hilfreich, Mocks (Dialoge mit Layout, aber ohne Funktion) zur Veranschaulichung zu entwickeln. Diese Mocks können später in die Entwicklung einfließen. Sie helfen aber vornehmlich dabei, eine bessere Vorstellung von Funktionalitäten zu erlangen. Grundsätzlich sollten Anforderungen, die noch vage sind, erst entwickelt werden, nachdem sie konkretisiert wurden.

Die Konzentration auf bekannte Anforderungen minimiert die Gefahr von Fehlentwicklungen und senkt letztlich den Aufwand.

2. Single Point of Maintenance

Mit heutigen Tools ist man verführt, "mal eben" den Code von einer anderen Stelle zu kopieren - es geht häufig schneller und Zeit ist bei der Softwareentwicklung ein besonders knappes Gut. Wenn dann später eine Anpassung erfolgen soll, wird es oft aufwändig und fehleranfällig. Daher sollten Redundanzen im Code vermieden werden. Das ist bei verteilten Teams alles andere als einfach und geschieht sicherlich nicht von alleine. Insbesondere bei solchen Teams ist es aber von Nachteil, diesen Grundsatz zu vernachlässigen.