Komplexität ohne Wiederkehr. Wie nennt man das?

13

Als Softwareentwickler ist es eine meiner Hauptaufgaben, die Komplexität unter Kontrolle zu halten.

In einigen Projekten gibt es jedoch einen Moment, in dem der Komplexitätsgrad so hoch wird, dass er eine Art "No Return" -Punkt erreicht. Ab diesem Zeitpunkt können Sie das Projekt niemals in kürzerer Zeit auf ein akzeptables Maß an Komplexität zurückführen, als es erforderlich wäre, alles von Grund auf neu zu schreiben.

Hat dieser besondere Moment einen Namen im Dialekt des Programmierers (ähnlich dem Godwinschen Gesetz für Trolle)?

--bearbeiten--

Entschuldigung, wenn ich nicht klar bin. Ich denke nicht, dass dieser "Moment" einen offiziellen Namen hat oder eine ernsthafte Metrik ist. Ich dachte an etwas im Geiste des "Ballmer Peak" in xkcd .

terminology

— Thibault J
quelle

1

Ich sehe eine Kontroverse in Ihrer Definition des fraglichen Punktes: ... in kürzerer Zeit müssten Sie alles von Grund auf neu schreiben , was impliziert, dass diejenigen, die das Projekt neu schreiben werden, gut genug sind oder zumindest besser als diejenigen, die hat das Chaos an erster Stelle geschaffen;)

— mojuba

1

Ich denke, ein Grund, warum es keine Einigung über den Namen gibt, ist, dass es davon abhängt, wer den Code betrachtet. Was für einen Entwickler hoffnungslos komplex oder unerreichbar erscheint, kann für einen anderen Entwickler ziemlich vernünftig erscheinen. In schweren Fällen kompiliere ich einfach eine DLL mit dem Präfix "ms" und sage, dass sie von Microsoft stammt.

— Kevin Hsu

1

Vielleicht würde dies genügen: Technical Debt Event Horizon

— PeterAllenWebb

20

Es geht eher um Wartbarkeit als um Komplexität.

Das Phänomen wird als "technische Verschuldung" bezeichnet, und sobald es ein kritisches Niveau erreicht, ist das Projekt auf dem Weg zum Bankrott.

Ist es das, was du meintest?

Vielen Dank für Ihre Antwort. Mir ist das Konzept der "technischen Abteilung" bekannt. Jedes Projekt hat eine technische Verschuldung. Was ich meine ist: Wie nennen Sie den Moment, in dem diese Schulden so hoch werden, dass Sie es vorziehen würden, das Projekt in den Müll zu werfen und von vorne zu beginnen?

— Thibault J

3

Ich mag Ihren Begriff "technischer Bankrott". Es legt nahe, dass Sie genau wie bei einer tatsächlichen Insolvenz genau prüfen müssen, welche Teile gerettet werden können und welche zurückgelassen werden sollten. Und vielleicht ist eine Umschuldung alles, was wirklich benötigt wird :)

— Jaap

2

@Thibault J: Ich glaube nicht, dass es einen bestimmten Begriff für diesen Moment gibt. Es geht mehr darum zu erkennen, ob Sie vor dieser Zeit noch glücklich oder traurig darüber hinaus gegangen sind.

1

@ Developer Art: ... zu erkennen, ob Sie vor dieser Zeit noch glücklich waren oder traurigerweise darüber hinaus gegangen sind - ich denke, das ist der Schlüssel für eine gute Definition des Punkts: Ein Projekt, das über den Punkt hinausgeht, ist eines, das kein Ingenieur hätte freiwillig übernehmen.

— Mojuba

3

Ich werde für die "technische Insolvenz" Begriff gehen, ich mag es. Und ich werde auch Ihre Definition verwenden.

— Thibault J

16

Der "Punkt der übermäßigen Komplexität" wird im Englischen bezeichnet als:

OH MEIN GOTT, WAS IST DIESER MIST.

Das Problem ist, dass dies auf etwas zutreffen kann, das eigentlich einfach ist, aber so schrecklich umgesetzt wird, dass Sie dieselbe Reaktion haben.

Es kann schwierig sein, etwas sehr Komplexes von etwas sehr Schrecklichem zu unterscheiden.

JEDOCH: Was eigentlich mit jeder Software passiert, ist ein Prozess wie dieser:

Schritt 1: Haben Sie eine schöne Spezifikation, machen Sie ein schönes Design, implementieren Sie schöne Sachen. Alle glücklich.

Am Ende von Schritt 1: Die Entwickler beglückwünschen sich zu der wunderbaren Eleganz ihres Designs und denken glücklich: "Ich habe hier ein wunderbares Vermächtnis, das andere in Zukunft ergänzen können. Es wird wunderbar sein und die Welt wird ein besserer Ort."

Schritt 2: Es werden einige Änderungen vorgenommen, Dinge hinzugefügt und neue Funktionen hinzugefügt. Die Architektur und Struktur von Schritt 1 machten dies zu einem ziemlich schmerzlosen Prozess. [Aber hoppla, der "Cruft-Faktor" hat sich nur ein bisschen erhöht.]

Am Ende von Schritt 2: Die Entwickler beglückwünschen sich zu der wunderbaren Eleganz ihres Designs und denken glücklich: "Ich bin so schlau, all diese Dinge in Schritt 1 berücksichtigt zu haben. Das ist so gut gelaufen. Ich habe ein wunderbares Erbe hier, damit andere in Zukunft etwas hinzufügen können, wird es wunderbar sein und die Welt wird ein besserer Ort sein. "

Schritt 3: Es werden mehr Änderungen vorgenommen, es werden mehr Dinge hinzugefügt, es werden mehr neue Funktionen hinzugefügt, eine Menge Dinge werden geändert, das Feedback der Benutzer wird tatsächlich angehört.

Am Ende von Schritt 3: Die Entwickler beglückwünschen sich zu der wunderbaren Eleganz ihres Designs und gehen ziemlich fröhlich davon über X und Y und Z. Sie könnten jetzt ein bisschen aufgeräumt werden. Aber !!! Ahhh !!! Ich bin so schlau, all diese Rücksichten in Schritt 1 gemacht zu haben. Das lief so gut. Ich habe ein wundervolles Vermächtnis hier für andere Dinge in Zukunft hinzuzufügen, wird es wunderbar sein und die Welt wird ein besserer Ort sein. "

Schritt 4: Genau wie Schritt 3. Außer:

Am Ende von Schritt 4: Die Entwickler denken: "Dieses Zeug, das so gut war, wird immer hässlicher. Es braucht wirklich einige gravierende Änderungen. Ich mag es nicht wirklich, daran zu arbeiten. Es muss umgestaltet werden. Ich frage mich, was der Chef ist werde sagen, wenn ich ihm sage, dass es 6 Wochen dauert und am Ende nichts für die Benutzer zu sehen sein wird ... aber ich werde weitere 5 Jahre leckeren zukünftigen Änderungsumfang haben, indem ich dies tue ... hmmm ... Zeit, in die Kneipe zu gehen und ein Bier zu trinken. "

Schritt 5: Es müssen einige Änderungen vorgenommen werden.

Und WÄHREND Schritt 5 sagen die Entwickler zueinander: "Dieser Code ist zum Kotzen. Wer hat das geschrieben? Sie sollten erschossen werden. Es ist schrecklich. Wir MÜSSEN ES NEU SCHREIBEN."

Schritt 5 ist tödlich. Dies ist der Punkt, an dem der Cruft-Faktor so schlecht geworden ist, dass der Code nicht nur ein paar weitere Änderungen aufweisen kann, sondern auch einige BIG-Änderungen erforderlich sind.

Das Problem bei Schritt 5 ist das Verlangen, es wegzuwerfen und von vorne zu beginnen. Der Grund dafür ist "The Netscape Factor". Go google es. Unternehmen sterben an diesem Punkt, denn wenn man wieder anfängt, beginnt man mit ungefähr 50% Annahmen anstelle von Fakten, 150% Enthusiasmus anstelle von Wissen, 200% Arroganz anstelle von Demut ("Diese Leute waren so doof!"). Und Sie führen eine ganze Reihe neuer Fehler ein.

Am besten umgestalten. Ändern Sie ein wenig nach dem anderen. Wenn die Architektur etwas müde wird, beheben Sie sie. Hinzufügen, erweitern, verbessern. Allmählich. Testen, testen und testen Sie bei jedem Schritt auf dem Weg etwas mehr. Inkrementelle Änderungen wie diese bedeuten, dass der aktuelle und ursprüngliche Code 10 Jahre später wie die Axt des Großvaters ist ("es hatte 10 neue Köpfe und 3 neue Griffe, aber es ist immer noch die Axt des Großvaters"). Mit anderen Worten, es gibt nicht mehr viel Gemeinsamkeiten. Aber Sie sind allmählich und vorsichtig vom Alten zum Neuen übergegangen. Dies reduziert das Risiko und für die Kunden den Verärgerungsfaktor.

— schnell_nun
quelle

Ich wette, Sie erhalten mehr Stimmen, wenn Sie Ihre Schritte verkürzen.

— Codism

Ich muss hinzufügen, dass die meisten Unternehmen dies nicht budgetieren, so dass das Refactoring immer zu spät ist. Um die zunehmende Entropie von Systemen zu bewältigen, muss festgelegt werden, dass ab dem ersten Tag ein Budget (10% -20%) für jeden Job für die Haushaltsführung bereitgestellt wird. Es ist kein Bugfix-Budget. Die Budgetausgaben werden vom Engineering festgelegt, nicht vom Management oder Marketing oder Vertrieb. Es wird nur verwendet, um die durch die Entwicklung entstehende Entropie auszugleichen und die Ausgaben zu reduzieren, wenn sich das Produkt dem Lebensende nähert.

— Mattnz

Einverstanden. Das Management möchte immer so etwas zurechtschneiden. Manchmal kann es passieren, dass Sie es nicht mehr anzeigen. (Fügen Sie etwa 20% zur Entwicklungsschätzung hinzu, wenn Sie etwas tun, und wenn ein Refactoring erforderlich ist - DO IT).

— quick_now

1

Es gibt einen Punkt, an dem man nicht wirklich umgestalten kann. Wenn Sie mehrere unterschiedliche Geschäftsanwendungen haben, die von derselben miesen Schnittstelle oder Datenbank abhängen, können Sie die zugrunde liegenden Probleme nicht sehr gut beheben, ohne alle anderen Anwendungen zu beschädigen, die von der beschissenen Grundlage abhängen. An diesem Punkt sind Sie wirklich geschraubt.

— John Cromartie

2

Ich stimme zu, dass der Moment schwer zu erkennen ist und durch geeignete Prozesse vermieden werden kann. Die Frage war jedoch, wie man es nennt. In der Realwirtschaft gibt es das Konzept der "sinkenden Rendite": Der Punkt, an dem die Erhöhung des Inputs für eine Ressource in einem Prozess Ihren Gesamtgewinn pro Einheit senkt. Dies gilt mit Sicherheit für die Codierung, und selbst gute Dinge wie Abstraktion, Wiederverwendung usw. haben einen solchen Punkt, dass die Rendite sinkt. Der allgemeine programmspezifische Begriff lautet "Überentwicklung". Für jemanden, der dazu neigt, mag ich Joels Begriff " Architektur-Astronaut ".

— Kilian Foth
quelle

1

Zu oft wird guter Code unter dem falschen Eindruck verworfen, dass das neue Team mit neuen Tools es billiger, schneller und zuverlässiger machen kann, nur um das zu finden

Die Komplexität liegt in den undokumentierten Anforderungen
Die neuen Tools sind schwerer zu bedienen als die versprochene Flash-Website
Das neue Team ist nicht so "heiß", wie sie dachten

Möglicherweise kommt die von Ihnen beschriebene Zeit mit einigen Codebasen (ich dachte es früher). Ich habe noch nie persönlich einen Fall erlebt, in dem alter Code dazu führte, dass ein Projekt nicht mehr funktionierte, oder dass Code neu geschrieben wurde, um ein Projekt zu speichern.

In diesen Fällen, in denen Metriken verwendet wurden, um bestimmte problematische Module oder Designs zu identifizieren, die dann ausgesondert und ersetzt wurden, schließe ich diese nicht ein.

— mattnz
quelle

Nun, ich habe ein Projekt gesehen, das so erweitert wurde, dass sein Wartungsbudget das Drei- oder Vierfache des ursprünglichen Entwicklungsbudgets betrug. Wie auch immer, der Begriff, den ich suche, ist keine "offizielle" und ernste Sache, sondern eher so etwas wie der "Ballmer Peak" in xkcd. Entschuldigung, wenn ich nicht ganz klar bin.

— Thibault J

Aber wie kam es dazu? Wenn es wegen komplexer Anforderungen, schlechtem Management und optimistischen Ingenieuren ist, warum sollte ein Umschreiben das Problem beheben?

— Mattnz

Weil das Team, das es umschreibt, nicht dasselbe ist wie derjenige, der es am Anfang geschrieben hat?

— Thibault J

1

Das eigentliche Problem mit diesem theoretischen "Moment" ist, dass es erst nachträglich erkannt wird. Sofern Ihre Kollegen keine Psychopathen sind, wird jedes einzelne Commit in die Codebasis mit der Überzeugung ausgeführt, dass es eine Verbesserung dieser Codebasis darstellt. Wenn Sie nur auf das folgende Durcheinander zurückblicken, können Sie feststellen, dass Sie diesen "Moment" vergangen haben.

Aber ich mag es, dass wir ihm einen Namen geben können. "Gents", könnte man sagen, während sich Ihre Mitentwickler um Sie scharten, "wir haben den Hellespont für Wartbarkeit überschritten. Schreiben Sie Ihrer Frau eine SMS und lassen Sie sie wissen, dass Sie sie eine Weile nicht sehen werden."

— Dan Ray
quelle

"Jeder einzelne Commit in die Codebasis erfolgt mit der Überzeugung, dass dies eine Verbesserung der Codebasis darstellt." Anscheinend haben wir nie in denselben Unternehmen gearbeitet :)

— Thibault J

@ThibaultJ - Vielleicht waren Ihre Kollegen Psychopathen?

— Dan Ray

@Thibault J: Ich glaube, dass jedes einzelne Commit mit der Überzeugung durchgeführt wird, dass es eine Verbesserung gegenüber dieser Codebasis darstellt. Der Glaube ist natürlich manchmal schlecht erforscht und unbegründet.

— David Thornley

Bei meiner letzten Arbeit glaube ich, dass es keine Wartungsverpflichtung gibt, die jemals jemand mit der Überzeugung gemacht hat, dass es eine Verbesserung der Codebasis war.

— Bobby Tables

Manchmal können sich die Anforderungen eines Projekts ausreichend ändern, um das Ersetzen durch ein neues Design zu erzwingen, es ist jedoch möglicherweise erforderlich, Änderungen an der alten Version vorzunehmen. Wenn die meisten früheren Benutzer der alten Version das neue System verwenden und das alte nicht mehr benötigen, kann es durchaus sinnvoll sein, eine Version zu erstellen, die den Anforderungen der wenigen entspricht, für die das neue System ungeeignet ist, selbst wenn dies der Fall wäre Machen Sie das System für die Leute, die es sowieso nicht mehr brauchen, weniger benutzerfreundlich.

— Supercat

-1

Ich weiß nicht, ob es einen Namen gibt, aber wenn es keinen gibt, würde ich vorschlagen, ihn "Schmelzpunkt" zu nennen.

— DPD
quelle

Oder einen anderen nuklearen Begriff ausleihen: kritische Masse.

— John Cromartie

-2

Dies ist keine sehr interessante Frage.

In der Tat ist es trivial.

Es ist so trivial, dass wir zahlreiche Möglichkeiten entwickelt haben, um damit umzugehen.

Wasserfall-Methoden. Viele Leute verbringen viel Zeit damit, Anforderungen und Designdokumente zu überprüfen, um sicherzustellen, dass die Komplexität verwaltet wird.
Agile Methoden. Weniger Leute verbringen weniger Zeit damit, darüber zu diskutieren, was unmittelbar anwendbar ist, um das Problem einer Person zu lösen und Software für sie freizugeben. Komplexität wird gemanagt, weil jeder darauf bedacht ist, etwas herauszubringen.

Das einzige Mal, dass jemand mit "Komplexität" ringt, ist, dass er die Methodik nicht befolgt und seine Zeit nicht richtig verwaltet.

Keine detaillierte Überwachung in einer Wasserfallmethode. Sie sind nicht gezwungen, Zwischenprodukte auf Anforderungen, Architektur, High-Level-Design oder detaillierte Designprüfungen zu überprüfen.
Keine Sprint-Frist oder richtige Prioritäten für Anwendungsfälle in einer agilen Methodik. Sie konzentrieren sich nicht darauf, dem Benutzer so schnell wie möglich etwas freizugeben.

Die Komplexität sollte durch die Festlegung von Zielen begrenzt werden.

Ringen mit Komplexität bedeutet, dass Ziele nicht richtig gesetzt oder belohnt werden.

Es gibt keinen "Wendepunkt". Wenn Komplexitätsmanagement ein Problem darstellt, stimmt organisatorisch bereits etwas nicht.

— S.Lott
quelle

1

Ich verstehe den Punkt nicht. Es ist sehr unwahrscheinlich, dass ein gut geführtes Projekt den Punkt ohne Wiederkehr erreicht, aber nicht alle Projekte werden gut ausgeführt. Einige schlecht gelaufene Projekte werden trotzdem erfolgreich sein, und der Rest wird aus verschiedenen Gründen fehlschlagen, manchmal wird der Komplexitätspunkt nicht erreicht und manchmal nicht.

— David Thornley

@ David Thornley: Das ist mein Punkt. Der "Komplexitätspunkt ohne Wiederkehr" existiert nicht. Es ist einfach altes schlechtes Management. Es ist kein ausgeklügelter Name oder eine Regel erforderlich. Komplexität ist nur ein Symptom für schlechtes Management. Nicht wirklich sehr interessant.

— S.Lott

@S.Lott: Ich denke es gibt es, wenn auch nicht in gut gemanagten Projekten. Es gibt eine Horde schlecht verwalteter Projekte, von denen einige in den komplexen Ereignishorizont rücken und andere nicht. Ich halte es nicht für sinnvoll, alles schlechte Management zusammenzufassen.

— David Thornley

@ David Thornley: Ich denke, es ist sehr schwer, schlechtes Management (was zu schrecklicher Komplexität führt) von schlechtem Management (was dazu führt, dass alle aufhören) zu trennen. Ich kann nicht sagen, ob ein Projekt zu komplex, zu spät oder inkompetent wird.

— S.Lott

@ S.Lott: Es gibt jedoch eine Unterscheidung zwischen einem Projekt, bei dem jeder aufhört oder unter einer schwerwiegenden Störung des Gesundheitszustands leidet, und einem Projekt, bei dem die Komplexität zu groß wird. Es gibt verschiedene Möglichkeiten, um zu scheitern, und es kann interessant oder sogar nützlich sein, sie zu kategorisieren.

— David Thornley

-2

Es gibt Methoden, um das Risiko einer zunehmenden Komplexität von (großen) Projekten und Code zu visualisieren und zu überwachen. Wenn sie vernünftigerweise angewendet werden, wird hoffentlich kein neuer Name für den Punkt ohne Rückkehr benötigt. (Es gibt ein ähnliches MOOC bei openHPI: https://open.hpi.de/courses/softwareanalytics2015/ )

Strukturelle Komplexität ist ein allgemeines Designproblem - nicht nur für das Software-Design in großen Teams. Die Visualisierung ist der erste Schritt im strukturellen Komplexitätsmanagement. Zu diesem Zweck können auch Matrizen und gerichtete Graphen verwendet werden.

Einige Methoden zur Reduzierung der strukturellen Komplexität sind http://www.buch.de/shop/home/suche/?fq=3540878890 :

Modularisierung
Vermeidung von Rückkopplungsschleifen
Triangulation

Darüber hinaus gibt es das Konzept des axiomatischen Designs: https://en.wikipedia.org/wiki/Axiomatic_design Mit diesem Konzept können Zuverlässigkeitsprobleme aufgrund unnötiger Komplexität vermieden werden.

Somit stehen eine Reihe von Methoden zur Verfügung. Am Ende geht es immer um die Entscheidung, darüber nachzudenken, weil ein Projekt groß genug wird.

— Eddi
quelle

Dies beantwortet die Frage nicht.

— Hulk