Stack-Overflow-Gründer Joel Spolsky: "Dokumentation ist ein Mythos"

Joel Spolsky erklärt im Interview, was er über Copy-and-Paste-Lösungen und Dokumentation denkt und was New Yorks Verkehrschaos mit Stack Overflow zu tun hat.

In Pocket speichern vorlesen Druckansicht 123 Kommentare lesen
Stack-Overflow-Gründer Joel Spolsky: "Dokumentation ist ein Mythos"
Lesezeit: 12 Min.
Von
  • Herbert Braun

Auf der Berliner Konferenz WeAreDevelopers sprachen wir Anfang Juni mit Joel Spolsky. Er ist Gründer des Unternehmens Glitch (ursprünglich Fog Creek Software), das unter anderem den gleichnamigen Online-Editor, das Projekt-Management-Werkzeug Trello und vor allem Stack Exchange auf den Weg gebracht hat. Letzteres ist ein Netzwerk von gut 170 Frage-und-Antwort-Websites, dessen erster und prominentester Vertreter Stack Overflow ist, die vielleicht wichtigste Website für Entwickler.

Stack Overflow entstand ursprünglich als Gegenentwurf zu Experts Exchange, einer Seite mit ähnlicher Ausrichtung, von deren Geschäftsmodell Spolsky allerdings genervt war. Unter anderem weil die Fragen und Antworten zwar über Google auffindbar, aber in der Regel nicht kostenlos einsehbar waren. Als sich über Jahre niemand der – nach Spolskys Meinung sehr einfach lösbaren – Situation annahm, gründete er 2008 Stack Overflow, zusammen mit dem Entwickler und Blogger Jeff Atwood. Details zu seinen Beweggründen und welche anderen Verbesserungen neben dem Geschäftsmodell Stack Overflow gegenüber seinen Vorgängern einführte, erläutert Spolsky ausführlich in seinem Blog Joel on Software.

Relativ schnell wurde Stack Overflow zu der Anlaufstelle für Programmierer schlechthin. In den mittlerweile über 17 Millionen Fragen finden sich Erklärungen zu fast jedem Problem. Viele Suchmaschinen binden passende Stack-Overflow-Antworten direkt in ihre Suchergebnisse ein, und für so manchen Programmierer ist die Website aus dem Alltag nicht mehr wegzudenken.

Joel Spolsky, Co-Gründer von Stack Overflow, programmiert gerne Arduinos in C: "Da fragt man sich nie: Manipuliere ich diesen String auf die bestmögliche Art, denn es gibt keine gute Art."

(Bild: Stack Overflow)

c’t: Entwickler benutzen ja ständig Stack Overflow. Hat das einen Einfluss auf den Code? Führt das zu einem Copy-Paste-Programmierstil?

Joel Spolsky: Ja, es gibt den Typ Entwickler, der fertigen Code kopiert und hofft, dass er funktioniert. Ich mache das auch oft, aber ich gehe den Code Zeile für Zeile durch, um ihn zu refaktorieren oder wenigstens zu formatieren und um sicherzugehen, dass ich ihn verstehe. Code zu kopieren ist wie eine Bibliothek zu benutzen, nur dass man sie nicht verlinkt. Manche Leute regen sich darüber auf: Wenn du Code benutzt, den du nicht verstehst, holst du dir Sicherheitsrisiken ins Projekt … Das muss jeder selbst entscheiden. Viele Artikel kritisieren bestimmte Programmierstile, ohne zu verstehen, dass es verschiedene Programmierwelten und Anforderungen gibt und dass jeder Programmierer für seine eigene Situation optimiert.

c’t: Sie persönlich wollen also den Code komplett verstehen, den Sie schreiben, finden es aber völlig okay, wenn jemand anders vorgeht.

Spolsky: Ja. Und die Hälfte der oft verspotteten Copy-und-Paste-Entwickler sucht nur Lösungen für die Schule oder Universität. Man kann da leicht in quasi-religiöse Streitigkeiten geraten.

c’t: Sie decken mit Stack Overflow die Bedürfnisse der Entwickler ziemlich erfolgreich ab. Haben Sie da noch Ziele und Pläne?

Spolsky: Viele Probleme, die Entwickler heute haben, werden auf Stack Overflow nicht beantwortet. Der Grund: Diese Fragen beziehen sich auf die Codebase eines Unternehmens, die vielleicht seit Jahrzehnten gewachsen ist. Ich glaube, Programmieranfänger oder Leute, die neue Projekte starten, finden für jede Frage auf Stack Overflow eine Antwort – und falls nicht, wird sie jemand in 30 Sekunden geben. Entwickler, die in einer großen Organisation arbeiten, beherrschen dagegen die Grundlagen ihres Handwerks. Zu kämpfen haben sie eher mit proprietärem Code. Für Informationen sind sie auf Kollegen angewiesen, von denen manche vielleicht nicht mehr im Unternehmen arbeiten.

Kennt fast jeder Entwickler: Stack Overflow. Die gezeigte Frage ist natürlich viel zu subjektiv, um echt zu sein; das Interview fand ganz klassisch statt.

In den 90er-Jahren, vor Java, war in der Windows-Programmierung COM sehr verbreitet. Viele haben es benutzt, aber niemand wollte es lernen, weil es so kompliziert war. Später standen Leute, die COM-Code schreiben konnten, trotz hoher Gehälter kaum zur Verfügung. Falls es heute noch welche gibt, wollen sie COM wahrscheinlich nie wieder sehen … Es gibt also niemanden mehr, der diesen alten Code noch warten kann. Das Wissen ist weg, eine brauchbare interne Dokumentation existiert nicht – niemand will Dokumentation schreiben oder lesen, sie ist oft schlecht, nicht auf dem aktuellen Stand oder unauffindbar. Dokumentation ist ein Mythos.

»Produktivität verbessert man am besten, indem man Komplexität verringert.«

Was besser funktioniert, ist ein Frage-und-Antwort-System. Im Stack-Overflow-Format kann man diese Fragen und Antworten aufbewahren, bearbeiten und durchsuchen und die Reputation von Personen erfahren. Das ist der beste Weg, um das zu dokumentieren, was man wirklich braucht. Wir haben deshalb jetzt drei Versionen von Stack Overflow, die wir verkaufen, für unterschiedliche Unternehmensgrößen: Teams, Business, Enterprise. Statt eine standardisierte Dokumentation zu beauftragen, muss ein Unternehmen nur sicherstellen, dass der Wissensfluss durch diese proprietären Plattformen läuft.

c’t: Letztes Jahr haben Sie im Interview gesagt, dass fast jede Programmiersprache auf Stack Overflow vertreten ist außer COBOL – weil es damit nur proprietären Code gibt?

Spolsky: Ja, könnte sein. COBOL ist interessant, weil es so weit in der Zeit zurückreicht. Es gibt ja den Trend, nur das zu lernen, was man gerade braucht. Das Gegenteil davon ist, dass man alles vorher lernt, eine lange Ausbildung durchläuft und keine Fragen hat, weil man alles im Kopf hat. Als IBM COBOL eingeführt hat, gingen die Entwickler auf monatelange Schulungen. Das war 60er-Jahre Ingenieurswesen: Man lernt jahrelang, bevor man irgendetwas anfassen darf.

c’t: Es haben sich also nicht nur die Werkzeuge und die Art der Projekte geändert, sondern auch die Haltung der Entwickler hat sich in Richtung Learning by doing gewandelt?

Spolsky: Ich glaube, ja. Ich halte das nicht für einen bloßen Trend, denn so läuft das auch auf anderen Gebieten, zum Beispiel Musik. Niemand kommt auf die Idee, erst mal ein Jahr Bücher übers Klavierspielen zu lesen, bevor er damit anfängt: Man drückt ein paar Tasten und übt. Nur im Ingenieurswesen hat man es zuerst anders versucht.

Für Haushaltsgeräte gibt es auch heute meist noch ein Handbuch, das suggeriert: Wenn du das gelesen hast, kannst du das Gerät bedienen. Das iPhone hatte nur eine Seite Anleitung dabei, obwohl es damals das vielseitigste Werkzeug der Menschheit war. Es gab nie die Annahme, dass man die Bedienung vorher lernen könnte. Mein Vater hatte früher einen teuren HP-35-Taschenrechner mit trigonometrischen und logarithmischen Funktionen. Das Handbuch hatte 150 Seiten; allein fünf davon erklärten, wie man einen Logarithmus berechnet. Ich erinnere mich, wie ich als Kind versucht habe, dieses Handbuch zu lesen, um magische Dinge mit diesem Taschenrechner zu tun …

c’t: Manche Leute vermissen diese Art von Handbüchern – ältere oder nicht so technisch versierte.

Spolsky: Wenn jemand ein Handbuch braucht, bevor er anfängt, ein Gerät zu benutzen, ist das auch ein Problem mit der Benutzerführung. Ich erinnere mich noch, dass es beim iPhone mit einem Button losging. Alles war klar und einfach. Dann kam jedes Jahr etwas Neues dazu: Screenshots, Schlafmodus, Copy und Paste, Swipe-Gesten, Gesichtserkennung … Smartphones sind so dominant, dass sehr viele Menschen diese Dinge nacheinander gelernt haben. Würde man ein heutiges iPhone zehn Jahre in der Zeit zurückschicken, wäre es zu kompliziert.

c’t: Ist das auch für Entwickler ein Problem, dass Tools und Sprachen mit der Zeit immer komplexer werden?

Spolsky: Wenn ich auf vierzig Jahre als Programmierer (oder so was Ähnliches) zurückschaue, kann ich nur sagen: Produktivität verbessert man am besten, indem man Komplexität verringert. Man beginnt mit einer simplen Sprache, dann findet man eine Bibliothek, mit der man ein paar Zeilen Code einsparen oder ein neues Feature umsetzen kann. Dadurch hat sich aber die Zahl der Dinge, die der Programmierer im Kopf behalten muss, um eins vergrößert – und die Zahl der Interaktionen um N oder N2.

Letztens habe ich versucht, ein GPS-Gerät auszulesen, das einen String zurückgibt. Heute nimmt man für das Parsen eine Library. Ich lud mir eine Bibliothek herunter und fand sie buggy. Schließlich habe ich den Code selbst geschrieben – das Ergebnis passt in ein paar Zeilen, läuft sehr schnell und ich verstehe den Code. Dieser Erkenntnisgewinn macht dich effizient als Programmierer, statt deine Zeit damit zu vergeuden, alle möglichen Bibliotheken verstehen zu müssen und dich um Abhängigkeiten und Updates zu kümmern.

c’t: Letztes Jahr sagten Sie in einem Interview mit einem Kollegen allerdings, dass Entwickler heute auf höherem Niveau beginnen und dadurch manche Probleme sehr schnell lösen.

Spolsky: Mit den richtigen Werkzeugen ist natürlich viel möglich. Ich denke, jeder auf dieser Konferenz könnte mit fertigen Bibliotheken und Webdiensten innerhalb eines Tages zum Beispiel ein Tool schreiben, das per Spracherkennung ein YouTube-Video transkribiert. Macht man es dagegen so wie ich und schiebt Zeiger in C hin und her, wird es ein Zehn-Jahres-Projekt, das wahrscheinlich nicht gut enden wird.

c’t: Es ist also eine Gratwanderung: einerseits nicht das Rad neu erfinden, andererseits nicht zu abhängig von anderen Projekten werden.

Spolsky: Deswegen baue ich nur noch simple Arduino-Projekte, wo ich LEDs abhängig von GPS-Daten aufleuchten lasse … Aber das ist der Grund, warum Stack Overflow so wichtig geworden ist: Man arbeitet in einem Ökosystem, das man nicht wirklich verstehen kann. Man programmiert auf Grundlage von Code anderer Leute.

c’t: Bei Stack Overflow bezahlt man mit einem Punkt seiner eigenen Reputation, wenn man einen Beitrag downvotet. Warum ist das eigentlich so?

Spolsky: Jeff Atwood – mein Mitgründer – war damals genervt von dem häufigen Gehupe in New York. Ich sagte, die Hupe ist aus Sicherheitsgründen notwendig. Aber meistens benutzen die Leute die Hupe nur, um ihrem Ärger Luft zu machen. Jeff schlug vor, dass man für jedes Mal Hupen fünf Dollar bezahlen soll: Wer sie braucht, um einen Unfall zu verhindern, wird sie trotzdem benutzen, wer nur genervt ist, eher nicht. Diese Idee haben wir in Stack Overflow eingebaut. Ich glaube, sie hat so funktioniert, wie wir es geplant haben.

»Stack Overflow ist nicht Reddit oder Rate My Cat. Es gibt richtig und falsch.«

Die größere Frage ist: Warum haben wir Downvotes? Viele Mimosen sagen: Warum seid ihr so gemein, wir sollten nett zueinander sein! Ich verstehe beide Seiten. Man möchte in einer Community willkommen geheißen werden. Andererseits ist Stack Overflow nicht Reddit oder Rate My Cat. Es gibt richtig und falsch; Code kann schlecht oder unsicher sein. Für Stack Overflow ist Downvoting wichtig, weil sonst nicht klar ist, ob ein niedrig bewerteter Beitrag noch nicht oft gesehen wurde oder ob er einfach schlecht ist. Ab einer gewissen Reputation kann der Benutzer auch sehen, aus wie vielen Up- und Downvotes sich ein Score zusammensetzt.

Nur soll es nicht politisch werden, nach dem Motto: Hier ist meine Antwort, ich downvote alle anderen. Downvoting ist wichtig, sollte aber selten genutzt werden. Ich habe mal eine ziemlich politische Antwort gepostet – ich glaube, es ging um Inversion of Control – und jeden Tag war der Score entweder bei +200 oder bei –200. Ich glaube, ich hatte recht, aber egal: Die Lektion daraus war, dass Stack Overflow nicht der richtige Ort ist, um Meinungen auszudrücken.

c’t: Schreiben Sie immer noch Antworten?

Spolsky: Gelegentlich. Meistens, wenn es eine Frage ist, an der ich selbst gerade arbeite. Die meisten Nutzer machen das so, aber es gibt auch einige, die anderen einfach helfen wollen.


Dieser Beitrag stammt aus c't 17/2019 (syt)