Michaels Blog

Es muss Gründe geben, warum nicht jeder Entwickler bei der Erwähnung von Test Driven Development (TDD) mit „ach klar, genau“ antwortet. Ich möchte dazu mal etwas ausholen. Softwareentwicklung ist ein kreativer Prozess. In diesem Prozess gibt es einige hochbegabte Entwickler, sehr viele im guten Mittelfeld und einige, die jede Kreativität vermissen lassen. Wo der eine mit dem ersten Wurf bereits einen sehr guten Treffer landet, muss sich der andere langsam an das Ziel herantasten. Das ist ganz normal, so sollte es ja auch sein.

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.

Klassische Situation. Man sitzt in einem Meeting und stellt fest, dass man nur zum Teil involviert ist und neue Themen vorgestellt werden. Man bekommt unweigerlich das Gefühl, das man dafür eine geschicktere Lösung gefunden hätte.

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.

Entweder man ist ein Naturtalent oder man muss es sich mühsam erarbeiten. Und dieses Erarbeiten wird nicht aufhören, solange man bestrebt ist, besser zu werden.

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.

Wie ich mit dem Erscheinen von Adobe Apollo bereits erwähnte, verändert sich das Web sehr stark in Richtung Desktop. Auf dem Google Developer Day zeigte dann in einer Liveübertragung aus Mountain View Adobe auf einer Google Veranstaltung nocheinmal die Möglichkeiten von Apollo. Wer sich fragt, wieso Adobe auf dieser Veranstaltung aufgetreten ist, hat dem Punkt verpasst, an dem Google Gears vorgestellt wurde.

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 morgens schon wüsste, was der Tag für einen bereithält, würde man manchmal garnicht erst aufstehen. Insofern kann die Gabe des Hellsehens auch nur als Fluch verstanden werden.

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.