Wähle langweilige Technologie (2015)

• Es ist für den langfristigen Erfolg eines Unternehmens vorteilhaft, neue Technologien zurückhaltend einzusetzen und bewährte Technologien (boring technology) bevorzugt einzuführen
• Jedes Unternehmen verfügt nur über etwa 3 Innovationstokens (innovation tokens); jedes Mal, wenn man sich für NodeJS, MongoDB oder ein neues Tool entscheidet, wird eines davon verbraucht
• Bei bewährten Technologien sind Funktionen und Fehlermuster (failure modes) gut bekannt, wodurch das Risiko der für neue Technologien typischen unbekannten Unbekannten (unknown unknowns) geringer ist
• Technologieentscheidungen wirken sich auf das gesamte Team und die ganze Organisation aus; wegen Betriebsaufwand und kognitiver Last sind Tools, die für viele Probleme solide genug sind, oft vorteilhafter als das „beste Tool für den Job“
• Sorgfältige Technologieentscheidungen geben Ingenieurinnen und Ingenieuren die Freiheit, sich auf größere Probleme zu konzentrieren; Technologie um der Technologie willen ist bedeutungslos

---

Langweiligkeit annehmen (Embrace Boredom)

• Jedes Unternehmen hat ungefähr 3 Innovationstokens (innovation tokens), und deren Angebot ist für eine Weile fest — mit gewonnener Stabilität und Reife können einige hinzukommen, aber man neigt dazu, den eigenen Bestand zu überschätzen
• Eine Website mit NodeJS zu bauen, MongoDB zu verwenden oder eine Service-Discovery-Technologie einzuführen, die seit weniger als einem Jahr auf dem Markt ist, kostet jeweils 1 Innovationstoken; eine eigene Datenbank zu schreiben ist ein großes Problem
  • Solche Entscheidungen können für eine JavaScript-Beratungsfirma oder ein Datenbankunternehmen sinnvoll sein, doch die meisten Unternehmen verfolgen größere Missionen wie die Neudefinition des globalen Handels oder die Neuerfindung von Web-Zahlungen — begrenzte Aufmerksamkeit auf Bereiche wie ssh-Innovation zu verwenden, ist ein direkter Weg zu Scheitern oder verzögertem Erfolg
• „Langweilig (boring)“ ist nicht gleich „schlecht (bad)“; es gibt auch langweilige und schlechte Technologien — Beispiele für langweilig, aber gut genug, sind MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• Der Vorteil langweiliger Technologien liegt nicht nur darin, dass ihre Fähigkeiten (capabilities) gut verstanden sind, sondern auch ihre Fehlermuster (failure modes)
• Bei Technologieentscheidungen gibt es sowohl known unknowns (z. B. dass unklar ist, wie sich eine Datenbank verhält, wenn die CPU-Auslastung 100 % erreicht) als auch unknown unknowns (z. B. wenn man nicht wusste, dass Statistikaufzeichnung GC-Pausen verursacht); bei neuen Technologien ist das Ausmaß der unknown unknowns deutlich größer

Global optimieren (Optimize Globally)

• Die Vorliebe für langweilige Technologien ist ein guter Bias, aber nicht der einzige Faktor; Technologieentscheidungen haben eine Reichweite (scope), die sich auf Teams, Organisationen und das Gesamtsystem erstreckt
• Das Hinzufügen einer Technologie hat Kosten — wenn man bereits Ruby nutzt und dann noch Python hinzufügt, übersteigt die Komplexität den Grenznutzen; bei Debatten wie Python vs Scala oder MySQL vs Redis werden diese Einschränkungen jedoch oft ausgeblendet und stattdessen das „beste Tool für den Job (best tool for the job)“ beschworen
• Der Kern der Arbeit besteht darin, Geschäftsprobleme auf den Lösungsraum von Softwareentscheidungen abzubilden; wenn Entscheidungen keine Last erzeugten, könnte man für jedes Problem lokal das optimale Tool wählen, aber in der Realität gibt es diese Last
  • Diese Last besteht aus Betrieb (operations) und in geringerem Maß aus kognitivem Overhead (cognitive overhead) — Monitoring, Wissen für Unit-Tests und Änderungen, init-Skripte usw. summieren sich schnell
• Das Problem mit der Denkweise vom „besten Tool für den Job“ ist, dass sowohl „beste“ als auch „Job“ zu kurzsichtig betrachtet werden — der eigentliche Job ist, das Unternehmen am Leben zu halten, und das „beste“ Tool ist jenes, das bei möglichst vielen Problemen die Position des am wenigsten schlechten (least worst) Tools einnimmt
• Die langfristigen Kosten, ein System stabil zu halten, übertreffen die Unannehmlichkeiten beim Aufbau bei weitem; reife und produktive Entwickler verstehen das

Manchmal neue Technologie wählen (Choose New Technology, Sometimes)

• Würde man diese Logik ins Extrem treiben, würde man Websites nur noch mit Java umsetzen — unrealistisch; man braucht einen Weg, neue Tools in den Werkzeugkasten aufzunehmen
• Neue Technologien haben am Ende Auswirkungen auf das ganze Unternehmen, daher ist ihre Einführung eine Entscheidung, die unternehmensweite Sichtbarkeit (company-wide visibility) erfordert — man braucht die kulturelle Erwartung: „Das ist etwas, das wir alle gemeinsam besprechen“
• Die sinnvollste Übung ist, sich zu fragen, wie man das aktuelle Problem lösen würde, ohne neue Technologie hinzuzufügen — so erkennt man Fälle, in denen das eigentliche „Problem“ nur darin besteht, dass jemand diese Technologie verwenden möchte; in so einem Fall sollte man sofort aufhören
  • Mit einer kleinen Zahl von Technologieentscheidungen kommt man schon weit; die tatsächliche Antwort ist selten „Das geht nicht“, sondern meist eher „Das geht, aber es ist zu schwierig“ — wenn es mit den aktuellen Ressourcen unmöglich scheint, das Ziel zu erreichen, hat man womöglich nicht kreativ genug gedacht
• Es hilft, klar zu dokumentieren, warum die Lösung dieses Problems im aktuellen Stack übermäßig teuer und schwierig ist
• Die Wahl neuer Technologie kann eine rein additive Änderung sein (z. B. memcached hinzufügen, weil es noch kein Caching gibt) oder sich mit bestehender Technologie überschneiden bzw. diese ersetzen — im Fall eines Ersatzes braucht es klare Erwartungen hinsichtlich der Migration bestehender Funktionen; die Richtlinie hat meist die Form, zusammen mit dem vorgeschlagenen Zeitplan eine Migration zuzusagen
  • Die Absicht ist, die Trümmer auf einem handhabbaren Niveau zu halten und ein Wildwuchs lokal optimierter Lösungen zu verhindern
• Dieses Verfahren ist nicht belastend: ein paar Fragen, die als Aufgabe auszufüllen sind, und ein Meeting, um sie zu besprechen — wenn eine neue Technologie oder ein neuer Service diese Hürde sauber nimmt, ist die Einführung angemessen

Einfach ausliefern (Just Ship)

• Polyglot Programming (polyglot programming) wird mit dem Versprechen verkauft, dass Entwickler Probleme wirksamer lösen, wenn man ihnen vollständige Freiheit bei der Toolwahl gibt; das ist bestenfalls eine naive Problemdefinition, schlimmstenfalls motiviertes Denken — die alltägliche toil der Betriebsarbeit drückt auf Entwickler
• Gerade sorgfältige Technologieentscheidungen geben Ingenieurinnen und Ingenieuren die Freiheit, über größere Fragen nachzudenken; Technologie um der Technologie willen ist Schlangenöl

Etsy-Beispiel (Fußnote)

• Etsy hatte anfangs große Probleme mit diesem Thema — nachdem viele Python-Programmierer eingestellt worden waren, suchte man nach Aufgaben für sie und baute eine sinnlose Zwischenschicht; es dauerte Jahre, sie wieder zu entfernen / gleichzeitig lag die Latenz der Suche am 90. Perzentil bei rund 2 Minuten — Etsy scheiterte zwar nicht, konnte aber jahrelang nichts ausliefern, wodurch sich der Erfolg verzögerte
• Die Schnittmenge aus langweiligen und schlechten Technologien wird oft „enterprise software“ genannt, aber das kann ungenau sein
• Etsys Fall der activity feeds — umgesetzt in einer Zeit, in der das meiste mit PHP, MySQL, Memcached und Gearman vereinheitlicht wurde / die Umsetzung war deutlich komplizierter als mit einem Tool wie Redis, aber mit diesem Stack dennoch ausreichend machbar
  • In den folgenden Jahren verlagerte sich die Aufmerksamkeit auf andere Themen, während die Nutzung der activity feeds um das 20-Fache anstieg; dank der gemeinsam genutzten Plattform funktionierte alles jedoch ohne gesonderte Änderungen weiterhin normal — ein langfristiger Vorteil von Zurückhaltung bei Technologieentscheidungen
  • Das ist allerdings kein Absolutismus — memcached-basierte activity feeds galten als praktikabel, aber spezialisierte Suche mit Facettensuche würde Etsy nicht in reinem PHP bauen; dafür nutzte Etsy Solr