Archiv der Kategorie ‘Organisation‘

TDD ist auch nur eine extreme Sichtweise

Donnerstag, den 25. Juni 2009

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.

Meetings töten Menschen

Donnerstag, den 10. April 2008

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.

Immer wieder

Dienstag, den 8. April 2008

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.

Warum man ein Wiki benutzen sollte

Montag, den 31. März 2008

Besser als in diesem Bild kann man es eigentlich nicht darstellen. Wobei die Unart, unformatierte Texte in Worddokumente zu verpacken um diese dann per Email zu verschicken auch ohne Wiki fast schon eine Straftat darstellt.

Messeplan Cebit

Freitag, den 7. März 2008

Ich war am Dienstag auf der cebit. Das was mich besonders gestört hat, war der aushängende Messeplan.Ich habe keine Übersicht gefunden, in der aufgelistet ist, was zum Beispiel in Halle 8 ist. Jetzt (leider zu spät) habe ich endlich einen Plan gefunden, der mir geholfen hätte. Vielleicht hilft es ja jemand anderem.

Messeplan Cebit 2008


Empfehlungen: handy taschen | Good Job - Bad Job