Ab morgen beginnen wir neu zu leben. Wir werden Scrum haben und es wird Glück geben. Vollständige Demokratie: Keine Chefs, das Team entscheidet, was zu tun ist, die Bürokratie wird abgebaut, die Hauptsache ist, dem Kunden Gutes zu tun.
Ein Trainer kam und brachte uns die Grundlagen bei. Er sprach über den bevorstehenden Erfolg, über Effizienz und Kundenorientierung, über die beispiellose Flexibilität und Bedeutung der Einbeziehung eines Kunden in den Entwicklungsprozess und über Raumschiffe, die das Bolschoi-Theater pflügen.
Gut, gut. Kommt Zeit, kommt Rat.
Wir starten ein neues Projekt. Gott sei Dank!
Und dann habe ich mich schon mit Moos bedeckt, als ich über dem Legacy-Code saß. Meine Stärke ist nicht mehr, ich kann mit diesem großen Pasta-Monster nicht fertig werden. Ich habe irgendwie versucht, die Schaltfläche im Anmeldeformular zu verschieben, daher habe ich Fehler vom Mail-Modul erhalten. Überlegen Sie, wo die Verbindung ist ...
Sie stellten uns einen neuen Mitarbeiter vor, wir werden einen Product Owner oder in russischer Sprache einen Kundenvertreter haben. Ich heiße Rita. Charmante Frau. Liebt es zu reden.
Stellen Sie ihr eine einfache Frage, damit sie eine halbe Stunde lang eine Rede hält. Du siehst sie an und denkst: "Äh, du verstehst nichts Verdammtes!"
Fünf Minuten später beginnen Sie zu zweifeln: "Nein, wie es heißt."
Am Ende stellen Sie fest, dass Sie keine Antwort auf Ihre Frage erhalten haben. Also gehst du.
Die Hauptsache ist, es zu unterbrechen, es gibt keinen Weg. Sie versucht, den verbalen Fluss in die richtige Richtung zu lenken, aber wo sie ist, weiß sie, dass sie eingegossen ist und erzählt erneut von den Schiffen und dem Bolschoi-Theater.
Wir hatten schon Angst, ihr auch nur einfache Fragen zu stellen. Sie können eine Antwort bekommen, aber Sie können im verbalen Ozean ertrinken.
Ja, die Bürokratie ist in der Tat geringer geworden. Weil jeder bei der Dokumentation im Allgemeinen punktete. Jetzt werden Informationen hauptsächlich mündlich übertragen. Natürlich verstehe ich alles, wir sind sehr agil, aber nicht im gleichen Maße ...
Angesichts der Aufgabe: im Gateway die Fähigkeit des Clients zu entwickeln, Daten zur Anzeige des Diagramms zu empfangen. Sie müssen zum Dienst gehen, die Rohdaten abrufen, nachzählen und dem Kunden geben. Es gibt keine Spezifikation, was und wie zu zählen ist - niemand weiß es. Es gibt nur den Namen des Diagramms. Nun, wie soll ich das machen, frage ich mich?
Okay, ich habe irgendwo in unseren alten Projekten nach etwas Ähnlichem gesucht und ein Muster erstellt. Es gibt keine Gewissheit, dass dies erforderlich ist, nein. Seltsam, aber niemand kümmert sich wirklich darum. Hauptsache, wir haben bei einer Demo-Rallye erfolgreich neue Funktionen eingeführt.
Ich komme heute zur Arbeit, dort haben Testerinnen unseren Scrum-Meister Kolya umzingelt und sie fordern, ihnen zu erklären, wie die neue Funktionalität funktioniert. Kolya schaut mit Blechaugen auf den Monitor und murmelt etwas über die Modelle und über sich ändernde Anforderungen.
Sie können Kolya verstehen: Sie haben vor einem Monat etwas geändert, und es ist schwierig, sich genau daran zu erinnern, dass es keine Dokumentation gibt. Aber die Mädchen sind kein Zucker: Sie wurden angewiesen, etwas zu testen, ich weiß nicht was.
Eine halbe Stunde später traf ich sie im Korridor: Kolya ging, die Mädchen folgten ihm und alle gackerten: "Neues Modell ... altes Modell ... Kundenanforderungen ..."
Die Armen ...
Ich habe eine Pull-Anfrage für eine Überprüfung erhalten. Fehler beim Exportieren des Diagramms: Die Proportionen von Höhe und Breite unterscheiden sich vom Original. Es ist seltsam, weil ich dieses Problem einmal gelöst und mich um alle Proportionen gekümmert hatte ... Das Problem wurde auf originelle Weise gelöst: Ein Kollege multiplizierte einfach die Höhe mit 1,25.
Ich frage ihn:
- Was bedeutet dieser Koeffizient?
"Und das", sagt er, "ich habe es aufgegriffen." Jetzt wird alles gut.
Um wie viel Uhr! Er nahm auf ... Und was wird mit dem Export anderer Charts passieren? Sie begannen zu verstehen, es stellte sich heraus, dass Sie nur die Reihenfolge der Anrufe leicht ändern müssen. In einigen sehr seltenen Fällen werden Ihre Canvas-Einstellungen verwendet, und Sie müssen die Proportionen danach neu berechnen.
Man hat den Eindruck, dass es manchmal wichtig ist, dass Menschen auf irgendeine Weise über ihre Arbeit berichten, und das Endergebnis stört sie nicht wirklich ...
Heute sagte Rita, dass sie sich für das unendliche Scrollen entschieden hat, wenn sie eine Liste von Dokumenten anzeigt. Ich habe versucht, sie davon zu überzeugen, dass sich die Situation im REST-Service ständig ändert: Einige Benutzer fügen Dokumente hinzu, andere löschen. Infolgedessen erscheinen entweder zusätzliche Elemente in der Form oder sie verschwinden, daher ist es besser, das gute Alter zu verwenden. Zu dem mir gesagt wurde, dass eine solche Situation selten ist und endloses Scrollen modisch und sexy ist, werden Benutzer glücklich sein.
Bist du zufrieden Hmm ... Ich wäre verärgert, wenn ich feststellen würde, dass die Liste nicht dem aktuellen Status entspricht ...
Ich verstehe nicht, wie es möglich ist, ein Gebäude aus Scheiße und Stöcken ohne Fundament zu bauen, wobei gleichzeitig aus vier Winkeln gleichzeitig begonnen wird. Manchmal denke ich, wenn Flugzeuge, Dampfschiffe und Wolkenkratzer wie moderne Software konstruiert würden, würden die Flugzeuge sofort fallen, die Schiffe auf den Kopf gestellt und unsere Städte würden in Trümmern liegen. Es ist klar, dass unser Fehlerpreis viel niedriger ist. Am Ende erstellen wir keine medizinische Software oder Weltraumsoftware. Unsere Software ist jedoch kompliziert und verwendet viele Microservices. Es ist notwendig, auf die vorläufige Untersuchung der Details zu achten!
Es ist gut, dass wir keine Flugzeuge bauen ...
Er schaute in die benachbarte Abteilung und spürte von der Schwelle aus, dass etwas nicht stimmte. Alle sitzen und klopfen wütend an die Tastatur, und in der Luft liegt eine Art allgemeines Unglück.
Plötzlich springt ihr Scrum Master Vitya und wie man jemanden anschreit:
- Was schreibst du mir allen? Sag es mündlich!
Und dann brachen sie durch. Auf einmal wurde schwindelig. Mündlich. Der Lärm stieg außergewöhnlich.
Ich stand eine Minute da, hustete, alle verstummten und starrten mich an. Ich fühlte mich plötzlich irgendwie unwohl.
Victor sagt:
- Sie haben die Berechtigung im Dienst geändert?
"Ja", antworte ich, "verändert." Jetzt können Benutzer ohne Rechte die Ressource nicht lesen. Es ist notwendig, einen anderen Weg zu verwenden.
- Sie haben sich also geändert - sagt er - und jetzt funktioniert die Anwendung nicht mehr für uns.
Er schwieg eine Weile und fügte hinzu:
- Du hast alles richtig gemacht, das ist unsere Neigung. Wir müssen die Veröffentlichung jedoch nach drei Stunden einführen, und wir können den Fehler nicht so schnell beheben.
Ich wollte ihnen sagen: "Nun, zum Teufel, Sie haben die Tests noch nie durchgeführt, weil die Woche bereits vergangen ist!", Aber sie schauten in ihre Gesichter, drehten sich um und machten einen Rollback im Service.
Der Chef hat uns heute versammelt und sagt:
- Wir sollten ein Epos haben. Wir möchten maschinelles Lernen einführen, um die Suchergebnisse anzupassen.
Die Leute interessieren sich natürlich dafür, was gemeint ist und ob es eine Beschreibung des Problems gibt.
- Es gibt noch keine vollständige Beschreibung, ich werde Ihnen Links zu dem werfen, was ist. Denken Sie jetzt nach, - Antworten. Und ging.
Dann habe ich mir die Seite unter seinem Link angesehen: Überschrift und zwei Absätze. Und wie sollten Sie bestellen, wenn nicht klar ist, woran Sie denken sollen?
Was passiert mit ihnen, weil es technische Leute gab, die aus einfachen Entwicklern hervorgegangen sind, und jetzt ist es, als wären sie zu Kunden entartet. Ich habe irgendwo gehört, dass künstliche Intelligenz modisch und cool ist, und lasst uns ein Epos beginnen. Weder eine Aufgabe zu konkretisieren, noch eine genaue Spezifikation zu schreiben, alles ist alles Materie und Raumschiffe mit Theatern ...
Ich treffe Vitya heute im Korridor und frage:
"Nun, hast du einen Fehler gefunden?" Ein Monat ist vergangen. Es wäre notwendig, die Autorisierung im Dienst wiederherzustellen, sonst leben wir mit einem Loch.
Vitya schaut weg und sagt:
- Nein, noch nicht gefunden. Es ist überhaupt nicht genug Zeit ...
Nun, hier bist du. Einen Monat lang können Menschen keinen Ort finden, an dem der falsche Endpunkt verwendet wird. Anscheinend haben sie dies bereits aufgegeben und beschäftigen sich mit aktuellen Angelegenheiten. Es ist seltsam, weil das Programm tatsächlich falsche Daten verwendet ...
Ja, hier hat sich unser neues Tor in einen engen Ball aus Nudeln verwandelt, und es ist bereits unmöglich, die Enden zu finden. Schnell haben wir es geschafft!
Ich versuche meine Kollegen davon zu überzeugen, mit meinen Vorgesetzten über den aktuellen Stand der Dinge zu sprechen. Aus meiner Sicht befindet sich das Projekt in einem bedauerlichen Zustand: Verschiedene Teams lösen ihre Aufgaben, nehmen Änderungen vor, die das Chaos erhöhen, und die Entropie wächst. Das Lösen von Problemen wird jedes Mal komplizierter.
Die Jungs stimmen mir zu, aber meine Initiativen sind cool. Und sie können verstanden werden: Jeder hat aktuelle Aufgaben, die während des Sprints gelöst werden müssen. Es liegt nicht am Philosophieren, Dinge müssen getan werden ...
Ich gebe zu: Ich habe dieses Tagebuch erfunden. Alle Charaktere sind fiktiv, Zufälle sind zufällig. Das ist nur ein Witz.
Es kommt manchmal vor, dass das Management Agile als etwas vulgär empfindet: Es reicht aus, die Aufgabe leicht zu skizzieren, und ein gutes Team wird alle architektonischen und konzeptionellen Probleme selbst lösen. Oft vergessen sie die Notwendigkeit einer gründlichen Dokumentation, obwohl die Verwendung von Agile keineswegs die Ablehnung der Dokumentation bedeutet.
Ich wollte jedoch nicht über Agile oder Entwicklungstechnologien sprechen. Ich möchte über die Qualität der von uns erstellten Software spekulieren und darüber, wie schlechte Entscheidungen diese Software zerstören können.
Interessenkonflikt
Sie sind Entwickler. Das Projekt oder ein Teil des Projekts, an dem Sie arbeiten, ist Ihr Lieblingskind. Du erschaffst und pflegst es, du willst, dass du eine perfekte Schöpfung hast. Damit Ihre Kollegen und Benutzer sagen können: "Ja, das ist eine coole Sache!".
Aber Sie arbeiten für das Unternehmen, das Sie eingestellt hat. Das Geschäft interessiert sich nicht für Ihre Ambitionen. Das Hauptziel eines Unternehmens ist zu Recht der Gewinn. Hier sind Sie gleichzeitig mit dem Geschäft, weil Sie möchten, dass so viele Menschen wie möglich Ihr Projekt nutzen?
Aber aus dem einen oder anderen Grund kann ein Unternehmen Entscheidungen treffen, die die Harmonie Ihres Projekts verletzen. Nehmen wir an, Sie müssen etwas sehr schnell festziehen, sonst geht der Kunde. Es ist keine Zeit, das Problem richtig zu lösen.
Was tun?
Höchstwahrscheinlich müssen Sie sich brechen, in der Hoffnung, dass die aktuellen Krücken später entfernt werden können ...
Allerdings ist nicht alles so traurig. Auf lange Sicht ist das Geschäft Ihr Verbündeter im Kampf um Qualität, es sei denn, er ist natürlich ein Feind seiner selbst.
Allerdings musste ich mir einen solchen Ansatz einfallen lassen, dass eine sorgfältige Ausarbeitung von Details und Analysen manchmal vernachlässigt werden kann, da eine schnelle und kostengünstige Kundenzufriedenheit am wichtigsten ist. Ist in diesem Fall Erfolg möglich?
Ist Erfolg möglich?
Das Paradoxe ist, dass solche Produkte zumindest in der ersten Phase kommerziell erfolgreich sein können. Kunden ärgern sich natürlich über viele Mängel und Inkonsistenzen im System, aber im Allgemeinen löst das Produkt ihre Probleme.
Kunden sind mit dem Grad der Unterstützung zufrieden: Sie gehen auf ihre Bedürfnisse ein und versuchen, neue Bedürfnisse schnell zu erfüllen. Einige von ihnen bemerken zwar, dass das System im Laufe der Zeit immer inkonsistenter und unvorhersehbarer wird, die Benutzeroberfläche immer komplizierter wird, es immer schwieriger wird zu verstehen, was im Inneren passiert, wie ein bestimmtes Problem richtig gelöst werden kann, es gibt Probleme mit der Reaktionszeit und so weiter. Dies geschieht jedoch allmählich und zunächst unmerklich.
Niemand ahnt, dass das Projekt zum Scheitern verurteilt ist. Bald wird er unweigerlich von der Schwere aller Erweiterungen, die mit ihm verbunden sind, in Eile zusammenbrechen.
Wie verbunden ist die innere Harmonie des Produkts mit seinen Verbraucherqualitäten? Es kommt häufig vor, dass Entwickler vom internen Zustand des Systems permanent entsetzt sind, während die Kunden scheinbar zufrieden sind. Aber kann ein hässliches Flugzeug gut sein? Und sollte sich die innere Harmonie eines Produkts nicht in seinen Verbraucherqualitäten widerspiegeln?
Es ist kein Geheimnis, dass oft obszöne Innenseiten hinter einer schönen Fassade verborgen sind, und dies gilt nicht nur für kleine Unternehmen, sondern auch für Giganten der Softwareindustrie. Hier ist nur ein
Beispiel .
Monsterfirmen können es sich leisten, Tausende von Programmierern einzustellen, um das gigantische Spaghetti-Gericht zu unterstützen, zu dem ihr Produkt im Laufe der Jahre und Jahrzehnte geworden ist. Für kleine Unternehmen ist dies jedoch ein Killer-Weg. Übrigens, selbst für Monster ist die geringe Qualität des Codes nicht spurlos und führt zu einer exponentiell zunehmenden Entwicklungs- und Implementierungszeit für jedes neue Feature, einer Erhöhung der Prozesskosten und einer ständig sinkenden Supportqualität.
Was ist wichtiger: Produktqualität oder Verkaufskompetenz?
Ein Qualitätsprodukt ist leider keine Garantie für den Erfolg.
Ich hatte einen Fall in der Praxis, in dem ein hochspezialisiertes Programm, das in Russland gut funktionierte, auf den europäischen Markt gebracht werden musste. Das Programm verwendete ein eigenes Datenformat, und die Konvertierung der zu diesem Zeitpunkt verfügbaren Kundendaten war nicht besonders schwierig. Wenn es uns gelingen würde, Verträge abzuschließen, würden wir für eine Weile Monopolisten in Europa werden. Es scheint, dass alles auf unserer Seite ist: Die Nachfrage auf dem Markt ist groß, bis jetzt kann niemand etwas Vollständiges und wirklich Funktionierendes anbieten, außer uns, das Programm arbeitet bereits an Hunderten von Arbeitsplätzen in Russland, russische Kunden reagieren positiv auf das Produkt.
Haben wir es also geschafft? Leider nein. Die Ausschreibung wurde von einem europäischen Unternehmen gewonnen, das bereits mit Kunden in anderen Bereichen zusammengearbeitet hat. Sie waren in diesem Moment erst am Anfang des Weges, den wir bereits gegangen waren, aber es gelang uns, uns zu schlagen. Wir hatten leider keine guten Spezialisten für Werbung und Verkauf und konnten die Leute nicht davon überzeugen, eine Entscheidung zugunsten unseres Unternehmens zu treffen. Dann, nach einiger Zeit, war es sehr enttäuschend, unsere Erfolge bei der Organisation der Benutzeroberfläche in ihrem neuen Produkt zu sehen ...
Schlechte Entscheidungen
Ein qualitativ hochwertiges Produkt ist ein strategisches Ziel, und ein intelligentes Unternehmen wird immer auf der Seite des Entwicklers stehen und nach Spitzenleistungen streben. Die Aufrechterhaltung der inneren Harmonie des Produkts ist jedoch nicht einfach. Mit der Entwicklung des Produkts kommen neue Anforderungen an uns, die die ursprüngliche Harmonie der Konzepte zerstören können. Die Entscheidungen, die in diesem Fall getroffen werden, spielen eine entscheidende Rolle für das zukünftige Schicksal des Produkts.
Niemand ist vor schlechten Entscheidungen sicher. Wenn eine strategische Entscheidung in der Entwurfsphase getroffen wird und im Laufe der Zeit klar wird, dass sie falsch war, führt dies zum Tod des Projekts. Während der Entwicklung werden jedoch häufig schlechte Entscheidungen getroffen, wenn neue Funktionen hinzugefügt werden. Es hängt zum einen von der Globalität der getroffenen Entscheidungen ab, dh zum Grad ihres Einflusses auf das Gesamtsystem, und zum anderen von der Anzahl der Fehlentscheidungen. Wenn die Anzahl der Fehlentscheidungen und der Grad ihres Einflusses eine bestimmte Schwelle überschreiten, beginnt eine lange und schmerzhafte Qual.
Ich möchte Ihnen einige Beispiele für schlechte Entscheidungen aus eigener Erfahrung mitteilen. Natürlich beanspruchen diese Beispiele in keiner Weise akademische Breite und Systematisierung.
Laxe Regeln
Manchmal scheint es uns, dass die Regeln für den Benutzer flexibel sein sollten.
Beispielsweise arbeitet Ihr System mit verschiedenen Arten von Hierarchien, die von Benutzern erstellt wurden. Sie entscheiden, dass für einen der Typen der Knotenschlüssel nur innerhalb der Ebene und nicht in der gesamten Hierarchie eindeutig ist. Dies erscheint praktisch, da der Benutzer die Hierarchie in Ebenen lädt.
Konsequenzen: Jetzt müssen sich Programmierer überall im Code um die Vorbereitung des zusammengesetzten Schlüssels kümmern, was häufig zu Fehlern führt. Wenn Benutzer per Schlüssel auf Websites zugreifen können, bereitet dies ihnen ebenfalls Kopfschmerzen.
Es kann sinnvoll sein, strengere Regeln zu berücksichtigen und die Eindeutigkeit eines Schlüssels in der gesamten Hierarchie zu fordern. Dies kommt sowohl Entwicklern als auch Benutzern zugute.
Verstoß gegen die Regeln
Sie haben eine komplexe Hierarchie von benutzerdefinierten Objekten. Jedes Objekt enthält die Name-Eigenschaft, die der Schlüssel ist, und den Titel mit beliebigem Text. Es gibt eine Reihe formaler Regeln für einen Namen. Beispielsweise sollte der Name keine Leerzeichen oder Sonderzeichen enthalten. Irgendwann entsteht die Aufgabe, Objekte eines Typs automatisch aus einem anderen zu generieren. Der Name sollte auf dem Titel basieren und erkennbar sein. Sie beschließen, die Regeln zu brechen und Titel als Namen zu verwenden: Es scheint Ihnen, dass dies für Benutzer am bequemsten ist.
Machen Sie sich bereit für Probleme in Ihrem System, die an unerwarteten Orten auftreten.
Komplexitätseinstellungen
Sie geben Einstellungen ein, die nur unter bestimmten Bedingungen gültig sind. Wenn einige Installationen unter der Bedingung betrieben werden, dass andere enthalten sind, ist dies eine recht häufige Situation. Aber wenn Sie eine komplexe Hierarchie von Einstellungen haben, von denen einige funktionieren, wenn andere eingeschaltet sind, und diese wiederum bedingt sind, ist dies der Weg zum Chaos. Die Erfahrung zeigt, dass in diesem Fall niemand bereit ist, vorherzusagen, wie sich die Änderung in einer bestimmten Installation auf das Verhalten auswirkt: weder Benutzer noch Entwickler. Das Einstellungssystem sollte klar, so offensichtlich wie möglich und sorgfältig durchdacht sein. Sie sollten sich bemühen, die Abhängigkeiten einiger Einstellungen von anderen zu verringern.
Fehlende Analyse des Problems
Ihr System ermöglicht es dem Benutzer, Berichte basierend auf DSL zu erstellen. Zunächst wurde entschieden, dass DSL alle Eigenschaften des Berichts enthält. Nach einiger Zeit fordert Sie einer der Clients auf, die Möglichkeit hinzuzufügen, einen Teil der Installationen separat zu speichern. Dies ist erforderlich, um einige interne Probleme des Clients zu lösen. Das Starten einer Aufgabe in Jiras "Externe Einstellungen hinzufügen" ohne vorherige Analyse des Problems ist ein Fehler. Zunächst muss die Frage beantwortet werden: Warum wurde es überhaupt benötigt? Es kann sich herausstellen, dass der Client nur einen Teil der Einstellungen für einige Benutzer ausblenden möchte. Vielleicht sollten Sie in Betracht ziehen, DSL mit Genehmigung dieser Teile in Teile aufzuteilen? Die Entscheidung ist nicht so schnell, aber vielleicht strategisch korrekt.
Politische Entscheidungen
Manchmal werden Entscheidungen aus organisatorischen Gründen getroffen. Beispielsweise werden bestimmte Ressourcen in einem speziell dafür entwickelten Microservice gespeichert. Es sind mehrere ähnliche Ressourcentypen erforderlich. Ein Team ist an dem Service beteiligt, während andere neue Arten von Ressourcen benötigen. Um die Verantwortung zu teilen, wird beschlossen, neue Typen nicht zum ursprünglichen Dienst, sondern zu den von anderen Teams ausgeführten Diensten hinzuzufügen.
Das Problem ist, dass der Dienst nicht nur Daten gespeichert, sondern auch eine Autorisierung bereitgestellt hat. Jetzt müssen Sie sich irgendwie darum kümmern, den Code wiederzuverwenden. Das ist aber nicht die Hauptsache. Die Hauptsache ist, dass es jetzt nicht offensichtlich ist, welcher Dienst verwendet werden soll, um die erforderlichen Daten zu erhalten.
Die internen Beweise für den Aufbau eines Systems werden organisatorischen oder politischen Motiven geopfert.Fazit
Als Entwickler möchte ich stolz auf die Ergebnisse meiner Arbeit sein. Für mich ist die innere Schönheit, Eleganz und Harmonie des Projekts wichtig. Aber nicht weniger wichtig ist die Nachfrage. Ich möchte nicht für den Warenkorb arbeiten, ich möchte, dass so viele Menschen wie möglich das Produkt verwenden und zufrieden sind. Ich verstehe, dass man manchmal auf die Kosten gehen und die innere Harmonie ein wenig verderben muss, um die Interessen einzelner Kunden zu befriedigen. Aber ich bin überzeugt, dass es hinter der schönen Fassade keine Schande geben sollte, hässliche Innenräume werden früher oder später nach draußen gehen, es spielt keine Rolle, ob dies eine externe Verwirrung in den Konzepten oder eine ständig zunehmende Reaktionszeit auf Kundenprobleme ist.Die Schönheit und Harmonie des Produkts ist am wichtigsten. Ja, wir sind manchmal gezwungen, im Interesse des Geschäfts Kompromisse einzugehen, und sind bereit, die Klarheit der Ansätze im Interesse eines bestimmten Kunden zu verwischen, insbesondere wenn es sich um einen sehr wichtigen Kunden handelt, aber dies ist ein schlüpfriger Hang.Mehr als einmal musste ich das allmähliche Aussterben und den Tod von Projekten beobachten, als sich die Leute nicht die Mühe machten, die Details sorgfältig zu studieren und gedankenlos neue Funktionen einführten, sich nicht um die Inkonsistenzen im Produkt kümmerten und nicht auf die Entstehung neuer und unnötiger Verbindungen zwischen den Modulen achteten. Dies führt immer zu Verwirrung, wenn es immer schwieriger wird, den einfachsten Fehler zu korrigieren, da nicht sicher ist, dass diese Korrektur keine unerwarteten Auswirkungen auf völlig fremde Komponenten und Teile des Systems hat.Ich möchte Ihren Projekten ein langes Leben wünschen!