Ich bin nicht sicher, dass ich es auf einen einzigen Grund reduzieren kann. Ich denke Produktivität ist das Produkt der Optimierung eines sehr komplexen multidimensionalen Raumes. Ich werde ein paar der Achsen dieses Raumes aufzählen, aber es wird sicher keine vollständige Liste werden.

Vor langer Zeit, als ich am MIT AI Lab war, und Patrick Winston noch der Direktor, kam Pat in mein Büro und schaute mir zu, wie ich vor mich hintippte. "Kent", sagte er (und ich erzähle natürlich aus dem Gedächtnis, da seit der Konversation viel Zeit vergangen ist), "in deinem Leben wirst du wahrscheinlich dreimal soviel erreichen wie ich, einfach nur weil du dreimal so schnell tippst wie ich." Ich weiss nicht, ob das eine wirklich faire Beurteilung war, aber ich denke schon, dass an diesem Kriterium etwas dran ist. Kompetenz ganz unten bei der einfachen mechanischen Manipulation des Computerinterfaces, sowohl beim Tippen wie auch bei den Textverarbeitungstools. (Ich benutze Emacs, nicht wegen der dummen Politik bzgl. open source, sondern weil er seit langem die Blindschreiber befähigt anstatt der langsamen "point and click" Gemeinde um den Bart zu streichen).

Ein "Typ A" zu sein hilft auch. Für mich bedeutet es, dass man immer mehr als nur eine Sache gleichzeitig machen muss. Ich sehe Fern (in der Regel Nachrichten- oder Informationssendungen), während ich arbeite, abgesehen von seltenen Fällen, wenn ich mich mit Hintergrundlärm nicht konzentrieren kann. Also nehme ich die ganze Zeit Informationen auf, während ich arbeite. Ich habe in der Regel keine Zeit zum Lesen und ich lese soviel online, dass ich es nicht mehr als entspannende Freizeitaktivität ansehe. Jedoch höre ich Buchkassetten wenn ich im Auto herumfahre. Manchmal ist es Prosaliteratur, für die ich auf andere Art keine Zeit hätte. Manchmal ist es Lernmaterial.

Ich bin mir auch der Parallelität in meinem Leben sehr bewusst. Angenommen ich muss zwei Aufgaben erledigen: das Geschirr waschen und eine Email versenden. Es ist wichtig, die Email zuerst zu versenden. Warum? Es könnte sein, dass, wenn ich mit dem Geschir fertig bin, schon eine Antwort da ist. Wenn ich die Dinge andersherum erledige, dann wartet sicher noch keine Antwort auf mich (da ich die Mail noch nicht geschickt habe). Indem ich Ereignisse umschichte, kann ich den Durchsatz erhöhen, ohne zusätzliche Arbeit zu erledigen.

Man sollte immer mehrere Aufgaben haben, an denen man arbeiten kann. Vor einigen Jahren war ich bei einem Talk von Isaac Asimov, bei dem er die gleiche Beobachtung machte. Er sagte, dass er es hasse, an dem zu arbeiten, woran er arbeiten sollte. Deshalb platzierte er an strategisch günstigen Stellen Dinge, die auch wichtig waren, und wenn seine Augen dorthin wanderten, um etwas zu suchen, das er nicht machen sollte, würde er zumindest andere Dinge finden, die auch gemacht werden mussten. Und letzendlich würde alles erledigt werden. Man kann auch manche Sache nicht die ganze Zeit über bearbeiten. Wenn ich eine grosse Schreibaufgabe habe, versuche ich ein weiteres Projekt einer anderen Art zu finden (z. B. Programmieren), um es damit zu verbinden. Es durchbricht die Monotonie. Wenn man keine solchen Techniken bennutzt verschwendet man lustlose Zeit, und diese Zeit kann man nie wieder einholen.

Ich bevorzuge Lisp, vor allem weil es die biegsamste Sprache ist. Lisp hat viele vorgefertigte Features, die ich mag, und wenn ich eines gerade nicht brauchen kann, kann ich es in etwas anderes umwandeln.

In den meisten Sprachen dominiert der Charakter der Sprachsyntax die eigenen Ausdrucksmöglichkeiten, und man ist eingeschränkt.

Jede Sprache, sogar Lisp, macht irgendetwas falsch. Oder vielleicht ist es auch nur, dass eine bestimmte Syntax nicht immer richtig sein kann. Aber Lisp gibt mir die besten Möglichkeiten, diese Schwächen zu überwinden.

Es gibt viele Dinge, die ich an Lisp mag, aber wesentlich ist, dass die Sprache ausdrücken kann "was ich machen will" und nicht "wie ich es machen will". Die meisten Sprachen konzentrieren sich auf die Implementation. Sie verlangen ein exaktes Datenlayout, in dem man jedes Bit kontrollieren kann. Das ist so, als ob der Präsident eines multinationalen Konzerns jeder Schreibkraft bei der Arbeit über die Schulter schauen wollte. Um ein komplexes Projekt von einer höheren Warte aus zu beurteilen, muss man die Detailkontrolle abgeben, was mich Lisp besser als andere Sprachen tun lässt.

Ich denke nicht, dass die Welt auf irgendeinen größeren Produktivitätssprung zusteuert, wie ich ihn vor zehn Jahren erwartet hätte.

Wir werden hauptsächlich durch immer schnellere Prozessoren produktiver, und nach meinem Gefühl ist es so schwierig durch "Schlauheit" die rohe Rechenleistung eines schnelleren Computers zu übertreffen (vielleicht bis wir die Grenze erreichen, wo die Lichtgeschwindigkeit den Leistungszuwachs ausbremst), dass die strategische Produktivitässteigerung eine vergessene Kunst wird. Es ist genug, schnellere Hardware zu kaufen.

Die Software, die auf diese Maschinen läuft, scheint mir aber immer schlechter zu werden. Aber vielleicht liegt das auch an mir. Vielleicht bin ich mit einer anderen Architektur groß geworden, und es gibt Menschen, denen die moderne Architektur zusagt. Egal, wie mausfreundlich alles wird, ich verstehe nicht, warum ein Profi die Zeit aufwenden sollte, um die Finger von der Tastatur zu nehmen, die Maus ein Stück zu verschieben und einen Knopf zu drücken, wenn man nur ein paar Tasten drücken muss. Aber Schreibgeschwindigkeit und ein reines Tastaturinterface sind bei modernen Umgebungen kaum mehr wichtig.

Auch in der Compilertechnologie sind die Zugewinne so klein, dass sie neben den Verbesserungen der Hardware verblassen.

Ich sehe zwei Arten von Problemen: Beschränkungen der Vorstellungskraft und des Budgets.

Mit beschränkter Vorstellungskraft meine ich das Unvermögen des Managements, zu verstehen, was ein Programmierer tut und wozu er fähig ist. Manager machen deswegen zwei Fehler: Sie stellen unvernünftige Forderungen an die Programmierer und sie halten Programmierer davon ab, vernünftige Dinge zu tun. Beides kann sehr bedauerlich sein.

Knapp dahinter kommt die Unfähigkeit der Programmierer, zu sehen, was sie tun können (oder können sollten). Als ich Programmieren lernte, war jeder ein Generalist und den Leuten wurde Programmieren von Grund auf als problemlösende Tätigkeit beigebracht. Heute ist es für viele einfacher, Programmieren zu lernen, aber was mit Programmieren gemeint ist, ist nicht das gleiche. Heute meint man mit "Programmieren" oft nur die Fähigkeit, mit Visual Basic oder Javascript ein UI zu erzeugen, aber diese "Programmierer" können kaum etwas anderes ... besonders dann, wenn es kein vorgefertigtes Interface dafür gibt.

Zum Budget muss ich sagen, dass der Open Source Markt meiner Meinung nach die größte Gefahr für den Fortschritt der Informatik ist. Durch das Verschenken von Technologie wird der Preis von allem gedrückt. Dadurch ist es schwierig, einen angemessenen Preis für Software zu erzielen, weshalb weniger Geld für die Bezahlung der Programmierer zur Verfügung steht, wenn es überhaupt bezahlt wird. Die freie Marktwirtschaft presst jeden verfügbaren Dollar aus dem heraus, der es zulässt, und wenn sie feststellt, dass Leute umsonst programmieren, wird sie sicherstellen, dass niemand mehr für Programmieren bezahlt wird.

Außerdem denke ich, dass es meistens die jüngeren und beeinflussbaren idealistischen Programmierer sind, die der Open Source Rhetorik Glauben schenken, während sie noch in der Ausbildung auf der Höhe ihrer Schaffenskraft glauben, dass ein paar Dollar extra unmoralisch sind. Später, wenn man dann gerne etwas mehr Zeit für die Familie hätte, oder krank wird, oder etwas wohltätigen Zwecken stiften möchte, spürt man den wahren Preis dafür, in seiner Jugend so viel verschenkt zu haben, aber dann kann man es nicht mehr zurückbekommen.

Da es immer wieder junge Leute gibt, geht auch die Bewegung um kostenlose Software weiter. Dabei schnürt sie aber den Lebenssaft aus Dollars von einer Gruppe ab, die zusätzliches Geld für eine Investition in die Zukunft verwenden könnte. Da statt dessen ihr eigenes Dogma vorschreibt, dass Programmierer wie Landarbeiter nur für die tagsüber geleistete Arbeit bezahlt werden, gibt es keine Gelegenheit für zukünftiges Wachstum, für Experimente, nicht einmal für menschliche Fehler, Krankheit oder andere nicht projekt-relevante Dinge. Programmierer werden als ersetzbare Rädchen betrachtet und nicht entsprechend gewürdigt, denn das Management schätzt nur, wofür es teuer gezahlt hat, und es ist nicht gezwungen teuer zu bezahlen.

Damit will ich nicht sagen, dass ich niemals ein Programm verschenkt hätte. Aber ich glaube nicht daran, dass so etwas eine Lebenseinstellung sein sollte.

Das scheint mir nicht so revolutionär zu sein, vielleicht, weil ich lange im AI-Bereich tätig war. Generatives Programmieren, Datenmodellierung, Metaprogrammierung, Automatische Programmierung, aspektorientiertes Programmieren, das haben wir alles schon lange Zeit gemacht.

Ich bin sicher, dass diese Techniken produktiv gewesen sind und auch bleiben, wenn wir mehr Arbeit vom Menschen auf den Computer übertragen wollen.

Andererseits, habe ich einige ethische Bedenken, dass solche Werkzeuge schließlich einen Teil des Programmiererbedarfs zumindest in bestimmten Bereichen ersetzen werden und somit Arbeitsplätze vernichten. Ich würde es gerne sehen, wenn man sich hier darauf konzentrieren würde, dass neue Arbeitsplätze geschaffen werden.

Es wird immer neue Grenzen geben, aber ob sich die Wirtschaft für diese interessieren wird, kann ich nicht sagen. Einige dachten, dass Schach computermäßig nicht beherrschbar sei, aber das stimmt nachweisbar nicht mehr. Einige denken wahrscheinlich, "was Programmierer machen" ist nicht automatisierbar, aber ich vermute, dass diese Annahme ebenso fallen wird.

Wenn andererseits die Freie Software gewinnt und Programmierer ihre Software verschenken und keinen entsprechenden Gegenwert erhalten, könnte ein automatisierter Ersatz einen schnellen Gnadentod für den zum Großteil nutzlosen "Beruf des Programmierers" sein.

Ich denke auch, dass diese Werkzeuge bald eine interessante Entwicklung in Firmen auslösen werden. Vor ein paar Jahren hat HP (in Zusammenhang mit eSpeak) angekündigt, die Zeit zwischen Produktidee und Realisierung auf wenige Stunden verkürzen zu wollen. Das einzige Problem mit dieser Idee ist, dass ein Produkt aus mehr als nur Programmierung besteht; da gibt es juristische, marketingtechnische, dokumentatorische Angelegenheiten usw. Das braucht alles Zeit, die bisher durch die lange Programmierzeit dominiert wurde. Wenn die Entwicklung aber schneller wird, werden einige dieser Bereiche die neuen Flaschenhälse. Vielleicht wird es einen strengeren Ansatz für Dokumentation oder juristische Angelegenheiten geben, um mit der schnellen Realisierung Schritt halten zu können. Ich weiß nicht, wo das hinführt, aber ich bin ziemlich sicher, dass es eine Rolle spielen wird.