In dem man nun TDD propagiert, stellt man alle Entwickler gleich, in dem man sagt, schreibe zuerst den Test, denn was Du entwickelst funktioniert mit hoher Wahrscheinlichkeit nicht. Das ist spannend. Wenn man Unterschiede zwischen Entwicklern macht, und ich hoffe, da gibt es keine Zweifel, dass dem so ist, dann soll es eine Arbeitsmethode geben, die für alle gleich gut funktioniert? Mir fällt kein Beispiel aus anderen Bereichen ein, wo das der Fall ist.

Ich glaube, und das zeigt mir meine Erfahrung, dass für den erfahrenen Entwickler eher das Motto gelten sollte: Teste, wo Du es für wahrscheinlich hältst, dass Du ein Fehler gemacht hast. Und ich habe es bisher nicht als vorteilhaft erachtet (und darum geht es ja hauptsächlich), den Test vor der Funktion zu schreiben. Dann das würde darin enden, dass ich an zwei Stellen gleichzeitig Anpassungen vornehmen muss, bevor überhaupt eine Funktion umgesetzt wurde. Ich weiß nicht, wie es anderen Entwicklern so geht, aber ich passe den Code, der entsteht sehr oft an – wie ein Gemälde, dass sich mit jedem Pinselstrich vervollständigt, aber eben auch Bereiche wieder ausradiert und neu gezeichnet werden müssen. Es ist nicht nur eine Funktion, die so entsteht, sondern gleich ein kleines Lösungsgebilde. Würde ich jedes mal davor einen Test schreiben, würde ich auf diese Weise extrem viel für die Tonne produzieren.

Als Entwickler passt man seine Arbeitsweise so an, dass die eingesetzten Methoden einen persönlichen Vorteil offenbaren. Wenn dieser Vorteil eintritt, ist Überzeugungsarbeit nicht notwendig. Dass es immer wieder Diskussionen zu z.B. TDD gibt, liegt wohl daran, dass es nicht für jeden die beste Wahl ist.

Wer gerne gemütlich beisammensitzt, wird hier vielleicht gar kein Problem feststellen. Aber wer der Meinung ist, die ihm zur Verfügung stehende Lebenszeit in dieser Situation interessanteren Themen widmen zu wollen, den wird diese Zeitverschwendung genauso ärgern wie mich.

Sicher kann man einen Tanzsahl mit der Zahnbürste putzen und besonders positive Menschen mögen das Wort Zeitverschwendung nicht. Aber es gibt auch keinen Grund, nicht die beste zur Verfügung stehende Lösung für ein Problem zu wählen.

Das bedeutet in diesem Fall ganz einfach, ein Meeting auf das zu reduzieren, wofür es am besten geeignet ist: Probleme im Dialog zu lösen und Entscheidungen zu treffen. Alles andere kann und muss man im Vorfeld anderweitig kommunizieren, schon um in einem Meeting überhaupt eine qualifizierte Meinung haben zu können. Es dürfte nicht überraschend sein, das die Ergebnisse dabei natürlich auch besser werden.

Und von seinen Reisen nach Feuerland erzählt man dann doch lieber als vom großen Junimeeting 2008, bei dem fast die ganze Mannschaft draufging.

Das gilt für viele Bereiche. So auch für die Softwareentwicklung. Aber dieses Grundprinzip wird trotzdem gerade in diesem Bereich in Frage gestellt. Entwickler, die bestehendes nicht mehr hinterfragen oder ihre eigene Arbeitsweise nicht regelmäßig kritisch betrachten.

Gerade im Softwarebereich ändert sich die Landschaft beinahe täglich. Und wenn man auch nicht jedem Strategiewechsel mittragen muss, ist es doch zwingend, sich intensiv mit neuen Themen zu beschäftigen. Denn nicht nur die Halbwertzeit des eigenen Wissens, sondern vor allem die gesparte Zeit spricht dafür. Und man spart Zeit, weil man die meisten Probleme nicht für sich gepachtet hat, sondern meist schon eine mehr oder weniger geeignete Lösung existiert.

Es ist nur schwer vorstellbar, wie man jemand gut beraten kann, wenn man sich nur selten selbst damit beschäftigt. Es sei denn, man ist ein Naturtalent. Aber wenn die Anzahl der Naturtalente einen signifikanten Anteil übersteigt, kann man nicht mehr davon sprechen.

Man kann also als Softwareentwickler selbst am Ball bleiben, oder darauf hoffen, dass die gewählte Hilfe (Kollege, Consultants, etc) selbst dran bleibt oder man das Glück hat, ein Naturtalent zu treffen.

Glück haben immer nur die anderen.

Interessant und sicher für den einen oder anderen etwas erschreckend ist die Tatsache, dass beim aktuellen Trend aus Webanwendungen desktopintegrierte Anwendungen zu schaffen Adobe und Google zusammenarbeiten und das ganze dann auch noch unter Open Source stellen.

Nutzer nutzen Dinge. So wird es stark davon abhängen, wie gut solche Anwendungen laufen und welchen Mehrwert sie bieten. Aber es ist nicht davon auszugehen, dass Nutzer aus idellen oder kulturellen Gründen solche Anwendungen ablehnen werden, denn dann würde man diese Menschengruppe anders nennen. Es hängt also alles an einer guten Lösung, einem guten Produkt.

Das bedeutet, dass das Web sich verändern wird und der Desktop zwar nicht überflüssig werden wird, in der Wahrnehmung aber eher in den Hintergrund tritt. Auch das Betriebssystem wird recht schnell irrelevant und die klassische Softwareverteilung durch webbasierte Anwendungssoftware in größerem Maße unnötig. Wenn ich mich recht erinnere hatte damals Netscape die ersten Ideen, wie man auf dem Desktop viel interessantere Sachen darstellen könnte, als so öde Icons. Das war damals m$ Grund genug, das nicht zu mögen. Was damals noch funktionierte wird mit diesem Gegenspieler und den technischen Möglichkeiten nicht mehr funktionieren. Mit dem Internet als Plattform ist es jedem möglich an einem globalen Wettbewerb um die guten und besten Lösungen teilzunehmen. Und gerade kleinere agile Entwicklungen werden davon profitieren, sofern sie erfolgreich die neuen Technologien adaptieren und das Produkt herausragt.

Everyone is a software architect. Just develop it.

Wenn man aber nun in der misslichen Lage ist, das man weiß was der Tag für einen bereithält, dann kann es helfen, in dem man es verdrängt. Das löst gleich zwei Probleme:
- man kann sich darauf konzentrieren, was man gerade bewältigen muss.
- man fängt erstmal mit dem kleineren Übel an.

Wie ist man einen Elefanten? In Stücken.