Tu das möglichst Einfachste
(seangoedecke.com)- In der Softwarearchitektur ist es ein wirkungsvoller Rat, immer „das möglichst Einfachste“ zu wählen
- Gutes Systemdesign wirkt nicht großspurig, sondern löst Probleme tatsächlich mit einem Minimum an Bausteinen
- Wer einfache Lösungen anstrebt, kann das YAGNI-Prinzip (You Aren't Gonna Need It) als zentrale Designphilosophie nutzen und das System nur dann schrittweise erweitern, wenn neue Anforderungen tatsächlich entstehen
- Über die Definition von „Einfachheit“ wird gestritten, aber ein stabiles System mit wenigen Komponenten und loser interner Kopplung kommt ihr am nächsten
- Die Fixierung auf übermäßige Skalierbarkeit macht eine Codebasis oft unflexibel; ein einfaches Design, das sich an den realen Anforderungen orientiert, ist langfristig meist vorteilhafter
Das möglichst Einfachste anstreben
Beim Entwurf von Softwaresystemen ist es wichtig, „das möglichst Einfachste“ zu tun. Dieser Ansatz lässt sich auf fast jede Situation anwenden, etwa auf Bugfixes, die Wartung bestehender Systeme oder das Design neuer Architekturen. Viele Engineers träumen von einem „idealen“ System – gut organisiert, nahezu unbegrenzt skalierbar und sauber verteilt. In der Praxis ist es jedoch oft effektiver, das bestehende System gründlich zu verstehen und dann die einfachste Lösung zu wählen.
Warum Einfachheit unterschätzt wird
- Systemdesign erfordert den Umgang mit vielen Werkzeugen wie App-Servern, Proxys, Datenbanken, Caches und Queues
- Gerade Junior-Engineers möchten oft viele Technologien einsetzen und komplexe Strukturen bauen, doch echte Reife zeigt sich eher darin, Unnötiges wegzulassen
- Herausragendes Softwaredesign wirkt unspektakulär und vermittelt eher den Eindruck, dass sich das Problem überraschend leicht lösen ließ
- Zum Beispiel sind Unicorn und die Rails-REST-API architektonisch stark, weil sie mit minimaler Struktur und auf Basis grundlegender Unix-Funktionen zentrale Garantien wie Isolation, Skalierung und Recovery erreichen
Die Denkweise hinter einer einfachen Umsetzung
- Wenn man etwa in einer Golang-Anwendung Rate Limiting hinzufügen will, kann man externen Storage wie Redis verwenden – aber sofern es nicht wirklich nötig ist, sollte man zunächst einfachere Ansätze wie Zählung im Arbeitsspeicher versuchen
- Wenn eine einfache Methode ausreicht, kann man den Aufbau schwergewichtiger Infrastruktur aufschieben
- So lässt sich das System schrittweise weiterentwickeln und erst dann erweitern, wenn tatsächlich neue Anforderungen auftauchen
- Das ist ein Ansatz, der das YAGNI-Prinzip zur obersten Priorität im Design macht
Fallstricke der Einfachheit und praktische Grenzen
1. Das Big-Ball-of-Mud-Phänomen
- Wer jede Anforderung sofort irgendwie erfüllt, riskiert, dass die Codebasis zu einem komplexen und schwer wartbaren „Big Ball of Mud“ verkommt
- Ein spontaner Hack ist jedoch keine Einfachheit, sondern erzeugt im Gegenteil mehr Komplexität beim Verstehen und Warten
- Um eine wirklich einfache Lösung zu finden, muss man viele Ansätze vergleichen und tatsächlich systematische Engineering-Arbeit leisten
2. Die Definition von Einfachheit
- Es ist nicht leicht, sich darauf zu einigen, was „Einfachheit“ eigentlich bedeutet
- Im Allgemeinen hat ein einfaches System wenige bewegliche Teile, lose Kopplung zwischen den Komponenten und klar abgegrenzte Schnittstellen
- Praktisches Beispiel: Unix-Prozesse und Unicorn teilen keinen Speicher und sind dadurch einfacher; verglichen mit Puma oder Redis ist ihre interne Kopplung geringer
- Wenn eine Entscheidung unklar ist, gilt meist die Option als einfacher, die weniger Wartung erfordert
3. Kritik an der Fixierung auf Skalierbarkeit
- Die „einfache Methode“ ist möglicherweise nicht für sehr großen Traffic geeignet
- Aber schon im Voraus kompliziert für zukünftiges starkes Wachstum zu entwerfen, ist meist vergeudete Mühe
- Der Großteil von Code muss realistisch nur auf etwa das 2- bis 5-Fache an Traffic vorbereitet sein; darüber hinaus ist es vernünftig, erst dann zu reagieren, wenn das Problem tatsächlich auftritt
- Ein zu stark auf Skalierbarkeit ausgerichtetes Design schadet der Flexibilität des Codes; unnötige Strukturaufteilung kann die Implementierung bestimmter Funktionen sogar erschweren und zusätzlich komplexes Transaktionsmanagement nötig machen
Fazit
- Mit der Zeit wird man immer pessimistischer, was die Fähigkeit angeht, künftige Systemanforderungen zuverlässig vorherzusagen
- In der Praxis ist es schon schwierig genug, den aktuellen Zustand eines Systems exakt zu verstehen, und genau das ist eines der größten Hindernisse für gutes Design
- In der Softwareentwicklung gibt es im Wesentlichen zwei Ansätze
- Systeme anhand erwarteter künftiger Anforderungen zu entwerfen
- wiederholt das möglichst Einfachste zu tun, das den aktuellen Anforderungen entspricht
- Letzterer Ansatz ist in der Praxis oft wirksamer; ein Denken in Richtung YAGNI und Einfachheit führt langfristig zu besserem Design
Anhang: Diskussion auf Hacker News und Herkunft des Begriffs
- Auf die Meinung, architektonische Einfachheit verliere mit wachsender Größenordnung an Bedeutung, entgegnet der Autor, dass gerade in großen Systemen eine einfache Struktur noch wichtiger werde – als Gegenmittel zur Komplexität von Funktionsinteraktionen
- Die Formulierung „Do the simplest thing that could possibly work“ stammt von Ward Cunningham und Kent Beck
1 Kommentare
Hacker-News-Kommentar
Ich denke, dass dieser Ansatz in einfachen Domänen gut funktionieren kann. Aber selbst nachdem ich lange in großen Tech-Unternehmen gearbeitet habe, bin ich immer wieder überrascht, wie viel Komplexität tatsächlich nötig ist. Selbst die einfachsten Business-Probleme brauchen oft mehr als ein Jahr bis zur Lösung oder brechen wegen zahlloser Edge Cases und Skalierungsproblemen immer wieder. Wer nur nach Einfachheit ruft, hat vermutlich keine Erfahrung im großen Maßstab. Selbst wenn man sich eine 10 Jahre alte Codebasis ansieht, gibt es so vieles zu berücksichtigen, dass selbst ein Rewrite oft scheitert. Wie bei der Metapher von Chesterton's Fence braucht es die Weisheit, etwas nicht leichtfertig zu entfernen, solange man den Grund für seine Existenz nicht versteht.
Ich denke, das ist ein klassisches Missverständnis, das dadurch entsteht, dass Software Engineers nicht gut miteinander kommunizieren. Wie der Titel des Artikels sagt, geht es darum, „das Einfachste zu tun, das möglich ist“. Bei komplexen Problemen ist Komplexität unvermeidlich, aber gemeint ist, dass man den Fehler vermeiden soll, sie unnötig noch komplizierter zu machen. Es geht nicht darum, Komplexität vollständig zu vermeiden, sondern darum, die Gewohnheit zu hinterfragen, Dinge übermäßig komplex zu gestalten.
Wie angemerkt muss die Komplexität nicht zwingend aus der Domäne selbst kommen. Sie kann auch das Ergebnis schlechten Softwaredesigns sein. Wenn alles voller Abhängigkeiten und Side Effects ist, dann wurden Separation of Concerns und Kopplung nicht sauber kontrolliert. Refactoring wird dann fast unmöglich, und wenn sich die Organisationskultur nicht verbessert, kommen während des Refactorings nur noch neue Probleme obendrauf. Trotzdem lassen sich auch komplexe Probleme mit Separation of Concerns und einfacher Komposition lösen. Das ist schwer, aber wenn Senior-Entwickler diese Perspektive konsequent vertreten, steigen die Erfolgschancen deutlich.
Wenn man erwähnt, dass der Autor Staff Engineer bei GitHub ist, dann denke ich, dass diese Person durchaus genug Erfahrung mit großen Systemen hat.
Legacy-Systeme existieren an den Rändern. Auch in realen Systemen gilt: Je mehr Dimensionen in einem mehrdimensionalen Raum dazukommen, desto stärker sammeln sich die Punkte an den Grenzflächen. Genauso arbeiten reale Nutzer meist nahe an den Grenzen eines Systems. Dass all diese Edge Cases optimal aufgefangen werden, ist letztlich der Grund, warum alte bestehende Systeme so geworden sind.
In meinem früheren Job entstand ein großer Teil der Komplexität aus Refactorings oder Verbesserungsversuchen, die scheiterten, unterwegs abgebrochen wurden oder unvollständig blieben. Ich habe mich oft gefragt, ob wir ein einfacheres System geerbt hätten, wenn man so etwas frühzeitig verhindert hätte. Das heißt nicht, dass man Refactorings und Verbesserungen komplett vermeiden sollte, aber ich denke, sie sollten so geplant werden, dass sie wirklich 100 % der Use Cases abdecken, mit gesichertem Budget und klaren Milestones, damit schrittweise Verbesserungen auch tatsächlich garantiert sind.
Ich wünschte, der Ursprung der Formulierung „das Einfachste, das möglich ist“ wäre klar benannt worden. Dieser Satz war ein Prinzip, das die Wiki-Erfinder Ward Cunningham und Kent Beck bei ihrer Zusammenarbeit in den späten 80ern oft verwendeten. Während des Codens erinnerten sie sich gegenseitig immer wieder an dieses Prinzip, und später wurde es zu einem wichtigen Thema in Vorträgen und Texten. Wie beim Beispiel mit der geschlossenen Tür erwähnt auch dieser Artikel, dass dieses „Einfach“ je nach Situation unterschiedlich aussehen kann. Eine einfache Lösung zu finden, ist selbst nicht immer einfach. Man war sich auch bewusst, dass dieser Ansatz technische Schulden hinterlassen kann, aber zunächst hatte funktionierender Code Priorität. Persönlich hätte ich mir gewünscht, dass auch in diesem Text die Perspektive technischer Schulden etwas stärker vorkommt.
Kent Beck hat später Extreme Programming formalisiert. Diese Methodik ist eine Sammlung von Praktiken, die dabei helfen, dass sich ein einfaches System natürlich weiterentwickeln kann, wenn sich Anforderungen ändern.
Ich kannte diesen Ausdruck von einem Kollegen, der ihn fast als Lebensmotto benutzt hat, wusste aber nicht, dass Ward Cunningham der Urheber war. Der Satz ist wohl so weit verbreitet, dass kaum noch jemand den ursprünglichen Autor kennt — vielleicht ist genau das die größte Ehre.
Ich fand die Erwähnung von Wiki interessant. In einem früheren Job haben wir Projekte mit Lotus Notes verwaltet, und dort war es praktisch, dass standardmäßig hervorgehoben wurde, wann sich ein Dokument geändert hatte. Im nächsten Projekt nutzten wir nur noch ein Wiki, aber weil man geänderte Dokumente nicht auf einen Blick erkennen konnte, wurde es praktisch unbrauchbar. Es war zwar einfach, aber so einfach, dass die praktische Nutzbarkeit darunter litt.
Über die Definition von „funktioniert“ habe ich in meiner gesamten Karriere am meisten gestritten. Der Satz „Nur weil es funktioniert, ist es noch lange nicht kaputtfrei“ ist für Menschen, die schon einmal selbst etwas repariert haben, intuitiv nachvollziehbar. Handwerker flicken etwas vielleicht erst mit einem kaputten Werkzeug provisorisch und entscheiden dann irgendwann, es zu ersetzen, während Entwickler den Bedarf, wirklich „zu reparieren“, oft nicht so deutlich zu spüren scheinen.
Die schwierigste Zeit meiner Karriere war in einer Firma mit einem Team, das Prototypen liebte. Dieses Team baute sehr schnell nur Proofs of Concept, zeigte sie dem Management in Demos und brachte sie direkt in Produktion. Dadurch entstand bei den Führungskräften der Irrtum: Wenn es so schnell fertig war, kann es doch auch sofort ausgerollt werden. Wenn das verantwortliche Team den Code dann öffnete, fehlten End-to-End-Sicherheit, Validierung, Fehlerbehandlung und andere absolut notwendige Dinge komplett. Am Ende musste alles von Grund auf neu gebaut werden, und die Führungskräfte dachten fälschlich, das Deployment-Team würde die Sache nur unnötig verkomplizieren.
Ich habe irgendwo einmal das eindrucksvolle Zitat gelesen: „Es reicht nicht, dass ein Programm funktioniert. Es muss aus den richtigen Gründen funktionieren.“ Im Kern ist das dieselbe Botschaft.
Solche Gespräche sind beruflich sehr wichtig. Ein System kann in dem Sinn „funktionieren“, dass es die gewünschte Ausgabe erzeugt, und trotzdem in Bezug auf Zuverlässigkeit oder Kosten weiterhin als gescheitert gelten.
Was „funktioniert“ in meiner Arbeit bedeutet, hängt davon ab, wofür mein Arbeitgeber Ressourcen, also meine Zeit, einsetzen will. Wenn ich Zeit in Qualitätsverbesserung investieren darf, gebe ich mein Bestes. Wenn dagegen nur Zielerreichung oder das Abhaken einer Checkliste gefragt ist, arbeite ich eben darauf hin. Ich denke, das Ergebnis folgt letztlich dem, was gemessen wird; ich kann beraten, aber die Entscheidungsmacht liegt nicht bei mir.
Die Ironie solcher Ratschläge ist, dass die Menschen, die sie in der Praxis wirklich gut anwenden können, meist ohnehin schon sehr erfahrene Experten sind. Wie soll man zum Beispiel wissen, was „das Einfachste“ überhaupt ist, oder beurteilen, ob es wirklich tragfähig ist? Ich hatte neulich bei einem selbst gebauten XLSX-Importer einen Fehler in der XML-Namespace-Behandlung, weil ich angenommen hatte, dass Excel immer nur den Default Namespace verwendet. Später bekam ich dann eine Datei mit anderen Namespaces, und sofort brach alles. Es wäre einfach gewesen, nur die Präfixe zu entfernen und irgendwie weiterzumachen, aber ich habe stattdessen vier Stunden investiert und den gesamten Parser namespace-freundlich neu aufgebaut — auch im Sinne meines zukünftigen Ichs. „Das Einfachste“ zu tun ist in der Praxis also gar nicht so einfach, und mit mehr Erfahrung kann man es meist besser einschätzen. Aber ab einem gewissen Erfahrungsgrad braucht man solche Ratschläge vielleicht gar nicht mehr.
Ich denke, der Text selbst spricht auch darüber, warum solche Ratschläge schwer anzuwenden sind. Der Kern ist: Um die einfachste Lösung zu finden, muss man mehrere Ansätze durchdenken, und dafür braucht man letztlich ingenieurmäßiges Denken.
Bei uns im Unternehmen gibt es das Prinzip: „Lasst uns keinen Code in die falsche Richtung ergänzen.“ Auch wenn etwas nur teilweise implementiert ist, wird nur so entwickelt, dass es sich später gut weiterentwickeln lässt. Das ist KISS, aber Abkürzungen sind ausdrücklich nicht erlaubt.
Ich beurteile Einfachheit danach, wie leicht sich etwas übergeben lässt. Ein einzelner Service, der nicht von komplexen Abstraktionen oder Infrastruktur abhängt, ist am Ende am leichtesten zu übergeben. Wer ihn liest, versteht ihn sofort, und auch Übergabe und Debugging sind einfacher. Wenn Abstraktion nötig ist, füge ich sie selbstverständlich ein, und wenn Infrastruktur wirklich gebraucht wird, kommt sie ebenfalls dazu. Entscheidend ist für mich immer die Frage, ob die Struktur beim Übergeben des Codes am leichtesten zu erklären ist. Früher wollte ich möglichst alles abstrahieren, pro Service trennen, konfigurationsbasiert aufbauen und fast keinen eigentlichen Code mehr haben, aber in der Praxis sind Übergabe und Hand-off komplett gescheitert. Heute mache ich die Struktur nur dann komplexer, wenn es wirklich nötig ist, und halte als Standard eine intuitive Einfachheit. Das hilft letztlich beim Onboarding neuer Leute, bei Bugfixes und bei realen Übergaben.
AI vibecoding ist ähnlich. Mit mehr Erfahrung und Know-how wird es leichter, passende Tasks auszuwählen und Agents zu steuern.
Viele Leute übersehen offenbar, dass „das Einfachste“ nicht gleichbedeutend mit einem Hack oder einer hastigen Behelfslösung ist. Gerade ein einfacher Weg verlangt in Wirklichkeit oft mehr Nachdenken und mehr Systemverständnis, und genau das war auch der Punkt am Anfang des Artikels. Viele scheinen nur die Überschrift gelesen und dann ihre eigenen Frustrationen ausgeschüttet zu haben.
Immer wenn ich solche Prinzipien oder starke Behauptungen höre, werde ich grundsätzlich vorsichtig. Wenn jemand so spricht, als gäbe es beim Softwareentwickeln eine universelle richtige Antwort, dann versteht diese Person es oft gerade nicht wirklich. Die eigentliche Schlussfolgerung erfahrener Entwickler lautet, dass Software schwierig ist und Sorgfalt verlangt. Es gibt keine Wunderlösung. Man braucht Offenheit und Rücksichtnahme.
Einfachheit, also die Gegenrichtung von Komplexität, ist beim Vergleich von Softwaredesign-Alternativen fast immer eines der wichtigsten Kriterien. Der Grund ist schlicht, dass Menschen etwas planen, abstimmen, implementieren und warten müssen. Aber Einfachheit zu beurteilen ist extrem schwer, und dem durchschnittlichen Engineer in der Branche kann man in dieser Einschätzung oft nicht trauen. Dazu kommt, dass „Einfachheit“ selbst zu einem fast bedeutungslosen Buzzword geworden ist und häufig nur noch als Gegenargument verwendet wird: „Das hier ist einfacher.“ Eigentlich müsste ein Team Lead solche Themen sauber einfangen, aber es wird zusätzlich schwierig, weil die Fähigkeiten vieler Team Leads immer weniger vertrauenswürdig erscheinen.
Im Artikel gab es dazu auch eine eindrucksvolle Passage. Ein wahrer Meister weiß nicht, was er hinzufügen muss, sondern was er weglassen kann — wie in einer Szene, in der ein Anfänger viele auffällige Bewegungen macht, während der Meister sich kaum bewegt und nur den entscheidenden Treffer setzt.
Beim Lesen des Textes war ich anfangs etwas genervt, aber ich denke, er trifft das Wesen von Trial-and-Error gut, weil „Abkürzungen“ am Ende nur weitere Komplexität hinzufügen. Das Problem entsteht, wenn solche Prinzipien wie Anweisungen des Managements überzogen angewendet werden, sodass man auf komplexe Probleme zu simpel reagiert, Wissen kaum weitergegeben werden kann und später nur noch kompliziertere Aufräumarbeiten bleiben. Umgekehrt werden Dinge oft unnötig komplex, weil man vorher lange an provisorischen Workarounds hing und dann versucht, alles in einem Schlag zu beheben — diesmal aber überzieht. Letztlich müssen Entwickler sich aktiv in Diskussionen einbringen, um schon früh kluge Entscheidungen zu fördern.
Ich halte das noch nicht für ein Warnsignal. Unnötige Komplexität nimmt jeden Tag zu, deshalb muss man sich aktiv für Einfachheit einsetzen. Designer, Produktmanager, sogar Kunden und Architekten neigen instinktiv dazu, mehr Komplexität hinzuzufügen.
Ich verstehe deinen Punkt auch, würde aber darauf hinweisen, dass alles am Ende auf „Alles ist ein Trade-off“ oder „Es gibt kein kostenloses Mittagessen“ hinausläuft. Solche allgemeinen Aussagen sind dennoch eine Verdichtung von Praxiserfahrung und lassen sich nicht völlig beseitigen. Das Problem entsteht, wenn ein nützliches Konzept irgendwann zu Hype oder quasi religiösem Eifer verkommt und am Ende nur noch Debatten über Ordnernamen übrig bleiben.
Während ich in Startups (Seed bis Series C) mehrere 0-1-Systeme gebaut habe, habe ich ein Prinzip verinnerlicht: „Einfachheit ist gleich Robustheit.“ Sowohl bei Erstentwürfen als auch bei Verbesserungen bestehender Systeme verfällt man leicht in Overengineering. Kundenanforderungen entwickeln sich ständig weiter, und selbst wenn man versucht, zukünftige Anforderungen vorherzusehen, liegt man am Ende oft daneben. Einfachheit reduziert nicht nur Fehler, sondern schafft auch die Grundlage dafür, eine Struktur leicht verändern zu können. Ich versuche also, mögliche X, Y und Z im Blick zu behalten, strebe aber trotzdem danach, „das Einfachste, das möglich ist“ zu bauen, um Raum für zukünftige Erweiterung zu lassen. Komplexität erhöht zwangsläufig die Zahl der Einschränkungen, und je mehr sie sich mit der Zeit ansammelt, desto fragiler wird der gesamte Stack.
Ich denke, man muss zumindest ein Stück weit versucht haben, das „ideale System“ zu entwerfen, bevor man am Ende wirklich bei „dem Einfachsten, das möglich ist“ ankommt. Auch um ein System zu bauen, das leicht zu lesen und leicht zu verändern ist, braucht es viel Know-how. Wirklich „einfache“ Verbesserungen entstehen ebenfalls aus Erfahrung und tiefem Verständnis.
Das passt zum Kontext von Gall's law. Nach dieser Theorie ist ein komplexes System, das tatsächlich funktioniert, immer aus einem einfachen System hervorgegangen, dem schrittweise Komplexität hinzugefügt wurde. Ein System, das von Anfang an komplex gebaut wird, funktioniert meist nicht gut. Deshalb sollte man zuerst das einfachste System bauen und dann nach und nach Komplexität ergänzen, wenn die Anforderungen es verlangen.
Ich stimme der Stoßrichtung des Textes zu, denke aber, dass sich die Definition von „Einfachheit“ mit dem Aufkommen von Cloud-Infrastruktur verändert hat. Früher war es eher ein Gegensatz zwischen „einfach, aber nicht skalierbar“ und „komplex, aber skalierbar“, heute ist das nicht mehr so. Eine In-Memory-Rate-Limiting-Lösung mag auf einem einzelnen Server einfach sein, aber sobald man nur zwei Server hat, wird sie sofort zu einem Problem verteilter Zustände. Dagegen bieten Managed Services wie DynamoDB oder ElastiCache sowohl bei einem einzelnen Node als auch bei 1000 Maschinen eine Single Source of Truth und reduzieren Komplexität massiv. Aus der Perspektive „einfache Systeme sind robust“ kann man also sagen, dass der Einsatz von Managed Services auf fundamentaler Ebene einfacher ist. Sie beseitigen wiederkehrende Probleme wie Datenverlust oder das Management verteilter Zustände. Die Bedeutung von „dem Einfachsten, das möglich ist“ scheint sich heute dahin verschoben zu haben, verwaltungsfreie Managed Services klug zu nutzen. Heutzutage spart es oft eher Zeit und Kosten, validierte isolierte Systeme effektiv zu nutzen, statt externe Abhängigkeiten um jeden Preis zu vermeiden.
Ich stimme dem Zitat zu: „So einfach wie möglich, aber nicht einfacher.“ Ich versuche immer, diesem Prinzip zu folgen, frage mich aber ständig, ob mir nur deshalb unnötige Komplexität entgeht, weil ich neue Technologien nicht gut genug kenne, oder ob im Gegenteil alle anderen gerade unnötige Komplexität einführen. In realen Projekten lernt man oft erst durch den tatsächlichen Einsatz, ob etwas wirklich brauchbar ist. Umgekehrt habe ich aber auch gesehen, wie Teams belastet werden, wenn jemand neueste Tools nur aus persönlichen Lerninteressen mit Gewalt in produktive Systeme drückt.
Ich erlebe gerade einen ähnlichen Albtraum. Wegen einer Führungskraft, die immer die neueste Software spannend findet, müssen wir ständig irgendwelche Tools für den Praxiseinsatz prüfen, obwohl völlig unklar ist, ob das überhaupt sinnvoll ist. Es ist belastend, dass wir Woche für Woche solche Erkundungen unabhängig von echten Ergebnissen weiterführen sollen.
In der Praxis sollte man Dinge meiner Meinung nach zuerst auf die einfachste Weise zum Laufen bringen — notfalls auch manuell — und den vollständigen Funktionsumfang erst dann hinzufügen, wenn der Bedarf wirklich da ist. Selbst wenn man anfangs Zeit damit verschwendet, alles zu automatisieren oder mit Tools abzubilden, ist die Erfahrung, später klar zu verstehen, warum etwas überhaupt nötig ist, letztlich wertvoller.
Dieses Gefühl kommt mir sehr bekannt vor. Ich stimme solchen Texten fast immer zu und versuche, Einfachheit praktisch umzusetzen, bin mir aber ständig unsicher, ob das wirklich Weisheit und Pragmatismus sind oder ob mir einfach nur Erfahrung und Können fehlen.
Genau deshalb versuche ich sehr vorsichtig zu sein, nicht in „resume-driven development“ abzurutschen.