Schießen und Bewegen

From The Joel on Software Translation Project

Jump to: navigation, search

Von Joel Spolsky

Aus dem Englischen von Florian von Walter

Redigiert von Michael Neutze 6. 1. 2002


Manchmal bringe ich absolut nichts zustande.

Sicher, ich komme ins Büro, spiele herum, schaue alle zehn Sekunden nach, ob ich neue Email habe, lese im Web, erledige sogar ein paar hirnlose Sachen wie meine American-Express-Abrechnung. Aber ich komme einfach nicht in diesen Zustand, in dem ich Code schreibe.

Bored-tetris.gif

Diese unproduktiven Phasen dauern normalerweise ein oder zwei Tage. Aber es gab Zeiten in meiner Entwicklerkarriere, in denen ich wochenlang nichts auf die Reihe gebracht habe. "Ich bin nicht im Fluss", sagt man dann. Ich bin nicht in der Zone. Ich bin nirgendwo.

Jeder hat Stimmungschwankungen; bei manchen Leuten sind sie schwach, bei anderen ausgeprägter oder sogar eine Störung. Und die unproduktiven Phasen scheinen irgendwie mit trübsinnigen Launen zusammenzuhängen.

Das läßt mich an jene Wissenschaftler denken, die sagen, daß die Menschen nicht kontrollieren können, was sie essen. Deswegen ist jeder Versuch, eine Diät zu machen, nur kurzfristig erfolgreich und das natürliche Gewicht wird sich immer wieder einstellen. Vielleicht kann ich als Softwareentwickler wirklich nicht kontrollieren, wann ich produktiv bin, und ich muß einfach die langsamen Zeiten zusammen mit den schnellen Zeiten hinnehmen und hoffen, daß im Durchschnitt genügend Programmzeilen herauskommen, um mich als Angestellten tragbar zu machen.


Bored-onion.gif


Was mich wirklich verrückt macht, ist, daß ich seit meinem ersten Job weiß, daß ich als Entwickler ungefähr zwei oder drei Stunden am Tag produktiv programmiere. Als ich im Sommer einen Ferienjob bei Microsoft hatte, erzählte mir ein Kollege, daß er jeden Tag tatsächlich nur von 12 bis um 5 zur Arbeit kommt. Fünf Stunden abzüglich Mittagessen, und sein Team liebte ihn, weil er trotzdem viel mehr zustande brachte als der Durchschnitt. Ich habe das Gleiche herausgefunden. Ich habe ein schlechtes Gewissen, wenn ich sehe, wie schwer alle anderen zu arbeiten scheinen, und ich arbeite ungefähr zwei bis drei Stunden richtig, und trotzdem bin ich eines der produktivsten Mitglieder des Teams gewesen. Das ist wahrscheinlich der Grund, warum Peopleware ("Wien wartet auf Dich") und XP (Extreme Programming) darauf bestehen, Überstunden abzuschaffen und genau 40 Stunden pro Woche zu arbeiten: weil sie ganz genau wissen, daß dies die Leistung des Teams nicht verringert.

Aber ich mache mir nicht über die Tage Sorgen, an denen ich "nur" zwei Stunden arbeite. Es sind die Tage, an denen ich gar nichts tue.

Ich habe viel darüber nachgedacht. Ich habe versucht, mich an die Zeit zu erinnern, als ich die meiste Arbeit in meiner Karriere erledigt habe. Das war wahrscheinlich zu der Zeit, als Microsoft mir ein wunderschönes, luxuriöses Büro gegeben hat mit großen Panoramafenstern mit Blick auf einen schönen, mit Steinen gepflasterten Hof voll von blühenden Kirschbäumen. Alles machte "Klick". Monatelang habe ich rund um die Uhr gearbeitet und die Detailspezifikation für Excel Basic ausgearbeitet -- eine monumentale Schwarte mit unglaublich vielen Details über ein gigantisches Objektmodell und eine Entwicklungsumgebung. Ich habe buchstäblich nie aufgehört. Als ich nach Boston zur MacWorld fliegen mußte, nahm ich einen Laptop mit und dokumentierte die Window-Klasse, während ich auf einer netten Terasse nahe der Harvard Business School (HBS) saß.

Wenn man einmal in Fluß gekommen ist, ist es nicht so schwer, weiterzumachen. Viele meiner Tage sehen so aus: (1) Zur Arbeit gehen (2) nach meiner Email schauen, im Web lesen usw. (3) eigentlich könnte ich genausogut mittagessen, bevor ich anfange zu arbeiten (4) vom Mittagessen zurückkommen (5) nach meiner Email schauen, im Web lesen, usw. (6) mich endlich dazu aufzuraffen, etwas zu arbeiten (7) nach meiner Email schauen, im Web lesen, usw. (8) jetzt muß ich aber wirklich mit der Arbeit anfangen (9) den verdammten Editor starten und (10) ohne Unterbrechung programmieren bis weit über halb acht hinaus.

Bike-trip.jpg

Irgendwo zwischen Schritt (8) und Schritt (9) scheint ein Fehler zu sein, weil ich es nicht immer über diese Kluft schaffe. Einfach anzufangen ist die einzige schwere Sache für mich. Ein Gegenstand im Ruhezustand neigt dazu, im Ruhezustand zu bleiben. Es gibt da irgendwas unglaublich Schweres in meinem Gehirn, das schwer in Bewegung zu bringen ist, aber wenn es einmal mit voller Geschwindigkeit läuft, braucht es keine Anstrengung, es am Laufen zu halten. Wie bei einem Fahrrad, das für einen längeren Ausflug übers Land gepackt ist -- wenn man mit dem vollgepackten Fahrrad losfährt, ist es kaum zu glauben, wie anstrengend es ist, es ins Rollen zu bringen, aber wenn man einmal fährt, fühlt es sich genauso leicht an wie bei einem Fahrrad ohne irgendwelche Ausrüstung.

Vielleicht ist das der Schlüssel zur Produktivität: einfach anfangen. Vielleicht funktioniert Programmieren zu zweit ja deswegen, weil jeder den anderen dazu zwingt, anzufangen, wenn man eine solche Sitzung für das Programmieren zu zweit vereinbart.

ARMY-wee.JPG

Als ich ein israelischer Fallschirmjäger war, schaute ein General vorbei, um eine kleine Rede über Strategie für uns zu halten. Bei Kämpfen der Infanterie, erzählte er uns, gibt es nur eine Strategie: Schießen und bewegen (Angriff ist die beste Verteidigung). Du bewegst dich zum Feind hin, während Du mit Deiner Waffe schießt. Der Kugelhagel zwingt ihn dazu, seinen Kopf unten zu halten, so daß er nicht auf Dich schießen kann. (Das meinen die Soldaten, wenn sie "Gib mir Deckung!" rufen. Damit ist gemeint: "Schieß auf unseren Feind, damit er sich ducken muß und nicht auf mich schießen kann, während ich über diese Straße hier renne." Es funktioniert.) Die Bewegung macht es möglich, ein Gebiet einzunehmen und näher an Deinen Feind heranzukommen, wo Deine Schüsse viel eher das Ziel treffen. Wenn Du Dich nicht bewegst, kann der Feind entscheiden, was passiert. Das ist nicht gut. Wenn Du nicht schießt, schießt der Feind auf Dich und hält Dich unten.

Das habe ich mir gründlich eingeprägt. Ich habe beobachtet, wie fast jede Art von militärischer Strategie, angefangen bei Luftkämpfen bis zu groß angelegten Schiffsmanövern, auf der Idee von Schießen und Bewegen aufbaut. Ich habe weitere fünfzehn Jahre gebraucht, um zu erkennen, wie man mit Hilfe des Prinzips vom Schießen und Bewegen sein Leben bewältigt. Du mußt Dich ein bischen bewegen, jeden Tag. Es spielt keine Rolle, ob Dein Code langsam und fehlerhaft ist und niemand ihn haben will. Wenn Du Dich vorwärts bewegst, ständig programmierst und Fehler behebst, ist die Zeit auf Deiner Seite. Paß auf, wenn Deine Konkurrenz auf Dich schießt. Wollen sie Dich nur damit beschäftigen, auf ihre Salven zu reagieren, damit Du Dich nicht vorwärts bewegen kannst?

Denk an die zurückliegenden Datenzugriffsstrategien von Microsoft. ODBC, RDO, DAO, ADO, OLEDB, und jetzt ADO.NET -- alle neu! Sind das etwa technologische Imperative? Das Ergebnis einer unfähigen Designgruppe, die das Thema Datenzugriff jedes gottverdammte Jahr neu erfinden muß? (Das ist es wahrscheinlich tatsächlich.) Das Endergebnis ist einfach nur Deckungsfeuer. Die Konkurrenz hat keine andere Wahl als die gesamte Zeit in die Portierung und Aktualisierung zu stecken, Zeit, die sie nicht haben, um neue Dinge zu entwickeln. Schau mal genau auf die Software-Landschaft. Die Firmen, denen es gut geht, sind die, die sich am wenigsten auf große Firmen verlassen und die nicht die ganze Zeit damit verbringen, aufzuholen und alles neu zu programmieren und Fehler zu beheben, die nur in Windows XP auftauchen. Die Firmen, die stolpern, sind die, die zu viel Zeit damit verbringen, im Kaffeesatz zu lesen, um die zukünftige Strategie von Microsoft herauszufinden. Die Leute sind besorgt über .NET und entscheiden sich dazu, ihre ganze Architektur für .NET umzuprogrammieren, weil sie denken, sie müßten das tun. Microsoft schießt auf Dich und es ist bloß Deckungsfeuer, damit sie sich bewegen können und Du nicht, weil das Spiel so gespielt wird, Bubby. Wirst Du Hailstorm unterstützen? SOAP? RDF? Unterstützt Du das, weil Deine Kunden das brauchen oder weil jemand auf Dich feuert und Du meinst, antworten zu müssen? Die Marketing-Teams der großen Firmen wissen, wie man mit Deckungsfeuer umgeht. Sie gehen zu ihren Kunden und sagen "OK, Sie brauchen nicht von uns zu kaufen. Kaufen Sie vom besten Hersteller. Aber stellen Sie sicher, daß Sie ein Produkt bekommen, das (XML / SOAP / CDE / J2EE) unterstützt, sonst sind Sie quasi im Kofferraum eingeschlossen." Und wenn die kleinen Firmen versuchen, diesem Kunden etwas zu verkaufen, ist alles, was sie von gehorsamen CTOs zu hören bekommen, Geplapper wie "Haben Sie J2EE?". Und sie müssen ihre Zeit damit verschwenden, J2EE nachzuprogrammieren, auch wenn es nicht wirklich zu den Verkaufszahlen beiträgt, und sie haben keine Möglichkeit, sich von anderen Firmen abzusetzen. Es ist eine Eigenschaft zum Abhaken -- man macht es, damit man einen Haken dahinter setzen kann, um sagen zu können, daß man es hat. Aber niemand benutzt oder braucht es jemals. Und es handelt sich um Deckungsfeuer.

Schießen und Bewegen bedeutet zweierlei für kleine Firmen wie meine: Du mußt einen Zeitvorsprung haben und Du mußt Dich jeden Tag vorwärts bewegen. Früher oder später wirst Du gewinnen. Alles, was ich gestern erreicht habe, ist, das Farbenschema von FogBUGZ ein bischen zu verbessern. Das geht in Ordnung. Es wird immer besser. Jeden Tag wird unsere Software besser und besser und wir bekommen mehr und mehr Kunden und das ist alles, was zählt. Solange wir nicht eine Firma von der Größe wie Oracle sind, brauchen wir nicht über eindrucksvolle Strategien nachzudenken. Wir müssen nur jeden Morgen ins Büro kommen und irgendwie den Editor anwerfen.

Editing.gif

Personal tools