Die Prokrastination des Entwicklers

Mach’ ich morgen! Vom Umgang mit technischen Schulden
Kommentare

Technische Schulden sind das Gespenst im Kopf aller Entwickler. Man möchte nicht an sie denken, aber am Ende holen sie einen doch meist ein. Denn wie bei jeder Art von Schulden gilt: Wer sie macht, muss sie auch abbezahlen. Das wirft in der Regel Fragen auf. Wann ist der richtige Zeitpunkt für die „Rückzahlung“? Wie gelingt es zukünftig am besten, das Backlog möglichst klein zu halten? Und: Kann ich darüber nicht auch noch morgen nachdenken?

Dass immer der Verursacher für Schulden aufkommen muss, stimmt in der Softwareentwicklung zugegebenermaßen nicht ganz. Immerhin gibt es durchaus eine Art technischer Schulden, die jahrelang durch Projekte geschleppt wird, bevor sich jemand ihrer annimmt. Dabei handelt es sich meist um kleine Unachtsamkeiten oder Abweichungen von Konventionen, die dazu führen, dass der Code schlecht pflegbar wird. Es sind Details, eigentlich sogar nur Kleinigkeiten, die solange kaum auffallen, wie nur Menschen mit dem Code arbeiten, die damit vertraut sind. Übernimmt dann aber jemand anders die Pflege des Projekts, explodiert das Backlog geradezu. Problem um Problem taucht auf und bereitet Kopfzerbrechen.

Der Teufel steckt im Detail

Technische Schulden sind also nicht die großen Bugs, die plötzlich alles zum Zusammenbruch bringen und laden deswegen dazu ein, sie ewig auf dem Backlog stehen zu lassen. Wird die Zahl der Provisorien aber zu groß, kann das durchaus zur Entstehung großer Probleme beitragen. Vor allem führen Notlösungen und Abweichungen von Standards im Code jedoch dazu, dass die Arbeit am Projekt immer langsamer voranschreitet. Jedes Provisorium muss nämlich bei der weiteren Arbeit am Code wieder berücksichtigt werden. Somit lohnt sich ein rechtzeitiger Blick auf die angesammelten Probleme durchaus.

Eine mögliche Lösung dafür stellt die Erstellung eines Hauptzweigs innerhalb des Projekts dar, der so frei wie möglich von technischen Schulden gehalten wird. Jedes neue Feature wird dann als eigener Projektzweig angelegt. Dadurch bleiben provisorisch gefixte Bugs auf einzelne Features beschränkt und beeinflussen nicht unmittelbar das gesamte Projekt, solange keine andere Funktion auf das Feature zugreift. Ganz vermeiden lassen sich technische Schulden nämlich nicht immer, sodass es gut ist, ihren Einfluss zumindest zu begrenzen, bis es an der Zeit ist, sie abzuarbeiten.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Mehr Zeit, weniger Schulden

Eine der wichtigsten Gründe für das Entstehen technischer Schulden ist eine zu enge Zeitplanung. Hier kann aber der Begriff der technischen Schulden durchaus dabei helfen, genau diese zu vermeiden. Vorgesetzte, die zu viel Zeitdruck aufbauen, wissen häufig einfach nicht genau, dass auch ein funktionsfähiges Produkt mit vielen Sollbruchstellen daherkommen kann. Wer aber mit wirtschaftlichen Faktoren für eine schnelle Auslieferung argumentiert, wird das Konzept der Schulden verstehen. Am Ende ist nämlich immer nur eins möglich: Qualität oder Quantität. Soll das eine erhöht werden, werden Schulden auf der anderen Ebene gemacht. Entweder kann die Deadline eingehalten werden oder der Code ist (weitgehend) fehlerfrei.

Lesen Sie mehr zum Thema im Java Magazin 2.15 „Technische Schulden“

Trotzdem ist einfach nicht jedes Problem unmittelbar lösbar, auch nicht mit genug Zeit. Eine andere Art technischer Schulden entsteht daraus, dass Entwickler über die Projektdauer hinweg immer genauer verstehen, wie zuvor entwickelte Features noch besser umsetzbar gewesen wären. Hier geht es weniger um Bugs und provisorische Lösungen und mehr um grundlegende Fragen des Designs. Natürlich kann das Projekt dann meistens nicht mehr vollständig umgestaltet werden; eventuell soll aber doch das eine oder andere Feature nachträglich noch einmal angepasst werden, um der neuen Ausrichtung zu entsprechen. Dafür bedarf es mehr Zeit und Vorbereitung als für die unmittelbare Behebung eines Bugs.

Entschuldung planen statt Listen pflegen

Um die technischen Schulden des Projekts nicht zu groß werden zu lassen, bietet es sich an, diese wie zu entwickelnde Features zu behandeln. Statt sie auf ein Backlog zu setzen und darauf zu warten, dass endlich einmal Zeit für ihre Erledigung über ist, kann diese Art von Arbeit genau so geplant werden, wie jede andere Aufgabe auch. Dadurch wird die Reduktion des Backlogs zum festen Bestandteil eines jeden Sprints.

Auch sollte von Anfang an darüber entschieden werden, wie im Rahmen der Arbeit an einem Projekt mit technischen Schulden umgegangen werden soll und an welcher Stelle Schulden gemacht werden dürfen. Es kann durchaus sinnvoll sein, bestimmte Entscheidungen auf einen späteren Zeitpunkt zu vertagen, wenn mehr Informationen verfügbar sind. Auch ist es manchmal notwendig, ein Feature mit Workarounds auszuliefern. Wichtig ist, rechtzeitig einen guten Umgang damit zu finden. Nicht jeder Bug darf nur provisorisch geflickt werden!

Keine Prokrastination!

Das größte Problem im Umgang mit technischen Schulden ist nämlich das Vorhaben, sich morgen darum zu kümmern. Oder nächste Woche. Oder im nächsten Sprint! Oder nächstes Jahr? Immerhin funktioniert das Produkt ja noch und das Backlog ist noch nicht zu lang. Warum sollte also die Arbeit an den technischen Schulden jetzt beginnen? Das nächste Feature muss doch auch fertig werden! Und schon häufen sich die Schulden an.

Wer einmal damit beginnt, die Arbeit an technischen Schulden aufzuschieben, gerät schnell in einen Teufelskreis. Es gibt keinen perfekten Zeitpunkt zum erledigen aufgeschobener Arbeit in der Zukunft. Im Gegenteil ist es sogar so, dass das Abarbeiten immer schwerer wird, je länger die Liste der anzugehenden Aufgaben ist. Auch wird immer etwas anderes anliegen, dessen Erledigung eigentlich dringender wäre. Hier haben wir drei Tipps zusammengestellt, um der Prokrastination zu entkommen.

Lesen Sie mehr zum Thema Prokrastination im Artikel „Softwareentwickler und der Kampf gegen die Prokrastination

Happy New Year!

Der Gedanke, technische Schulden kurz vor Projektabschluss zu bearbeiten, kann an dieser Stelle verlockend sein. Dieser Ansatz hat jedoch einiges mit den üblichen Neujahrsvorsätzen gemeinsam. Es gibt nämlich kein magisches Datum, an dem es plötzlich ganz leicht fällt, viele Probleme auf einmal zu lösen. Oder zu dem endlich genug Zeit dafür da ist. Je größer die technischen Schulden werden, desto langsamer wird das Projekt voranschreiten, sodass am Ende nur noch wenig Zeit für die Abarbeitung der Schulden bleibt.

Noch schlimmer ist es aber, technische Schulden zu machen und sie nie abarbeiten zu wollen. Natürlich gibt es einfache Lösungen, die durchaus sinnvoll sind und so bleiben können. Wer aber unabhängig davon, welcher Natur das Problem ist, nur einen kurzen Vermerk im Code hinterlässt, ist sich meist durchaus bewusst, dass er nie dahin zurückkehren wird. Auch diese Schulden können aber später Probleme verursachen. Sind sie nicht einmal in einem Backlog erfasst, wird es noch schwerer, sie dann zu identifizieren.

Wer erst einmal erkannt hat, dass er etwas besser machen könnte, sollte am besten unmittelbar damit anfangen. Dem Entschluss etwas zu verändern wohnt nämlich eine gewisse Energie inne. Wer diese sofort nutzt um die Idee in die Tat umzusetzen, kann viel bewegen,während andere noch drüber nachdenken was sie tun sollten und wie sie am besten vorgehen könnten.

Anfangen statt überlegen

Auch zu perfektionistische Konzepte führen nämlich nur wieder zum Aufschub der Erledigungen. Wer sich vornimmt, eine ewig verdrängte Aufgabe nun nicht nur zu erledigen, sondern es gleich perfekt zu machen, baut neue Hürden auf. Code wird nie perfekt sein, also ist das auch bei der Abarbeitung technischer Schulden nicht das Ziel. Hier sollte es darum gehen, standardkonforme Konzepte und einen weitgehend bugfreien Code zu präsentieren, der ohne Provisorien auskommt.

Und wie ist das mit der Wichtigkeit? Natürlich stehen auch immer andere Aufgaben an, das liegt in der Natur der Sache. Es ist allerdings eine Frage des eigenen Schwerpunktes, wie die jeweiligen Aufgaben gewichtet werden. Hier hilft es, kritisch zu hinterfragen, ob eine neue Aufgabe oder ein bestimmter Teil der technischen Schulden nun relevanter ist. Denn auch das ist wichtig für die Abarbeitung einer langen To-Do-Liste: Nicht alle Aufgaben können gleichzeitig angegangen werden, den Schwerpunkt muss jeder selbst setzen. Wer sich nicht auf eine Aufgabe fokussiert, ist schnell überfordert.

Kosten mit Kollegen besprechen

Überforderung ist ein weiterer häufiger Mechanismus, der hinter jeder Art von Prokrastination steckt. Auch bei technischen Schulden geht es oft darum. Wer nicht sicher ist, wie ein Problem richtig gelöst wird, wird unter Umständen schneller Schulden aufhäufen als jemand, der sich besser auskennt. Niemand ist allerdings perfekt, also gehört auch ein regelmäßiger Austausch mit dem Kollegen zum Abbau technischer Schulden. So ergeben sich Lösungen für Probleme, die nur aus Überforderung entstanden sind, ganz von selbst.

Am Ende geht es aber auch bei der Abarbeitung technischer Schulden um eine Kosten-Nutzen-Rechnung. So mancher Workaround kann durchaus erlaubt sein und im Code bleiben, auch wenn er nicht standardkonform ist. Das ist dann der Fall, wenn für die „richtige“ Lösung mehr Aufwand notwendig wäre, als die Abkürzung an Schaden anrichten kann. Wichtig ist dabei aber die Frage danach, wie der Code sich in der Zukunft verhalten wird: Schulden müssen bezahlt werden. Ist der Preis gering, ist das unter Umständen okay. Wird es teuer, muss die Prokrastination ein Ende finden!

Lesen Sie mehr zum Thema im Java Magazin 2.15 „Technische Schulden“

entwickler.de in den sozialen Netzwerken

Entwickler Magazin

Folgen Sie den Social-Media-Kanälen des Entwickler, um stets über aktuelle News aus allen Bereichen informiert zu werden.

Aufmacherbild: hand cutting a rope with a clock hung on by a wooden clip via Shutterstock / Urheberrecht: wk1003mike

Ann-Cathrin Klose

Autor

Ann-Cathrin Klose

Ann-Cathrin Klose studiert allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz. Seit Februar 2015 verstärkt sie als redaktionelle Mitarbeiterin die Redaktion bei Software & Support Media. Zuvor war sie als freie Autorin tätig und hat erste redaktionelle Erfahrungen bei einer Tageszeitung gesammelt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -