Unser Softwareentwicklungsalgorithmus

• In einem kürzlichen Gespräch mit einem bekannten Tech-CEO und Ingenieur hörte ich von einer interessanten Methodik der Softwareentwicklung. Diese Methodik brachte mich dazu, über andere Heuristiken und Verallgemeinerungen nachzudenken.

Seine Methode

• Zu Beginn des Tages mit der Arbeit an einem Feature anfangen. Wenn es bis zum Ende des Tages nicht fertig ist, alles löschen und am nächsten Tag neu beginnen. Geschriebene Unit-Tests können behalten werden.
• Wenn das Feature auch nach mehreren Tagen nicht umgesetzt werden kann, über das Fundament, die Infrastruktur oder das Refactoring nachdenken, das das Feature ermöglichen würde, dies umsetzen und dann zum Feature zurückkehren.
• Diese Methode ähnelt der Extreme-Programming-Bewegung der späten 90er- und frühen 2000er-Jahre.

Gedanken zur Methode

"Alles zweimal schreiben"

• Ein Ratschlag für Junior Engineers: Das Problem lösen, den Code auf einem Branch speichern und ihn dann noch einmal schreiben.
• Diese Methode wurde zufällig entdeckt, nachdem ein Laptop kaputtgegangen war. Das Neuschreiben dauerte nur 25 % der Zeit der ersten Implementierung, und das Ergebnis war deutlich besser.
• Mit dem 1,25-Fachen des Zeitaufwands kann man Code von doppelt so hoher Qualität erhalten. Nützlich für Projekte, die langfristige Wartung erfordern.
• Die Methode "jeden Tag neu anfangen" ist noch extremer. Bei jedem Neuschreiben findet man eine elegantere Lösung.

"Quantität hat eine eigene Qualität"

• Ein Zitat von Stalin lässt sich auf Software Engineers anwenden. Für Junior Engineers sind die ersten 100.000 Zeilen Code unverzichtbar.
• Die Methode "jeden Tag neu anfangen" hilft dabei, diese 100.000 Zeilen schneller zu schreiben.
• Dasselbe Problem wiederholt zu lösen, ist nützlich, um sich Muster einzuprägen.
• In 5.000 Zeilen perfekten Codes kann man alle wichtigen Muster sehen. Die übrigen 95.000 Zeilen verdrahten durch Wiederholung die Neuronen neu.

Vergleich mit der Heuristik "mit der Pistole am Kopf"

• Jemandem, der eine Problemlösung vorgestellt hat, die Frage stellen: "Wie würdest du es machen, wenn es in 24 Stunden fertig sein müsste?"
• Diese Methode durchbricht Framing- und Anchoring-Bias. Oft kann sie in wenigen Minuten einen Plan hervorbringen, der an nur einem Tag umsetzbar scheint.
• In Wirklichkeit ist es kein Plan, der tatsächlich an einem Tag fertig werden kann, aber die neue Lösung lässt sich oft innerhalb weniger Tage abschließen.
• Der Zweck dieses Gedankenexperiments ist nicht, eine tatsächliche Lösung zu erzeugen, sondern eine Untergrenze für die Lösung festzulegen.

Pfadsuche

• Entscheidend ist es, im Problemraum einen Pfad zu finden. Jeder Pfad ist eine Lösung, und die Aufgabe des Engineers besteht darin, den besten Pfad zu finden.
• Es lohnt sich, über die Ähnlichkeiten zwischen diesen Heuristiken und verschiedenen Algorithmen zur Pfadsuche nachzudenken.
• Bei Engineering-Heuristiken ist es genauso: Ein besserer Engineer zu werden bedeutet, im Problemraum bessere Pfade zu finden.

GN⁺-Zusammenfassung

• Dieser Artikel untersucht effiziente Methodiken und Heuristiken in der Softwareentwicklung.
• Die Methode "jeden Tag neu anfangen" und die Methode "alles zweimal schreiben" sind nützlich, um die Codequalität zu erhöhen.
• Wiederholtes Problemlösen hilft bei Mustererkennung und der Neuverdrahtung von Neuronen.
• Die Heuristik "mit der Pistole am Kopf" ist nützlich, um eine Untergrenze für Lösungen festzulegen.
• Die zentrale Aufgabe von Engineers ist es, im Problemraum den besten Pfad zu finden.

[ahwjdekf]

Seid ihr verrückt? Das können höchstens Leute machen, die viel zu viel Zeit übrig haben — ist so etwas in der Realität überhaupt ein vertretbares Unterfangen?

[dlehals2]

In der koreanischen SI-Umgebung wäre das wohl unmöglich … haha, höchstens in einem privaten Projekt.

[kaistj]

Auf diese Herangehensweise wäre ich überhaupt nicht gekommen.
Das sollte ich mal ausprobieren, haha

[eususu]

Ich kann dem Gedanken des Neuschreibens sehr zustimmen.
Ich habe einmal aus Versehen an einem Code gearbeitet und ihn verloren; als ich ihn dann neu schrieb,
habe ich Dinge mit berücksichtigt, die ich zuvor aus Bequemlichkeit ignoriert hatte, weil ich mitten im Prozess das Design nicht mehr ändern wollte.
Das Ergebnis war vielmehr sogar besser.

[GN⁺]

Hacker-News-Kommentare

• Es ist eine gute Strategie, neue Features zweimal zu schreiben. Für Business-Entwickler oder Projektmanager kann das jedoch wie eine unnötige Verzögerung wirken.

  • Ein Feature einmal von Anfang bis Ende zu schreiben hilft dabei, die Logik zu ordnen und zu refaktorisieren.
  • Das Neuschreiben macht den logischen Ablauf klarer und ermöglicht es, einem lineareren Plan zu folgen.
  • Es verringert tendenziell den Bedarf an großen Refactorings zu einem späteren Zeitpunkt.

• Die Frage „Was, wenn es in 24 Stunden fertig sein muss?“ ist keine Frage, die ein Projektmanager stellen kann.

  • Das ist eine persönliche Lernübung, keine Methode, um Arbeit schneller fertigzubekommen.

• Guter Code entsteht durch die Wahl der passenden Abstraktion.

  • Um die passende Abstraktion zu wählen, muss man das Ganze kennen.
  • In anderen Ingenieurdisziplinen gibt es gute Blueprint-Paradigmen wie CAD-Layouts.
  • In der Softwareentwicklung fehlen solche Blueprints.
  • Erfahrung ist wichtig, weil es darum geht, die Balance zu finden.

• Mit fähigen Kollegen kann man zeigen, was in kurzer Zeit möglich ist.

  • Es gibt viele Gründe, warum schnelles Arbeiten wichtig ist.
  • Wie bei der Autoreparatur gilt: Je länger es dauert, desto wahrscheinlicher ist es, dass man beim Zusammenbau etwas vergisst.
  • Wenn man ein Feature an einem einzigen Tag implementiert, sinkt das Risiko.
  • Dafür braucht man ein sicheres Verständnis der Tools und einen verlässlichen CI/CD-Prozess.

• Ich kann der Ansicht zustimmen, dass es gut ist, Software zweimal zu schreiben.

  • Nachdem ich einmal geschriebenen Code verloren habe, fehlt mir die Motivation, ihn erneut zu schreiben.
  • Wenn ich versuche, ihn neu zu schreiben, kann ich mich nicht konzentrieren und erinnere mich nicht mehr an den Ansatz.

• Wenn man ein Feature auch nach mehreren Tagen nicht implementieren kann, sollte man zuerst die nötige Infrastruktur oder Refactorings erledigen.

  • Es ist wichtig, den „Wortschatz“ der Werkzeuge aufzubauen und zu pflegen.

• „Innerhalb von 24 Stunden“ und „alles zweimal schreiben“ hängen miteinander zusammen.

  • Wenn man Code schlampig schreibt, muss man ihn am Ende ohnehin neu schreiben.

• Dieser Beitrag ist einer der besten „Programmier-Ratschläge“.

  • Er ähnelt dem Rat des grug brained developer.

• Manchmal muss man einen Hintergrund-Thread laufen lassen, um ein Problem zu lösen.

  • Erfahrene Leute können solche Probleme schneller erkennen.
  • Manchmal ist es besser, das Problem kurz liegen zu lassen und etwas anderes zu tun.

• Der folgende Ansatz ist nützlich:

  • Zuerst mehrere Ideen aufschreiben, wie sich das Problem lösen lässt.
  • Die Arbeit so aufteilen, dass sie „innerhalb einer Sitzung abgeschlossen werden kann“.
  • So implementieren, dass der Code am Ende jeder Sitzung immer „funktioniert“.
  • Am Ende jeder Sitzung einen Brain-Dump in Kommentaren oder im README festhalten.