Wir starteten mit einer kurzen Zusammenfassung, was technische Schulden sind in das Carrot Monthly. Wenn du mit dem Begriff nicht vertraut bist, kann ich dir unseren Blog Post über technische Schulden empfehlen.

Eines der jüngsten und viel diskutierten Beispiele für technische Schulden ist Twitter, wo es in letzter Zeit einige technische Probleme gab. Einer der Tweets von Elon Musk:

Ob ein kompletter Rewrite die beste Idee ist, ist eine andere Frage. Aber man sieht hier sehr gut: Viele technische Schulden sind entstanden wurden in der Vergangenheit aber nicht adressiert, die verantwortlichen Entwickler sind teilweise nicht mehr im Unternehmen, um den Code zu pflegen, und der Rest weiß einfach nicht, wie sich die vielen verschiedene Komponenten gegenseitig beeinflussen.

Ein Satz aus der gestrigen Diskussion hat mir besonders gut gefallen: Jedes Projekt hat technische Schulden. Der Unterschied ist, ob man sich dessen bewusst ist oder nicht.

Bewusstsein & Kultur

Wie schafft man also Bewusstsein? Ein wichtiger Aspekt ist die Kultur. Es geht um Unternehmens-, Team- und Fehlerkultur. Wenn das nicht funktioniert, werden technische Schulden vielleicht aus Angst und Scham versteckt. Wenn es eine Kultur der Offenheit gibt, ist es keine große Sache, Entscheidungen transparent und auf Augenhöhe zu diskutieren. Wenn zum Beispiel eine Funktion wichtig ist und das Team sie vor dem Abgabetermin fertigstellen muss, es aber nicht ohne einen Hack oder eine Abkürzung geht, ist es völlig in Ordnung, dies zu tun. Solange es kommuniziert, dokumentiert und in Zukunft dann auch sicher wieder abgearbeitet wird.

Technisches Grundverständnis

Ein weiterer Aspekt ist das Verständnis dafür, dass Code nicht gleich Code ist. Es gibt einen großen Unterschied zwischen schönen, wartbaren Code und chaotischen, nichtlesbaren Code. Wenn man nicht vorsichtig ist, passiert letzteres. Es geht also um mehr als nur um die hübsche Oberfläche, die die Benutzer:innen in ihren Browsern sehen. Manche Manager:innen sind sich jedoch nicht darüber im Klaren, dass der Code auch sauber und lesbar sein muss, damit er auf lange Sicht gewartet werden kann. Sie beginnen erst dann sich Sorgen zu machen, wenn etwas schief läuft, die Arbeit länger dauert und vorhandene Features plötzlich nicht mehr funktionieren. Das das wird dann oft sehr viel teurer, als wenn das Problem früher schon addressiert hätte. Ein Beispiel: Ein Manager kam mit einem Code zu uns, der von einer Offshore-Firma entwickelt worden war. Für die Endanwender sah das Ergebnis, nämlich die Web Applikation, großartig aus. Aber als wir uns den Code ansahen, war er ein völliges Durcheinander. Es gab tatsächlich keine Hoffnung, diesen Code zu retten, ohne unangemessen viel Geld auszugeben. Ein kompletter Rewrite wäre die einzige Option gewesen. So wirft man Geld zum Fenster raus, oder?

Systeme schaffen und etablieren

Im Carrot Monthly hat jemand David Allens Buch Getting Things Done erwähnt. Im Grunde geht es darum, ein System zu schaffen und Gewohnheiten zu entwickeln, um Dinge zu erledigen. Es gibt eine Analogie zu den technischen Schulden. Du und dein Team braucht Gewohnheiten und ein System, um technische Schulden zu dokumentieren, zu verwalten und in Angriff zu nehmen. Und damit das ganze dann auch funktioniert müsst ihr die Vorteile dieser Gewohnheiten und Systeme kennenlernen und erleben. Nehmen wir als Beispiel automatisierte Tests. Zunächst fühlt es sich wie eine Menge zusätzlicher Arbeit an - ein bisschen so, als würde man anfangen, ins Fitnessstudio zu gehen oder zu joggen. Zeit und Beständigkeit ist notwendig um sich eine Gewohnheit anzueignen, um konsequent zu bleiben und letztendlich die Früchte ernten zu können. Aber es lohnt sich auf jeden Fall!

Kann Perfektionismus technische Schulden vermeiden?

Wir haben dann auch darüber diskutiert, ob Perfektionismus eine Strategie für den Umgang mit technischen Schulden ist. Ein Beispiel in diesem Zusammenhang war Steve Jobs bei der Entwicklung der ersten MacBooks. Die Schlussfolgerung: Selbst wenn man den perfekten Code schreibt - was man übrigens nicht kann -, werden trotzdem technische Schulden entstehen. Generell ist es vermutlich keine nachhaltige Strategie, den perfektesten Code zu schreiben. Die Kosten explodieren und Ergebnisse entstehen nur langsam. Und: technische Schulden verschwinden nicht.

Wegwerfmentalität

Ein weiterer Aspekt, den wir im Carrot Monthly besprochen haben und der für kleinere Unternehmen besonders relevant sein kann, ist das Verständnis des Unterschieds zwischen einer Website und einer Webanwendung oder SaaS. Eine Website ist etwas, das relativ einfach - und im Falle einiger Unternehmen oft - neu gestaltet und neu entwickelt werden kann. Die alte Website wird weggeworfen, um Platz für eine neue Website mit einem noch besseren Design zu schaffen. Das ist natürlich mit Kosten verbunden, die aber oft nicht ins Gewicht fallen. Eine Webanwendung hingegen ist etwas Komplexeres. Und sie ist definitiv nichst was man einfach so wegwerfen möchte. Die Entwicklung kostet üblicherweise viel mehr als eine Website und das Geld noch mal zu investieren, macht keinen Sinn. Im Idealfall möchte man also eine qualitativ hochwertige Webanwendung erstellen, die über Jahre hinweg Bestand hat. Wir glauben, dass es schwieriger ist, technische Schulden zu verstehen und zu verwalten, wenn man aus dieser Wegwerfkultur kommt und den Unterschied zwischen einer Website und einer Webanwendung im Hinblick auf das Lebenszyklusmanagement nicht versteht.

Zusammenarbeit mit externen Entwicklungsunternehmen

Ein wichtiger Punkt, den wir festgestellt haben, ist, dass es einen Unterschied macht, ob man mit seinem eigenen Team oder mit einem externen Unternehmen arbeitet. Im eigenen Team ist es einfacher, eine Fehlerkultur und Kommunikation auf Augenhöhe zu schaffen. Viele externe Unternehmen versuchen, es jedem recht zu machen, anstatt transparent zu sein und zu erklären, dass Funktion X zwar rechtzeitig fertiggestellt werden kann, aber die Folgen sind technische Schulden, mit denen man sich später auseinandersetzen muss. Vor allem bei der Zusammenarbeit mit externen Unternehmen solltest du sicherstellen, dass es eine transparente Kommunikation gibt und dass ein gegenseitiges Vertrauen besteht, und/oder dass du ein technisches Qualitätsmanagement in deinem Team hast. Unserer Erfahrung nach ist es wichtig, dass sich der externe Partner als Teil des Teams versteht und umgekehrt. Dies ist ideal für eine transparente Kommunikation und gute Ergebnisse.

Es gibt sicher noch mehr Aspekte, aber die Zeit verging so schnell und ehe man sich versah, war eine Stunde vergangen. Wir haben die Diskussion sehr geschätzt und freuen uns schon auf das nächste Carrot Monthly am 18. April um 16 Uhr MESZ (online).

Wenn du an der Diskussion und dem Wissensaustausch teilnehmen möchtest, sichere dir jetzt dein kostenloses Ticket, denn es gibt nur eine begrenzte Anzahl von Plätzen für das Carrot Monthly Online Zoom Meeting.

Das nächste Carrot Monthly wird sich mit automatisiertem Testen beschäftigen.

Hol dir dein KOSTENLOSES Ticket