Joel warnt: Menschliches Multitasking schadet ...

Das Erste, was du zu lernen hast, wenn du ein Team von Programmierern leitest, ist, Aufgaben zuzuweisen. Es geht also darum, Leuten etwas zu tun zu geben. (Man könnte es auch "Papier entsorgen" nennen - wir laden schließlich Stapel von Papier auf anderer Leute Schreibtisch ab.) Die Entscheidung aber, welche Mappe auf welchem Schreibtisch zu entsorgen ist, ist das Gebiet, auf dem du erstaunliche Produktivitätsgewinne realisieren kannst, wenn du es richtig anstellst. Mach' es verkehrt, und du erzeugst einen jener unruhigen Zustände, in denen niemand etwas zustande bringt und jeder nur darüber klagt, dass "hier einfach nichts weiter geht".

Da das hier nun mal eine Internetplatform für Programmierer ist, will ich eure Gehirne mal mit einem Programmierproblem ankurbeln.

Mal angenommen, es sind zwei getrennte Berechnungen, A und B, durchzuführen. Beide brauchen jeweils 10 CPU-Sekunden. Die dafür verfügbare CPU hat darüberhinaus nichts zu tun.

Unsere CPU kann auch Multitasking. Also kann man die zwei Berechnungen entweder nacheinander durchführen ...

Sequentielle Verarbeitung

... oder man arbeitet im Mehrprogrammbetrieb. Auf dieser speziellen CPU soll das heißen, jede Aufgabe wird immer wieder 1 Sekunde lang bearbeitet, und das Umschalten zwischen den Aufgaben verbraucht keine Zeit.

Multitasking

Wie würdest Du entscheiden? Die meisten von uns würden aus dem Bauch heraus urteilen: Multitasking ist besser. In beiden Fällen wartet man 20 Sekunden bevor man beide Antworten bekommen hat. Aber überleg' nochmal, wie lange jede einzelne Berechnung dauert.

In beiden Fällen verbraucht die Berechnung B (blau) 20 Sekunden. Schau' Dir jetzt mal Berechnung A an. Im Mehrprogrammbetrieb läuft sie 19 Sekunden ... bei der sequentiellen Verarbeitung aber ist sie schon nach 10 Sekunden fertig.

Mit anderen Worten: In diesem hübschen, konstruierten Beispiel ist die durchschnittliche Zeit für eine Berechnung bei sequentieller Verarbeitung kürzer als bei Multitasking: 15 gegenüber 19,5 Sekunden. (Es ist übrigens kein konstruiertes Beispiel, es geht auf ein reales Problem zurück, das Jared bei uns zu lösen hatte.)

Weiter oben habe ich behauptet: "das Umschalten zwischen den Aufgaben verbraucht keine Zeit". Tatsächlich aber brauchen reale CPUs für das Umschalten ein wenig Zeit ... Im Wesentlichen ist das die Zeit zum Sichern der Registerinhalte der einen und Laden der gesicherten Registerinhalte der anderen Aufgabe. Realistisch betrachtet sollte man das eigentlich vernachlässigen. Um's interessanter zu machen, stellen wir uns vor, das Umschalten würde ein halbe Sekunde dauern. Jetzt sieht Multitasking noch älter aus.

Und jetzt... nur mir zuliebe - ich weiß, das ist Unsinn: Was, wenn Umschalten jeweils eine ganze Minute bräuchte?

Je länger das Umschalten dauert, desto härter die Strafe für's Multitasking.

Für sich alleine betrachtet, ist diese Erkenntnis nicht garade weltbewegend, oder? In Kürze werde ich wieder zornige E-Mails von irgendwelchen Trotteln bekommen, die meinen, ich wäre "gegen" Multitasking: "Willst Du vielleicht DOS zurückhaben, wo man WordPerfect verlassen musste, um 1-2-3 aufzurufen?" Das ist nicht der Punkt! Ich möchte lediglich Euer Einverständnis dafür, dass für ein Beispiel wie oben gilt:

a) sequentielle Verarbeitung liefert im Durchschnitt schnellere Ergebnisse, und

b) je länger das Umschalten dauert, umso größer ist die Zeitstrafe für's Multitasking.

Nun gut, lassen wir die CPUs und gehen zurück zu dem interessanteren Thema Menschen. Entscheidend insbesondere bei Programmierern sind ihre extrem langen Schaltzeiten. Das liegt an der Art der Aufgabe, die verlangt, sehr viele verschiedene Dinge gleichzeitig im Gedächnis parat zu haben. Je mehr Dinge Du sofort erinnern kannst, desto produktiver bist Du beim Programmieren. Ein Programmierer unter Volldampf hat Myriaden Sachen gleichzeitig im Kopf: angefangen bei Variablennamen über Datenstrukturen, wichtige APIs, die Namen selbst programmierter und häufig genutzter Hilfsfunktionen bis hin zum vollen Verzeichnisnamen für das Speichern des Quellkodes. Wenn Du diesen Programmierer für drei Wochen Urlaub nach Kreta schickst, wird er das vergessen, alles! Unser Gehirn scheint es aus dem Kurzzeit-RAM auf ein Sicherungsband auszulagern, von wo es nur mit riesigem Zeitaufwand zurückgeholt wird.

Wie lange dauert das? Naja, in meiner Software Firma haben wir kürzlich unsere laufende Arbeit - wir entwickeln gerade neue Software mit dem Kodenamen CityDesk - unterbrochen, um einem Kunden in einer Notsituation drei Wochen lang auszuhelfen. Zurück an unserem Arbeitsplatz schien es nochmal drei Wochen zu dauern, ehe wir an CityDesk wieder mit vollem Tempo entwickelten.

Was einzelne Personen angeht - hast Du schon einmal bemerkt, dass, wenn du einer Person einen Job zuweist, die das supergut erledigt, wenn Du dieselbe Person aber mit zwei Aufgaben betraust, nichts wirklich gut wird? Sie macht entweder den einen Job und vernachlässigt den zweiten, oder sie tut beides so langsam, dass man meint eine Schnecke könnte sie überholen. Das liegt daran, dass Programmieraufgaben lange Schaltzeiten haben. Wenn mir gleichzeitig zwei Programmierprojekte auf dem Tisch liegen, dann liegt die Schaltzeit bei gefühlten 6 Stunden. Für einen 8-Stunden-Tag reduziert das die produktive Zeit auf 2 Stunden. Traurig, nicht wahr?

Ergebnis: Wenn Du jemandem zwei Dinge zum abarbeiten gibst, dann solltest Du dankbar sein, wenn sie eine Aufgabe schleifen lässt und nur an der anderen arbeitet, denn auf die Art wird sie mehr erledigen und die Aufgaben im Schnitt früher fertigstellen. Die eigentliche Erkenntnis ist: Lass deine Leute nie gleichzeitig an mehreren Aufgaben arbeiten. Mach' klar, was die Aufgabe ist. Gute Manager sehen ihre Aufgabe darin, Hindernisse zu beseitigen, so dass ihre Leute sich auf eine Sache konzentrieren können, und die dann gut erledigen. Wenn Notfälle auftreten, überlege zuerst, ob Du es nicht alleine in den Griff kriegst, bevor Du es an einen Programmierer delegierst, der tief in einem Projekt steckt.