- Entwicklerisches Können wird nicht allein durch Wissen bestimmt. Selbst wenn man weiß, was zu tun ist, häufen sich technische Schulden an, wenn man Tests, Refactoring oder das Schreiben von Reproduktionsfällen aus mangelnder Motivation aufschiebt.
- Hervorragende Entwickler untersuchen flaky tests und beheben sie, machen aus entdeckten Bugs Tickets oder fixen sie sofort und refaktorieren zuerst, wenn neue Features nicht zum bestehenden Code passen.
- Sprichwörter wie „premature optimisation“, „duplication is better than the wrong abstraction“ oder „Keep It Simple, Stupid“ sind nützlich, wenn es um reale Einschränkungen geht, können aber auch dazu dienen, bloßes Nicht-wollen zu kaschieren.
- Für Lazygit wurde über mehrere Monate hinweg ein End-to-End-Testsystem aufgebaut und dessen Nutzen spürbar, doch für Lazydocker wurden dieselben Tests nicht ergänzt, und auch die Anfrage nach einem minimalen Reproduktions-Repository sowie das Refactoring einer God Struct wurden aufgeschoben.
- Selbst wenn die Energie für perfekten Code fehlt, hilft es, Mängel ehrlich offenzulegen, um Wartungsmaßstäbe und die Priorität der nächsten Arbeitsschritte leichter beurteilen zu können.
Motivationsmangel als Ursache technischer Schulden
- „Can’t Be Fucked“ ist australischer Slang für einen Zustand, in dem man etwas nicht tun will oder nicht die Energie und Motivation dafür hat.
- Es schien naheliegend, dass man durch mehr Entwicklungswissen ein besserer Programmierer wird, doch in Wirklichkeit sind die Entwickler, die man zu respektieren lernt, nicht nur fachlich stark, sondern auch von konstanter Gewissenhaftigkeit geprägt.
- Gute Entwickler wissen, dass es langfristig Zeit spart, Probleme sauber zu behandeln, solange sie noch klein sind, und handeln entsprechend.
- Wenn es einen flaky test gibt, untersuchen und beheben sie ihn.
- Wenn sie in freier Wildbahn einen Bug entdecken, erstellen sie ein Ticket oder beheben ihn sofort.
- Wenn ein neues Feature nicht zum bestehenden Code passt, zwängen sie es nicht hinein, sondern refaktorieren zuerst.
- Bei Bedarf gehen sie im Stack bis nach unten, um die Ursache zu verstehen.
- Diese Entwickler können dennoch unterscheiden, wann „good enough“ richtig ist, wann der Scope reduziert werden sollte und wann es besser ist, erst mehr über die Domäne zu lernen, bevor man die Architektur ändert.
- Das Problem ist, dass unabhängig von solchen Urteilen in manchen Momenten nicht äußere Projektzwänge die stärkere Einschränkung sind, sondern fehlende Motivation.
Ehrlich sein, statt sich hinter Sprichwörtern zu verstecken
- Das End-to-End-Testsystem von Lazygit wurde über mehrere Monate in Teilzeit aufgebaut, hat danach viele Regressionen verhindert, und es besteht die feste Überzeugung, dass es heute schwerer wäre, es nachträglich hinzuzufügen.
- Trotzdem wurde Lazydocker nicht mit End-to-End-Tests ergänzt, und der Grund war schlicht CBF.
- Nachdem in einem anderen Open-Source-Repository ein Issue erstellt worden war, wurde ein minimales reproduzierbares Git-Repository angefragt, aber es wurde noch immer nicht erstellt; auch ein großes Refactoring, das vor über einem Jahr begonnen wurde, konnte nicht abgeschlossen werden, sodass im Code weiterhin viel God Struct verblieben ist.
- Ob es Burnout ist, ein Mangel an Growth Mindset oder einfach eine Frage der Persönlichkeit, wird nicht festgelegt.
- Den langfristigen Schmerz technischer Schulden zu kennen, kann ein Antrieb zur Vermeidung sein, doch es zu wissen und tatsächlich richtig zu handeln, sind zwei verschiedene Dinge.
- Aussagen wie „Zu viele Tests erhöhen den Wartungsaufwand“, „Ich werde refaktorieren, nachdem ich gesehen habe, welche Auswirkungen andere Features haben“, „premature optimisation“ oder „cut scope aggressively“ können Ausdruck guter Urteile sein, aber auch als Ausreden dienen.
- Wenn man zugibt, dass Teile von Code oder eines Pull Requests aus Faulheit unzureichend sind, können Reviewer selbst beurteilen, ob dieser Mangel noch akzeptabel ist oder ob es sinnvoller wäre, Zeit in die nächste Aufgabe zu investieren.
- Wenn der CBF-Zustand eintritt, sollte man nicht verzweifeln, sondern ehrlich sein; wer zu lange mit 100 % gelaufen ist, braucht vielleicht Urlaub.
1 Kommentare
Meinungen auf Hacker News
Ein erheblicher Teil von CBF lässt sich allein durch Vergütung und Anreize erklären
Als ich in mein jetziges Unternehmen kam, war ich voller Energie: Ich reparierte kaputte Builds, brachte vernachlässigte Tests wieder zum Laufen, refaktorisierte die Deployment-Pipeline und fand und behob die eigentlichen Ursachen von Bugs
Doch mit der Zeit nahmen sich die Leute nicht etwa ein Beispiel an mir, sondern es hieß: „Der wird das schon reparieren“, und ich merkte, dass man für Drecksarbeit nur noch mehr Drecksarbeit zurückbekommt
Umgekehrt wurde jemand, der Dinge schnell und hacky zusammenbaut, zuerst befördert, weil er die Ergebnisse gut verkauft; wenn dann im Betrieb Probleme auftauchen, ist er längst zum nächsten Projekt weitergezogen
Der Junior, dem ich jede Woche stundenlang helfe, verdient mehr als ich, weil er 2022 in aller Eile eingestellt wurde; ich bekam 2023 zwar die Bewertung „über den Erwartungen“, aber wegen schwieriger Zeiten nicht einmal eine Gehaltserhöhung
Am Ende ist es aus Sicht eines Angestellten nicht verwunderlich, wenn die Motivation verschwindet, wenn Einsatz nicht belohnt wird oder einem sogar schadet
Man sollte gehen und den Ort und die Menschen finden, zu denen man gehört
Anerkennung senkt die Motivationskosten deutlich, und Menschen mögen Belohnungen
Dass Leute Tausende Stunden in Spiele stecken, liegt auch daran, dass die Motivationskosten dort sehr niedrig sind
Das heißt nicht, dass man den Arbeitsplatz gamifizieren sollte; aber weil es kleinlich wirkt, wenn man sich selbst verteidigt, sollten Kolleginnen und Kollegen einander Anerkennung geben
Auch technische Schulden haben unterschiedliche Zinssätze, und Können besteht darin, 0-%-Schulden liegen zu lassen und zuerst die hoch verzinsten Schulden zu tilgen
Als ich im Keller einen Schrankboden verlegte, reichte das Material nicht, um ihn ganz bis nach hinten fertigzustellen. Es sieht etwas hässlich aus, ist aber immer von Kisten verdeckt und hat auch nach Jahrzehnten keine Auswirkung. Das sind technische Schulden mit 0 % Zinsen
Wenn dagegen ein Abfluss verstopft ist, steigen die Kosten mit der Zeit durch eindringendes Wasser im Keller oder dadurch, dass der Abfluss sich löst; das sind Schulden, auf die Zinsen anfallen. Eine kaputte Eingangstreppe, über die man ständig stolpert, ist ebenfalls eine hoch verzinste Schuld, die schnell behoben werden muss
Im Engineering kann ein Architekturproblem, das jede Feature-Entwicklung verlangsamt, eine hoch verzinste Schuld sein, während schlampiger Code oder TODOs in Dateien, die kaum jemand anfasst, in der Praxis niedrig verzinste Schulden sein können
Engineers verpassen einerseits wichtigere Arbeit, weil sie 0-%-Schulden beheben, und sagen andererseits, „Produkt/Leadership unterstützt den Abbau technischer Schulden nicht“, können aber oft die tatsächlichen Kosten und den Zinssatz nicht gut erklären
Von oben bis unten bekommt nur Neues und Glänzendes Aufmerksamkeit; die Pflege des Bestehenden interessiert niemanden
Selbst wenn man die Wichtigkeit überzeugend darlegt, stimmt das Management nur zu, dass die Arbeit nötig ist, aber sie hat keinerlei positiven Einfluss auf die Leistungsbewertung. Ich bleibe dann auf Arbeit sitzen, für die ich nur kritisiert werde, wenn etwas schiefgeht
Wenn die Codebase unordentlich und inkonsistent ist, sinkt bei Entwicklern selbst bei versteckten Dateien die Bereitschaft, neue Features konsistent und hochwertig umzusetzen
Dann heißt es: „Dieses ganze Modul muss sowieso neu geschrieben werden, also hängen wir es erst mal schnell hier dran und räumen später auf“
https://en.wikipedia.org/wiki/Broken_windows_theory
Sie ist eine natürliche Erweiterung des Begriffs technische Schulden, bringt den Kern prägnant auf den Punkt und ich würde sie gern auch im Unternehmen verwenden
Deshalb ist es etwas zu einfach, den Entwicklern vorzuwerfen, sie hätten die tatsächlichen Kosten nicht erklären können
Wenn ein Problem für Kunden sichtbar wird, wird es wahrscheinlich behoben; wenn es nur ein internes Problem ist, ist die Wahrscheinlichkeit deutlich geringer
Wenn man Ausdrücke wie „technische Schulden mit 0 % Zinsen“ ernsthaft verwendet, sollte man vielleicht prüfen, ob man das Konzept nicht falsch verstanden hat
Schulden muss man zurückzahlen oder man muss Zinsen dafür zahlen; wenn es so etwas nicht gibt, ist es keine Schuld
Als Nächstes nennt man dann wohl auch noch nicht implementierte Features technische Schulden mit 0 % Zinsen
Ich bin kein Steve-Jobs-Fan, aber seine Zitate über Handwerkskunst und die Haltung, auf Details zu achten, haben mir immer gefallen.
„Wenn du ein Tischler bist, der eine schöne Kommode baut, wirst du für die Rückseite, die zur Wand zeigt und die niemand sieht, kein Sperrholz verwenden. Du weißt ja, dass sie da ist, also wirst du auch für die Rückseite schönes Holz nehmen. Damit du nachts ruhig schlafen kannst, müssen Ästhetik und Qualität bis zum Ende durchgezogen sein.“
Ich denke, Software insgesamt leidet stark unter der Haltung: „Die Anforderungen sind technisch gerade so erfüllt, also ist meine Arbeit erledigt.“
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
Es gibt viele Geschichten darüber, dass er sich weigerte, Hardware und Software zu veröffentlichen, die den Standards nicht entsprachen, und Leute entließ, die es nicht in der richtigen Spezifikation hinbekamen.
Die meisten dagegen arbeiten unter einer genau gegenteiligen Führung: „So schnell wie möglich fertig werden, mehr verkaufen und gerade genug zusammenflicken, damit die Qualitätstests irgendwie durchlaufen.“
Ein echter Tischler muss praktisch und kosteneffizient sein, um am Markt zu konkurrieren.
Wenn er teures Holz oder zusätzliche Zeit an Stellen aufwendet, die niemand sieht, sinkt der Durchsatz und die Kosten für Kunden steigen unnötig.
Auch für Handwerker sind Zeit und Geld endlich, und Zeit, die in unsichtbare Arbeit fließt, kann nicht in sichtbarere Arbeit fließen.
In einem Markt, in dem Tischler mit denselben Fähigkeiten zu niedrigeren Kosten mehr produzieren, würde so ein Tischler verdrängt werden.
Bei Software sehe ich das Problem eher als Anreizproblem denn als Haltungsproblem. Ich mache gerne gute Arbeit und nutze gerne gute Software, aber der Tag hat nur begrenzt viele Stunden, und ich bin nicht bereit, persönliche Zeit für geschäftliche Vorteile zu opfern, von denen ich selbst nichts habe.
Außerdem kann man vernünftigerweise erwarten, dass, sobald man mit Refactoring beginnt, eines Tages plötzlich ein unverzichtbares Feature auftaucht, das noch heute fertig werden muss.
Selbst wenn das Management der Abarbeitung technischer Schulden zustimmt, passiert am Ende nichts, wenn man nicht Schätzungen aufbläht und statt der zugewiesenen Arbeit Refactoring macht.
In einem Buch repariert eine Schmiedefigur ein Teil an einer Kutsche und sagt: „Tu immer das Beste, was du kannst.“
Auf den Einwand: „Aber das ist ein Teil, das unten eingebaut wird, niemand wird es sehen“, antwortet sie: „Aber ich weiß, dass es dort ist. Wenn ich es nicht so gut mache, wie ich kann, werde ich mich jedes Mal schämen, wenn diese Kutsche vorbeifährt. Und ich werde diese Kutsche jeden Tag sehen.“
https://news.ycombinator.com/item?id=28086786
Wenn man saubere Unit-/Integrations-/End-to-End-Tests schreibt und beim Anblick von chaotischem Code refactort, statt einfach noch etwas obendrauf zu setzen, wirkt man auf dem Papier weniger produktiv als Kolleginnen und Kollegen, die ständig Tickets „lösen“.
Besonders schlimm ist das in „voll agil“ arbeitenden Organisationen, die Refactoring oder Code-Qualitätsarbeit überhaupt nicht berücksichtigen.
Apple war zumindest eine Zeit lang eine Ausnahme. Die Produkte waren teuer, die Kunden erwarteten Qualität, das Unternehmen hatte die Margen, um sie zu ermöglichen, und vor allem gab es Steve Jobs, der ein Auge für die Experience hatte.
Am anderen Extrem steht so etwas wie Juicero, das eine Maschine zum Auspressen von Saftpäckchen mit Raumfahrt-Engineering baute.
Den größten Teil meiner Karriere habe ich technische Schulden beseitigt, wenn ich die Gelegenheit sah, auch ohne dazu aufgefordert zu werden. Das lag an Bindung und Ownership.
Jetzt arbeite ich in einer Jira-getriebenen Umgebung mit Micromanagement und ohne Autonomie, also tue ich nichts außer dem, was unbedingt getan werden muss.
Früher war freiwilliger Einsatz ein Kern meiner Karriere, aber inzwischen sind die bürokratischen und sozialen Projektmanagementkosten für jede Änderung so hoch, dass es sich einfach nicht lohnt.
Es interessiert mich nicht, ob das Produkt langfristig gut dasteht oder das Unternehmen Erfolg hat; ich arbeite nur Tickets ab, bis ich den nächsten Job finde.
Wenn man es umgekehrt nach dem Motto „Für Refactoring fragt man nicht um Erlaubnis, man macht es“ angeht, wird man dafür gerügt, dass man einen PR erstellt hat, der nicht den bestehenden Patterns im Repository folgt.
Dann heißt es: „Das ist gut, aber wir müssen es mit dem ganzen Team besprechen.“
Also wachsen die technischen Schulden weiter, das Mergen eines einzelnen PR dauert Monate, und die Tests sind so instabil, dass es sich wie ein Casino-Spielautomat anfühlt, bei dem man immer wieder auf den Restart-Button drückt, bis es baut. Agile ist wirklich großartig.
In einem Arbeitsplatz, der nur reaktiv handelt, wird proaktives Handeln meiner Erfahrung nach nie belohnt.
Wenn man ein Problem entdeckt, wird es in diesem Moment zu meinem Problem, und wenn es später wieder hochkocht, ist es meine Schuld.
PMs und Management gehen immer von negativen Annahmen aus, daher lohnt es sich nicht.
Vor allem denken manche Leute, sie hätten den erleuchteten Pfad zu gutem Code gefunden, tatsächlich wählen sie aber oft den leichteren Weg, statt den bestehenden Code zu lesen und zu verstehen.
In den Kommentaren hier gibt es einige Missverständnisse.
Für einzelne Programmiererinnen und Programmierer sind Motivation, Einsatz, Energie, Willenskraft – wie auch immer man es nennt – endliche Ressourcen, und das ist völlig normal.
Der Vorteil einer Organisation ist, dass sie mehr leisten kann als ein einzelner Programmierer, aber beim Zusammenfügen vieler Elemente entstehen Lücken, und Arbeit fällt durch diese Lücken.
Menschen wie COO, HR und Produktmanager, die nicht für technische Arbeit, sondern für den Betrieb der Organisation bezahlt werden, müssen Prozesse schaffen, um diese Lücken zu schließen.
Doch immer mehr Unternehmen wälzen diese Arbeit auf einzelne Engineers und Designer ab, weil sie sich schwer in Gewinn und Verlust oder OKRs messen lässt.
Das Unternehmen leidet und die Engineers brennen aus. Es gibt eine Grenze dafür, wie lange man ohne zusätzliche Vergütung kleine Tickets und Aufgaben auffangen kann, die durch die Lücken gefallen sind.
Die Stimmung hier ist zwar extrem negativ, aber ich war froh, weil der Artikel meine alltäglichen Gefühle genau beschreibt.
Wenn ich die großartige Testabdeckung und das prinzipientreue Refactoring von Open-Source-Projekten sehe, komme ich an manchen Tagen auch in den „Machen wir es richtig“-Modus und schaffe viele gut gebaute Dinge.
Und wenn diese Energie dann eines Tages verschwindet, werde ich, wie der Autor, auch zu CBF. Ich überspringe Tests, hänge Code an Stellen an, von denen ich weiß, dass sie nicht gut sind, und lege Wege an, für die mein zukünftiges Ich mir nicht dankbar sein wird.
Ich sehe das in Echtzeit passieren, habe aber weder die Energie noch die Motivation, wieder in den inspirierten „Machen wir es richtig“-Modus zurückzukehren.
All das passiert sogar bei Software, die ich selbst baue und verkaufe.
Ich fand es beeindruckend zu sehen, dass der Autor der Macher von Lazygit ist, und ich mag lazygit wirklich sehr. In meinem Kopf gehört er immer zur Kategorie der Open-Source-Maintainer, die es richtig hinbekommen.
Es klingt, als hätten wir beide ähnliche Erfahrungen mit Motivation.
Es freut mich, dass du lazygit magst, und ich hoffe, dass ich diese gute Einschätzung auch in Zukunft halten kann.
Die meisten Entscheidungen sind tatsächlich unbewusst.
Der Zustand „Ich kann einfach nicht“ bedeutet, dass irgendein Schaltkreis im Gehirn entscheidet, dass Dinge wie Refactoring oder Tests den Aufwand nicht wert sind.
Dieser Schaltkreis kann auch recht haben. Denn objektiv und im Großen und Ganzen ist die Belohnung im Verhältnis zum Aufwand oft tatsächlich nicht groß genug.
Wenn man zum Beispiel zwei Monate lang End-to-End-Tests gebaut hat und sich dadurch in den folgenden sechs Monaten drei Wochen Debugging usw. spart, geht die Rechnung nicht auf.
Es gibt zwei verbreitete Extreme. Auf der einen Seite zwingt das Business Engineers zu technischen Schulden, die wirklich schlechte Kompromisse sind; auf der anderen Seite verbringen Engineers manchmal Zeit mit idealisierter Strukturierung und riesigen Testpaketen, die sich am Ende nicht auszahlen.
Ein Teil davon liegt auch daran, dass jemand Sorge hat, jemand anderes könnte bessere Codestruktur oder zusätzliche Tests entdecken und ihn danach beurteilen.
Wenn ich das Gefühl habe, etwas abzuliefern, das meinen eigenen Maßstäben nicht genügt, dann schadet das meiner Moral und Motivation massiv, selbst wenn diese Maßstäbe höher sind als eigentlich nötig.
Das größte Problem technischer Schulden sehe ich eher darin, dass sie die Moral zerstören.
In Lazygit habe ich über Monate hinweg teilweise ein End-to-End-Testsystem gebaut, und ich denke jeden Tag an die Regressionen, die es verhindert hat, und daran, wie viel schwieriger es wäre, es heute nachträglich hinzuzufügen.
Ich weiß eindeutig, dass es sich gelohnt hat. Warum ich trotzdem keine End-to-End-Tests zu Lazydocker hinzugefügt habe? Einfach weil CBF.
End-to-End-Tests sind höllisch lästig und ein riesiger Aufwand, wenn das Tooling nicht stimmt. Es braucht bessere Basis-Frameworks, die man leicht einbauen kann.
Mit Glück bleibt dieser Person noch Zeit für Integrationstests.
Ich halte die Sichtweise, dass Menschen in dieser Gesellschaft und dieser Welt faul seien, größtenteils für völligen Unsinn.
Man arbeitet jahrzehntelang 40 Stunden pro Woche und soll erst nach der Wiedergeburt ausruhen; und hier wollen wir über Faulheit reden?
Geistige Energie wird einem herausgesaugt, um den Reichtum anderer zu schaffen, und wenn man zu alt ist, um noch etwas zu tun, wird man weggeworfen.
Jede Woche kommt wieder ein Feature, das gestern fertig sein sollte, und ich weiß nicht, wann man technische Schulden eigentlich beheben soll. In der Freizeit? Ich weiß ohnehin nicht, warum man überhaupt ständig existieren muss.
In einem reifen Projekt in einem kleinen Team bestanden die verbleibenden Tickets nur noch aus schwierigen Bugs, die niemand anfassen wollte.
Bugs, bei denen man nach mehreren investierten Tagen nichts vorzuweisen hat außer ein paar gestrichenen Verdachtsmomenten, und die nach einer falschen Streichung eine Woche später wieder auftauchen.
Jeden Tag muss man seine gesamte geistige Energie in solche Tickets stecken, und wenn man mit Kaffee oder Stimulanzien gerade so einen Bug gelöst bekommt, reicht man den Code ein, schließt das Ticket und geht direkt zum nächsten über.
Echte Erholung gibt es nicht; nur am Anfang des nächsten Tickets kann man den Kopf kurz ausruhen, wenn noch niemand sofort Ergebnisse erwartet.
Aber nach ein paar Tagen fragen die Leute, was man bisher gemacht hat, ob man feststeckt, und man muss sich mit kleinen Lügen einen Grund dafür zurechtlegen, warum man zurückliegt, obwohl man eigentlich kaum angefangen hat.
Genau dann, wenn man am dringendsten Ruhe bräuchte, ist man schon am weitesten im Rückstand und die Leute haben es bemerkt, sodass sich selbst Urlaub nicht mehr wie eine Option anfühlt.
Jetzt arbeite ich in einer Engineering-Non-Profit-Organisation 20 bis 30 Stunden pro Woche, manchmal weniger, und das Geld ist knapp, aber mehr zu arbeiten ist schlicht unmöglich.
Ich habe ein bisschen Zeit für Side Projects und Radfahren, und am Wochenende arbeite ich niemals. Dienstags arbeite ich auch nicht, außer in besonderen Fällen.
Ich liebe meinen jetzigen Job wirklich, er ist mein Traumjob, aber er ist es nicht wert, mich dafür umzubringen. Man lebt nur einmal, und ich werde richtig lieben und leben.
Heute habe ich eine einmonatige Aufgabe abgeschlossen, bei der ich die Firmware eines Geräts unserer Firma fast komplett neu geschrieben habe; ursprünglich war sie als einwöchige Aufgabe angesetzt, um einen kleinen Bug in einem Teil des Kommunikationsmoduls zu beheben.
Zum Glück habe ich einen entspannten PM und Kolleginnen und Kollegen, die anerkennen, dass wir jetzt tatsächlich die acht Jahre alten Legacy-Bugs in diesem Code beheben können.
Es bleiben noch Edge-Case-Tests und weitere Korrekturen, aber Remote-Code-Updates funktionieren, also können wir die Geräte ausliefern.
Mit „lügen“ meine ich hier eher eine Handlungsempfehlung. Ursprünglich hatte ich den Kommentar mit „Lügt“ begonnen, aber das wurde missverstanden.
Man sollte auch existieren, um Kolleginnen und Kollegen daran zu erinnern, dass es wichtig ist, sich Zeit zu nehmen, über die größeren Implikationen der Arbeit nachzudenken.
Und um seine Gedanken in solche Communities einzubringen, Schokolade zu essen, wenn möglich mit dem Hund spazieren zu gehen und sich auf YouTube Vorträge von Alan Watts anzuhören.
Als jemand, der versucht, es richtig zu machen, glaube ich, dass bei technischen Schulden Tracking entscheidend ist.
Ein sichtbares Problem als Aufgabe anzulegen, dauert nur ein paar Minuten, und diese Aufgabe wird dann zu technischer Schuld.
Die Führungsebene ist dafür verantwortlich, technische Schulden zu priorisieren und kontinuierlich eine gewisse Menge davon abzubauen.
Manchmal reduziert man technische Schulden auch dadurch, dass man entscheidet, etwas nicht zu tun, und das ist völlig in Ordnung.
Der Zweck eines Prozesses aus Dokumentieren, Prüfen und Bearbeiten ist, „Probleme, die nicht jetzt dran sind“ ein zweites Mal anzusehen.
Die erste Intuition kann falsch gewesen sein und X war vielleicht gar nicht nötig; oder sie kann aus Gründen richtig gewesen sein, an die man damals nicht gedacht hat.
Vor allem sind einige der Dinge, die man „jetzt nicht machen kann“, tatsächlich wichtig. Wenn man sich nicht die Zeit nimmt, sie anzuschauen, findet man sie nicht.