Nachdenkliches zur Wochenmitte: Jeffrey Zeldman „Blue Beanie Day matters“

[Gunnar Bittersmann]

@@pl

Zukunftskompatible Ideen im produktiven Umfeld durchzusetzen ist nicht möglich, weil deren Entwicklung viel zu lange dauern würde.

Da wage ich mal zu widersprechen. Entschieden.

Mitunter wird „agile Software-Entwicklung“ so verstanden, dass man sich Scheuklappen aufsetzt und nur das macht, was gerade ansteht, ohne in die Zukunft zu blicken. Wenn sich in Zukunft was ändert, überlegt man halt dann neu – und fängt von vorne an.

Ich halte das für Bullshit. 💩

Erfahrungsgemäß kommt die Zukunft eher früher als später.

Beim ersten Feature ist man natürlich schneller, wenn man erstmal einfach so loslegt ohne groß nachzudenken. Schon beim zweiten stimmt das wohl nicht mehr und beim dritten ist man deutlich langsamer als wenn man beim ersten schon in die Zukunft gedacht hätte.

Harry Roberts hat in seinem Vortrag auf der beyond tellerrand eine ähnliche Rechnung aufgemacht: ab 12:45 im Video.

Wie ich neulich erst schrub, sollte man den zweiten Teil von “Don’t write code that guesses the future, arrange code so you can adapt to the future when it arrives” (Sandi Metz) nicht unterschlagen.

Und wo Du mal wieder an mein Framework denkst:

Nein, an dein Framework dachte ich hier nicht.

Sondern an Frameworks, die gerade hip sind: Angular, React, … Und nächste/n/s Woche/Monat/Jahr wird die nächste Sau durchs Dorf getrieben.

Die Gründe für deren Einsatz sind allzu oft:

1. Andere setzen dieses Framework auch ein. Und Million Fliegen können ja nicht irren.
2. Unsere Entwickler kennen sich mit diesem Framework aus. Und mit keinem anderen.
3. Unsere Entwickler können Aufgaben ohne dieses Framework gar nicht mehr lösen.

1 und 2 habe ich selbst schon erlebt. 3 ist das, wovor Zeldman eindringlich warnt.

Ich will hier aber keinesfalls den Sinn von Frameworks/Bibliotheken infragestellen. Wenn sie mit Bedacht eingestzt werden, sind sie eine gute Sache.

jQuery hat damals™ die JavaScript-Entwicklung schon revolutioniert. Und sicherlich Einfluss auf natives JavaScript gehabt: jetzt gibt es querySelector/querySelectorAll (und damit einen Grund weniger, noch jQuery einzusetzen).

Und 3D möchte ich auch lieber mit Three.js als ohne machen.

Die Frage ist, wie man das einsetzt. Zunächst einmal, ob man ein Framwork deshalb wählt, weil es zu dem jeweiligen Projekt passt. Und nicht wegen obigen 1, 2, 3.

Und natürlich, wie es eingesetzt wird – für oder gegen den Nutzer. Man kann eine SPA (singe page application) so bauen, dass der Nutzer sekundenlang nichts zu sehen bekommt bis das Framework geladen ist. Man kann eine SPA mit modernen Frameworks aber auch so bauen, dass die vom Nutzer aufgerufene Seite serverseitig gerendert und sofort übertragen wird und erst danach das Framework geladen wird.

Und wenn bei einer SPA Dinge wie Browser-History (incl. Funktion des Back-Buttons) und Möglichkeit des Setzen als Lesezeichen/Verlinkung der einzelnen „Seiten“ (Zustände der SPA) bedacht werden, ist gegen SPA nicht einzuwenden – im Gegenteil.

Nur leider wird allzu oft derartiges nicht bedacht und ein Framework eingesetzt, um die Entwicklung zu vereinfachen, damit aber das Produkt zu verschlechtern.

Entwickler sollten nicht solchen Pfusch abliefern. Und sich von Produktmanagern nicht dazu antreiben lassen, solchen Pfusch abzuliefern.

Entwickler sollten ihre Arbeit nicht so verstehen, sich selbst das Leben so einfach wie möglich zu machen. Sondern das Leben der Nutzer. Wie Jeremy Keith sagt: “In case of conflict, I will always value user needs above developer convenience. That’s called ‘work’.”

LLAP 🖖