Blogbeiträge in Programmen für Softwareentwicklung zu schreiben, ist ähnlich absurd wie einen Roman in Excel zu verfassen oder Screenshots in Word zu übermitteln. Was beim Lesen in uns allen ein “Ja, was denn sonst?” auslöst und bei meinen Leserinnen und Lesern die Frage aufkommen lässt, über welch banale Erkenntnis ich jetzt schon wieder einen Blogbeitrag verfasst habe, ist gar nicht so abwegig wie es auf den ersten Blick scheint.
Wer in der Softwarebranche tätig ist, kennt das: Diejenigen, die Software entwickeln, empfehlen denjenigen, die sie benutzen sollen, oftmals Workflows, die, von außen betrachtet, teilweise absurd sind. Sie erkennen aber die Absurdität nicht oder verbieten es sich, den in ihrer Bubble als State-of-the-Art bezeichneten Prozess zu kritisieren. Manche von ihnen quälen sogar sich selbst jahrelang, bis sie erkennen, dass Schreiben keinen Deploymentprozess benötigt und das Verfassen von Texten in Programmen zur Softwareentwicklung nicht g’scheit ist. Danny von Kooten ist einer von ihnen.
As of today, after a twelve-year journey across various static site generators, this site is once again powered by WordPress. […] The reason I’m back […] is not technical. A static site comes with many benefits if you’re a developer: you get to edit posts in your favorite IDE, everything is in version control and hosting is free, simple and secure. […] My IDE is for coding, not for writing. […] Every time I opened the site to write, my brain switched into engineering mode. Too often I would […] suddenly find myself focusing on some technicality instead. Another redesign. Getting the build working. […] WordPress gives me a place that is clearly for managing content. Not building, not configuring, not upgrading a toolchain. Writing.
Danny van Kooten
Was Danny van Kooten beschreibt, ist subtil. In Wirklichkeit beschreibt er ein Gefühl. Er beschreibt, wie die Wahl der Software für eine bestimmte Aufgabe – in diesem Fall wählt er seine ihm von Berufs wegen gewohnte Entwicklungsumgebung (IDE), um einen Text zu schreiben – Einfluss auf seine Stimmung hat. Anstatt zu schreiben, drängt ihn die Software förmlich dazu, zu coden, auszuprobieren, zu basteln, die neuesten Tools auszuprobieren. Doch er hält dagegen und wählt ein geeignetes Tool, um seiner ursprünglichen Intention nachzukommen. Er entscheidet sich für WordPress und tut, wofür er gekommen war: Schreiben.
Aber Danny van Kooten will schreiben und erkennt, dass die Software, die er dafür verwendet, Einfluss auf ihn hat. Was aber, wenn wir es mit Menschen zu tun haben, die nur vorgeblich schreiben wollen? Und was, wenn solche, die gar nicht schreiben (und somit auch die Erfahrung, die Danny van Kooten gemacht hat, nie machen werden), Softwarelösungen für diejenigen schaffen sollen, die schreiben wollen? Kann das gut gehen? Kann jemand, der den Bedarf nicht nachvollziehen kann, eine Lösung für jemanden schaffen, der den Bedarf hat? Kann jemand, der die Auswirkungen seiner Software nie spüren wird können, eine gute Lösung für jemanden, der sie braucht, entwickeln? Das ist keine Theorie, sondern ein praktisches Problem, das zu teils absurden Lösungen führt, die am Bedarf vorbeigehen.
Wir alle kennen Entwicklerinnen und Entwickler, die andauernd der Verlockung unterliegen, etablierte Systeme gegen das, was gerade angesagt ist, auszutauschen. Sie probieren aus und berichten dann stolz über ihre Wechsel vom Framework A zum System B zur KI C. Auf die nie gestellte Frage nach dem Warum antworten sie meist mit Argumenten, die auf den jeweiligen Repositories oder Websites der Hersteller von A, B und C genannt werden. Sie antworten allerdings so, als ob diese Argumente Resultat ihres eigenen, auf Erfahrung basierenden Erkenntnisprozesses gewesen wären. Sie labern über die Vorteile ihres jeweils neuen Workflows für sich selbst und angeblich auch für ihre Kunden, und konstruieren Nachteile des jeweiligen Vorgängersystems, um ihr Vorgehen zu rechtfertigen. Es vergeht keine Woche, in der ich nicht ungefragt von wieder neuen, ach so tollen, super-performanten Publishing-Setups höre.
Das Problem daran ist: Das ist Werkzeugfetischisierung, nicht Problemlösung.
Nicht gerade selten basieren diese super-performanten Setups auf Workflows, die für Entwickler zwar normal sind, aber für Menschen, die einfach nur schreiben und Inhalte veröffentlichen wollen, absurd. So wurde mir letztens von einem Kollegen stolz berichtet, dass er seinem Kunden Markdown beigebracht hatte. Ich vermutete schon, dass es hier nicht um eine Optimierung ging, sondern um eine Notwendigkeit, also fragte ich ihn nach dem Wozu. Der Kunde braucht Markdown-Dateien mit Front Matter, meinte er, damit er diese Dateien dann in Git ablegen und auf ein Remote-Repository pushen kann, um einen Build-Prozess auszulösen, der aus den einzelnen Dateien eine Website generiert und sie veröffentlicht. Und stell dir vor, berichtete er noch weiter, ich musste ihm erst einen Texteditor installieren, weil er das mit Word machen wollte! Sprach’s und sah mich mit funkelnden Augen wie ein Welpe an, der freudig einen Ast aus dem Wald geholt hatte.
Ja, so etwas verkaufen Entwickler ihren Kunden als Erfolg. Ja, das nehmen sie als völlig normal wahr. Und ja, das halten sie für die beste Lösung und berichten auch noch stolz darüber. Wie für den Hammer alles ein Nagel ist, ist für diese Art von Softwareentwickler alles ein Deploymentprozess.
Jono Alderson meint, WordPress (oder CMS im Allgemeinen) sei die einzige Lösung für inhaltszentrierte Websites. Seine Begründung ist technischer und organisatorischer Natur, aber man darf den von Danny van Kooten angesprochenen Aspekt nicht unterschätzen. Wenn jemand schreiben will, dann ist eine Software, die fürs Programmieren optimiert wurde, nicht die richtige Wahl. Eine, die fürs Veröffentlichen von Texten online geschaffen wurde, hingegen schon. Sie erspart denen, die schreiben wollen, den Umweg eines komplizierten, fehleranfälligen Deployments. Sie erledigt das Veröffentlichen ohne Friktion. Kein Markdown, kein Front Matter, kein Git, kein Deployment, kein Build-Prozess, kein gar nix. Stattdessen: Anmelden, Tippen, Speichern – so einfach kann es sein. Unattraktiv auf Reddit, aber eine effektive Problemlösung.
Gute Programmierer erkennen das irgendwann. Sie wissen, dass es Probleme gibt, die nicht mit dem üblichen Standardprozedere abgefertigt werden können. Sie erkennen auch, dass das Aufzwingen eines Workflows, der für die eine Tätigkeit funktioniert, nicht unbedingt die beste Lösung für jede Tätigkeit ist. Sie beginnen, die Wünsche der Kundinnen und Kunden ernst zu nehmen und das Problem aus ihrer Sicht anzugehen. Sie hören auf, diese Wünsche in vorgefertigte Schablonen zu zwängen. Sie beginnen, das Schreiben als eigenständige Tätigkeit, die andere Werkzeuge braucht, zu respektieren. Eines dieser Werkzeuge kann WordPress sein. (Oder Craft, oder Drupal, oder Statamic, oder sonst ein CMS.)
Danny van Kooten hat zwölf Jahre gebraucht, um am Ende festzustellen:
It’s the content that matters […] WordPress is familiar, imperfect, flexible, occasionally annoying, and very good at being a place where words can live for a long time.
Danny van Kooten
Die offensichtliche, unabhängige, kostenlose und einfache Lösung lag die ganze Zeit vor ihm.
Es gibt Menschen, für die passt Lösung A. Für andere Menschen wiederum ist Lösung B die Bessere. Und weil es auch C-Z gibt, kann jeder Mensch für sich selbst den Weg finden, wie es für ihn gut klappt.
WordPress hat seine Stärke in einer Niedrigschwelligkeit, dafür aber aus meiner Sicht eklatante Schwächen technischer Natur. Für mich ist es also nicht die beste Lösung. Wenn ich damit nicht gescheit bin, so be it. Ich finde diesen Absolutismus aber nicht zielführend. Warum nicht einfach mal die Leute machen lassen, wie es sich für sie gut anfühlt?
Klar, am Ende sollen alle das Werkzeug nutzen, das sich für sie gut anfühlt. Mein Text war auch nicht absolut gemeint, sondern ein Plädoyer dafür, ehrlich zu sich selbst zu sein: Nutze ich A oder B, weil mir das Schreiben leichter fällt? Oder weil mir das Basteln mehr Spaß macht als das Schreiben?
Genau diese Verwechslung war ja auch der Punkt bei Danny van Kooten: Es fühlt sich produktiv an, an der Technik zu schrauben, am Theme zu feilen, das nächste Tool auszuprobieren. Nur entsteht dabei eben kein Text. Und das ist die Falle, vor der ich warnen wollte. Definitiv nicht WordPress als alternativloses Heilsversprechen ausrufen.
Dass WP technische Schwächen hat, bestreite ich überhaupt nicht. Es ist in vielerlei Hinsicht ein Trümmerhaufen, da bin ich bei dir. Aber die Frage ist halt: Wofür optimiere ich? Wenn mein Ziel saubere Technik ist, ist WordPress oft die falsche Antwort. Wenn mein Ziel aber ist, regelmäßig zu veröffentlichen, ohne dass zwischen Gedanke und Veröffentlichung noch Dateien, Commits, Build-Steps und ein Deployment liegen, dann gewinnt die Niedrigschwelligkeit deutlich. Ob es nun WordPress oder ein anderes Tool ist, ist im Grunde egal.
Insofern: kein Absolutismus von meiner Seite, no worries. Eher ein “pass auf, dass das Werkzeug dir dient und nicht umgekehrt”. Ob das dann A, B oder Z ist, kann und soll jeder und jede selbst herausfinden.