Beiträge mit tag "Zitate

Es gibt immer eine Alternative

1

Nachdem ich in letzter Zeit häufig Politiker zitiert habe, die etwas sinnvolles getan oder geleistet haben, macht dieser Trend mit einem Zitat der eisernen Lady Margaret Thatcher eine Kehrtwende. Die britische Premierministerin hat häufig die Floskel „There is no alternative.” verwendet. Ein Zitat, das bei mir keine positiven Gefühle auslöst.

Dieser Satz ist ein bequemer Weg, um eine Entscheidung zu begründen. So unwahr dieser Satz in der Politik ist, genauso unwahr ist es, wenn es um Software-Entwicklung oder das Management von Entwicklungs-Teams geht. Wenn jemand Ihnen glauben machen will, dass Sie unbedingt eine Rules Engine/Scala/PHP/einen Application Server einsetzen müssen, um ein Problem zu lösen und das damit begründet, dass das der einzige Weg ist, das Problem zu lösen, dann schauen Sie besser genauer hin.

Statt des einzigen Wegs ist es meistens eher der einzige Weg, den die entsprechende Person kennt, oder der, bei dem er nichts neues lernen muss oder sogar der, der einem Consultant das meiste Geld bringt.

Die Gründe für die scheinbare Alternativlosigkeit werden Ihnen natürlich nicht mitgeteilt. Mit dem Satz „Es gibt keine Alternative.” wird nur versucht, eine Diskussion über mögliche Wege von Anfang an zu unterbinden.

Der französische Soziologe Pierre Bourdieu hat für dieses Muster den Begriff „TINA-Prinzip” geprägt, in Anlehnung an die Anfangsbuchstaben von „There Is No Alternative.” Passend dazu hat die Politikwissenschaftlerin und ehemalige Greenpeace-Vorstandsmitglied Susan George dem TINA-Prinzip den Aufruf „TATA!” entgegengestellt:

There Are Thousands of Alternatives!

Ob Sie dem TINA- oder dem TATA-Prinzip folgen, liegt bei Ihnen, Sie haben die Alternative.

Jeder ist entbehrlich – außer John Rambo

2

In Rambo II – Der Auftrag wird John Rambo von seinem ehemaligen Vorgesetzten aus dem Gefängnis (in das man in nach Rambo – First Blood gesteckt hat) geholt und nach Vietnam geschickt. Dort soll er Photos von Kriegsgefangenen machen, die auch viele Jahre nach dem Vietnamkrieg dort festgehalten und gefoltert werden.

Unterstützt wird John Rambo dabei von der Vietnamesin Co Bao, in die er sich während seines Einsatzes verliebt und von Captain Vinh getötet wird. Rambo schwört Rache und befreit die Kriegsgefangenen unter Einsatz seines eigenen Lebens aus den Klauen des Vietcong.

Vor ihrem Tod führen Rambo und Co Bao die folgende Unterhaltung.

Rambo: „Ach weißt Du, ich bin entbehrlich.”
Co Bao: „Was bedeutet entbehrlich?”
Rambo: „Das ist so, als wenn man zu einer Party eingeladen wird, und dann nicht hingeht. Es spielt einfach keine Rolle.”
Co Bao: „Rambo, Du bist nicht entbehrlich.”

John Rambo ist also nicht entbehrlich. Doch was hat er davon? Immer wieder, wenn es Probleme gibt, muss Rambo sein Leben einsetzen, um diese Probleme zu lösen. Was das aus ihm gemacht hat, sieht man sehr gut im ersten Film der Rambo Reihe: In First Blood kommt Rambo aus dem Krieg zurück in eine Kleinstadt und ist so traumatisiert, dass er sich vom Sheriff provozieren läßt und einen Kleinkrieg anfängt. Am Ende des Films wird er von der Armee eingesperrt und erst wieder auf freien Fuß gesetzt, als man ihn bei einem Todeskommando braucht. Ähnlich ergeht es Rambo in den Jahren danach, statt Vietnam muss er in Rambo III nach Afghanistan. Selbst als er sich in „John Rambo” einen Altersruhesitz in Thailand aufbauen möchte, und wirklich keinen Ärger mehr sucht, kommt er nicht zur Ruhe. Stattdessen muss er eine Gruppe Missionare aus Burma retten, die nicht auf ihn hören wollten. Sein Leben wiederholt sich immer wieder.

Viele Software-Entwickler wollen so sein, wie John Rambo: unentbehrlich. Sie sind glücklich, wenn sie die einzigen sind, die wissen, wie man mit einer bestimmten Datenbank oder einer Legacy-Applikation umgeht. Wenn es Probleme mit dieser Datenbank oder dieser Anwendung gibt, dann muss man beim einzigen Entwickler vorsprechen, der sich damit auskennt und ihn bitten, diese Probleme zu lösen. Wenn man so manchen „unentbehrlichen” Entwickler reden hört, dann lassen sich diese Probleme auch nur, wie von John Rambo, unter „Einsatz des eigenen Lebens” lösen.

Auch wenn es anfänglich schmeichelt, immer dann gerufen zu werden, wenn es Probleme gibt, bringt diese Unentbehrlichkeit auch negative Seiten mit sich. Einem solchen Entwickler wird die Möglichkeit genommen, sich weiter zu entwickeln. Er bleibt auf der aktuellen Position sitzen, weil er ab und zu an dieser Stelle dringend gebraucht wird. So wie Rambo in Friedenseiten langsam zu einem Relikt aus alten Zeiten wird, geht es auch diesen Entwicklern. Und wenn die Systeme des Entwicklers sterben, so stirbt auch der Entwickler mit ihnen. Und wie John Rambo in Thailand, möchte ein Entwickler sich später einmal neu orientieren. So lange er in seinem alten Job nicht entbehrlich geworden ist, wird er dort immer zu jeder Tages- und Nachtzeit gerufen werden.

Falls Sie also ein „unentbehrlicher” Entwickler sind, lauet mein Rat an Sie: „Seien Sie nicht John Rambo, machen Sie sich entbehrlich.

Kleine Schritte sind besser als keine Schritte

1

Eigentlich hatte unter diesem Titel geplant, einen Eintrag über die Pfadfinder-Regel zu schreiben, die Robert C. „Uncle Bob” Martin in seinem Buch Clean Code vorstellt:

Leave the campground cleaner than you found it.

Genau an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den Akten zu legen. Doch Schritt für Schritt (wer findet hier den Wortwitz?) bin ich wieder zu der Idee zurück gekehrt.

Die Überschrift „Kleine Schritte sind besser als keine Schritte” war das Motto von Willy Brandt (dt. Bundeskanzler von 1969 bis 1974), der damit seine Ostpolitik der langsamen Annäherung beschrieben hat.

Willy Brandt hat bei diesem Zitat sicher nicht an Uncle Bob, Coding Standards und kleine Refactorings gedacht. Sehr viele Entwickler, die sich die Pfadfinder Regel auf die Fahne schreiben, beschränken diese jedoch zu stark auf den Quellcode und wenden diese nicht ganzheitlich auf die eigene Arbeit und das Umfeld an. Richtig aufgefallen ist mir das auch erst in den letzten Wochen, in denen ich ausführlich mit Holger über Clean Code und die Einührung der Prinzipien in unseren Teams gesprochen habe.

Wenn Willy Brandt diese Regel auf eine Ostpolitik angewandt hat und damit eine Annäherung an Polen und die damalige Sowjetunion damit geschafft hat, dann sollten wir diese Regel auch in unserem täglichen Arbeitsumfeld anwenden können.

Ein gutes Beispiel ist, dass ich auf Konferenzen, auf denen ich über Clean Code, Testgetriebene Entwicklung und eine Menge andere „gute Dinge” geredet habe, am Ende immer gefragt werde, wie man diese in Teams einführt. Für die Teilnehmer sieht das immer nach einem großen Schritt aus, ein Team, das kein Verständnis für eine geminesame Code-Basis, Qualität und Entwicklungsmethodik hat, in ein Team zu transformieren, das bei der Entwicklung und der Pflege des Codes harmonisiert. Meine Antwort ist auch hier immer die selbe: Man muss es in kleinen Schritten angehen. Sie werden es nicht schaffen, das Bewußtsein für neue Entwicklungsmethodiken bei allen Teammitgliedern sofort zu wecken, also wecken Sie es bei einem und schauen Sie, wie es sich danach entwickelt.

Ähnlich verhält es sich bei der klassischen Beförderung vom Entwickler zum Leiter eines Entwicklungsteam. Sie können planen, wie Sie als perfekter Teamleiter sein könnten und diesen Plan dann in einem Jahr umsetzen. Oder Sie fangen morgen an und erledigen eine Teilaufgabe Ihres neuen Jobs mit Bravour und gehen dann die nächste an.

Sei es also ein neues Projekt oder ein neuer Job, der eine große Veränderung bedeutet, so ist der erfolgsversprechende Weg der, der mit vielen kleinen Schritten auf ein Ziel führt, das sich vielleicht sogar während des Wegs verändert.

Und wäre das nicht zu dramatisch für das Ende eines Blog-Artikels, würde ich jetzt schreiben:

Danke Willy Brandt. Danke Uncle Bob. Danke Holger.

Consultants

0

Helmut Schmidt schreibt in seinem Buch „Ausser Dienst: Eine Bilanz”:

„Während ich im persönlichen Gespräch mit Personen, deren Kompetenz und Urteilskraft ich vertraute, zeit meines Lebens viel lernen konnte, habe ich von institutioneller Beratung nie viel gehalten. Gremien, Kommissionen und sonstige Beratungsinsitutionen, die lediglich Gutachten erstellen und Empfehlungen aussprechen, aber nicht handeln müssen, haben nur selten wirksamen politischen Einfluss.”

Man könnte meinen, Helmut Schmidt arbeitet auch in der IT-Branche.

An meiner Wand – mit Amilio

0

Nils Langner von phphatesme.com bietet mit amilio einen neuen Service an, mit dem man sich mit ein paar Klicks (und dem Ausfüllen von fünf Feldern) kleine Motivationsposter erstellen kann.

In Anlehnung an mein Posting „Don’t assume”, hat Herr Nils gleich noch ein Poster erstellt, das ab Montag mein altes Poster ablösen wird:

Wer sich wundert, dass das Zitat von meinem abweicht: In diesem Poster wird das Originalzitat verwendet, ich hatte das für mein Posting ein bißchen abgewandelt, da es auch in dieser Form an meiner Wand steht.

Frisch im RSS-Reader

0

Seit ich mich entschlossen habe, selbst aktiv zu bloggen, habe ich auch wieder angefangen, regelmäßig andere Blogs zu lesen. Neu in meinem RSS-Reader sind jetzt:

Frank Westphal

Mit seinem Buch „Testgetriebene Entwicklung mit JUnit und FIT” verfolge ich in unregelmäßigen Abständen, was Frank Westphal veröffentlicht. Auf seiner Website veröffentlich er interessante Artikel zum Extreme Programming, Agiler Entwicklung und Qualitätssicherung. Seinen Podcast „Tonabnehmer” habe ich mir bislang noch nicht angehört, wären aber sicher ein guter Grund, Podcasts endlich mal auszuprobieren.

Neal Ford

Neal Ford ist Meme Wrangler bei Thoughtworks. Auf ihn bin ich bei einer Keynote auf der Dynamic Languages World aufmerksam geworden. Am meisten beeindruckt hat mich damals (und auch heute noch) sein Satz

Simplify essential complexity; diminish accidental complexity.

Diesem Satz hatten Holger Rüprich und ich auch eine unserer neun Regeln in unserem Workshop „Die Kunst des Software Design” auf der PHP World 2009 gewidmet.

Ludwig Ostrowski

Auf das Blog von Ludwig Ostrowski bin ich nur per Zufall (aka Twitter) gestolpert. In meinen Reader hat er es aus zwei Gründen geschafft:

  1. Seine neusten Einträge befassen sich mit Dependency Injection (und sogar PHP und Google Guice, meine Lieblingsthemen bei DI), Continuous Integration und Sonar. Alles Themen, die mich auch schon seit einiger Zeit fesseln.
  2. In seinem Blog zitiert er Martin Fowler mit einem meiner Lieblingszitate.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Ich werde das Blog auf jeden Fall mal im Auge behalten.

David Seah

Zum Abschluss noch ein Blog, das nichts mit Software-Entwicklung zu tun hat. David Seah schreibt über Design und Produktivität und kombiniert beides, in dem er wunderschöne Vordrucke für Tasklisten oder auch Ressourcenplanung zum kostenlosen Download anbietet. Zusammengefasst werden diese unter dem Namen „The Prinable CEO”, den David Seah wie folgt erklärt:

The Printable CEO name comes from the idea that a good CEO should focus primarily on those things that move the company forward; since I can’t afford to hire my own CEO, being able to print one out seemed like the next best thing!

Die Feeds

Don’t assume!

1

Manche Weisheiten sind so einfach, dass man sie immer wieder vergisst. Aus diesem Grund hänge ich mir solche gerne bei mir im Büro an die Wand, damit ich regelmäßig mit der Nase drauf gestoßen werden.

In regelmäßigen (oder wahrscheinlich eher unregelmäßgen) Abständen werde ich diese jetzt auch in meinem Blog posten. Ihr findet diese Artikel dann alle unter dem Tag „An meiner Wand”. Den Anfang macht heute die folgende Weisheit von Oscar Wilde:

Don’t assume – it makes an «ass» of «u» and «me».

Auf den ersten Blick klingt das in der Software-Entwicklung etwas seltsam, da wir alle wissen, dass in kaum einem Software-Entwicklungsprojekt immer alle Anforderungen klar auf dem Tisch liegen. Dabei bleibt uns als Entwicklern oft nichts anderes übrig, als Annahmen zu treffen.

Wichtig ist aber, dass man sich in solchen Moment bewusst sein muss, wo man nur Annahmen trifft. Sonst macht man ganz plötzlich Annahmen, von denen man annimmt, dass es Fakten sind. Und nichts ist schlimmer, als Annahmen über Annahmen zu treffen.

Und genau da beginnt das Problem. Sie treffen Entscheidungen auf Basis von Fakten, die nur in Ihrer Vorstellung existieren. Typische Annahmen, die zu Problemen führen sind:

  • „Ich denke nicht, dass der Kunde diese Anforderung nochmal ändern wird. Die ist in Stein gemeißelt.”
  • „Unsere Applikation ist so langsam, weil wir Datenbank XXX verwenden, wir müssen stattdessen die Datenbank YYY einsetzen.”

Während die erste Annahme dazu führt, dass Sie dem Kunden Flexibilität nehmen, investieren Sie bei der zweiten Annahme Zeit und Aufwand in eine Optimierung, die unter Umständen unnötig ist. Damit landen Sie nämlich bei Premature Optimization, und darüber hat Donald Knuth mal gesagt:

Premature optimization is the root of all evil.

Bevor Sie also annehmen, dass ein Kunde eine Anforderung in Stein gemeißelt hat und darauf hin eine Architektur-Entscheidung treffen, sprechen Sie doch lieber mit dem Kunden darüber. Erklären Sie ihm zur Not auch, welche Vor- und Nachteile hat, wenn er genau diese Anforderung unumstößlich festlegt und Ihnen damit eine bestimmte Architekturentscheidung ermöglicht.

Und bevor Sie annehmen zu wissen, wo das Performance-Problem Ihrer Anwendung liegt, fragen Sie doch einfach einen Profiler und stützen Ihre Entscheidungen auf Fakten.

nach oben