Nachhaltige Softwareentwicklung als Entwickler begreifen
Wenn Nachhaltigkeit einfach wäre, dann wären es hier kein Thema. Nachhaltigkeit ist ein Thema für alle und damit auch für Entwickler. Hier ein etwas philosophischer Ansatz, wie man Nachhaltigkeit als Entwickler begreifen kann.
Twitter ist ein Ort, an dem oft konzentrierte Erkenntnisse geteilt werden. Erkenntnisreich fand ich zum Beispiel den folgenden Austausch von @GeePawHill.
I spoze the historic and ongoing inability/unwillingness of the software trade to grasp and adopt test-driven development (TDD) is one of the most frustrating & demoralizing events of my forty-two years as a professional geek.
Da es mir oft ein wenig einfacher fällt, Dinge auf Deutsch zu begreifen, hier die Übersetzung.
Die historische und andauernde Unfähigkeit bzw. der Unwille der Softwarebranche, testgetriebene Entwicklung (TDD) zu begreifen und anzunehmen, ist eines der frustrierendsten und demoralisierendsten Ereignisse in meinen zweiundvierzig Jahren als professioneller Geek.
„Begreifen“ ist nicht nur hier bei TDD ein zentraler Aspekt, sondern aus meiner Sicht eben auch bei der Entwicklung von nachhaltiger Software. Bei einer Erklärung der Vorteile und der Notwendigkeit von TDD nicken die meisten Entwickler mit dem Kopf und setzen es am Ende aber dann doch nicht mit der notwendigen Konsequenz um. Wir kennen in der Regel die Auswirkungen, verknüpfen diese aber nicht direkt mit unserem Handeln.
Genau diese Brücke baut dann auch die Antwort von @wittyelk auf den ursprünglichen Tweet.
Not doing TDD is like not doing anything against climate change. You get away with it too long. And the effects (bugs) become evident only weeks & months later. They are never connected with the cause: not doing TDD.
Auch hier wieder zur Verstärkung des Inhaltes die Übersetzung:
TDD nicht zu machen ist wie nichts gegen den Klimawandel zu tun. Man kommt zu lange damit durch. Und die Auswirkungen (Bugs) werden erst Wochen und Monate später sichtbar. Sie werden nie mit der Ursache in Verbindung gebracht: kein TDD zu machen.
In der Regel sind wir viel zu beschäftigt, um uns um saubere Tests zu kümmern oder eben, dass unsere Software „ökologisch“ effektiv ist. Neue Features wollen implementiert und die bereits bestehende Komplexität bezwungen werden. Als Entwickler ist man oft schon froh, wenn etwas grundlegend funktioniert und damit ist das oft auch der Horizont, auf den man hinarbeitet. Aber eben genau dieses Vorgehen ist auch gleichzeitig die Ursache für unser Problem.
Davon könnte man die Regel ableiten, dass alles, was man macht, um ein Problem zu lösen, auch immer ein Feedback auf die Probleme der Zukunft hat. Je kleiner (effektiver) die Lösung sind, desto geringer ist das Feedback auf die Probleme von Morgen. Wir tun unserem Zukunfts-Ich also einen Gefallen, wenn wir uns an das einfache Prinzip „Weniger ist mehr“ halten.
