Verhindert die Wiederverwendung von Software die Wiederholbarkeit von Prozessen?

Wiederverwendung von Code als Problem

Ich habe über diese Frage zur Softwarebereitstellung nachgedacht und bin immer wieder auf das Thema Wiederholbarkeit und / oder Reproduzierbarkeit zurückgekommen . Sie spielen eine Rolle, denn wenn Sie ein Projekt nicht wiederholen, wird es schwieriger, den Prozess zu verbessern, mit dem Sie das Projekt erstellt haben. Das Engineering beinhaltet die ständige Verbesserung der mit dem Entwurf und der Konstruktion verbundenen Prozesse, um Projekte mit höherer Qualität zu produzieren.

Software kann aufgrund ihrer digitalen Form stark auf die Wiederverwendung angewiesen sein. Anstatt ein Modul neu zu schreiben, rufen wir es einfach erneut auf oder kopieren es auf das andere System. Einige Beispiele sind Authentifizierung / Anmeldung oder möglicherweise eine Protokollierungsfunktion. Es gibt viele bekannte Beispiele für diese Kategorien, und die übliche Weisheit besteht darin, das Vorhandene wiederzuverwenden, anstatt das Eigene zu verwenden.

Einige Vergleiche zu anderen Disziplinen

Konstruktion

Im Gegensatz dazu ist der Bau physischer Systeme (Gebäude, Brücken) bei weitem nicht so wiederverwendbar. Es ist wahr, dass die Blaupause eines Hauses viele Male wiederverwendet werden kann, um dieselbe Kopie des Hauses zu bauen, aber die Konstruktion muss jedes Mal durchgeführt werden. So funktioniert Ausschneiden & Einfügen in der analogen Welt nicht. Brückenentwürfe sind weniger wiederverwendbar als Häuser, da die Standortbedingungen variieren.

Baumeister sind Experten, die dafür bekannt sind, dass sie in ihrem Gebiet Dutzende, Hunderte oder Tausende von Dingen entworfen und / oder gebaut haben. Zum Beispiel Frank Lloyd Wright , ein weltbekannter Architekt und Designer designed more than 1,000 structures and completed 532 works. Vergleichen Sie das mit Anders Hejlsberg , der „nur“ fünf Sprachen entworfen hat (Turbo Pascal; Delphi; J ++; C #; Typescript). In vielerlei Hinsicht ist es ein unfairer Vergleich, da die Domänen unterschiedlich sind. Auf einer breiten Ebene ist die quantifizierbare Produktion zweier sehr intelligenter Menschen jedoch sehr unterschiedlich.

Kampfkunst

Kampfkünstler werden sagen, dass die Beherrschung eines Zuges nur aus Tausenden von Wiederholungen resultiert. Nachdem ein Großteil dieser Wiederholungen vorgenommen wurde, sind viele Kampfkünstler überrascht, wie einfach eine zuvor als komplex empfundene Kata oder Form geworden ist. Die Ausbilder dieser Schüler werden auch bemerken, wie die Bewegung flüssiger und zielgerichteter wird und eine Wirtschaftlichkeit der Bewegung aufweist. Ebenso sind erfahrene Kampfkünstler in der Lage, komplexere Katas schneller als weniger erfahrene Studenten aufzunehmen. Die Erfahrung aus Wiederholungen hat ihnen einen Rahmen oder Prozess gegeben, der es ihnen ermöglicht, schneller zu lernen.

Holzbearbeitung

Holzarbeiter erleben eine ähnliche Transformation. Hobby-Holzarbeiter verweisen immer auf ihr erstes Projekt, das viele Schubladen benötigte. Wenn sie das Projekt abschließen, gewinnen sie eine neue Wertschätzung für die Effizienz, die Montagelinien erzielen. Es gibt noch weitere Vorteile, z. B. ein besseres Verständnis der Anordnung der Schubladenteile auf dem Plattenmaterial, um die Holznutzung zu maximieren. Im Vergleich zu Bastlern können professionelle Holzarbeiter Gegenstände, die sie schon oft hergestellt haben, schneller entwerfen, herstellen und herstellen. Sie erlangen auch die Fähigkeit, in der Konstruktion eines anderen Menschen inhärente Probleme zu erkennen, die diesen Fehler in ihrer Arbeit gemacht haben.

Verhindert die Wiederverwendung von Software, dass Softwareentwickler kompetenter werden?

In vielerlei Hinsicht ist Software-Design und -Konstruktion immer neu. Wir wiederholen keine früheren Arbeiten, denn wenn wir ein Modul, eine Bibliothek oder ein System wiederverwenden können, tun wir das auch. Wir werden ein bestehendes System vorzugsweise erweitern, bevor wir das Ganze von Grund auf neu schreiben . Aber Wiederholung ist es, was es uns ermöglicht, Effizienz im Design und in der Konstruktion zu finden. Jeder, der eine Sportart oder körperliche Aktivität ausgeübt hat, wird Ihnen sagen, dass Wiederholung der Schlüssel ist, um ein guter Praktiker zu werden.

Meine Frage: Verhindert die Wiederverwendbarkeit von Software die notwendige Prozessverbesserung und Effizienz, die sich aus der Wiederholung eines Projekts ergibt?

Die Möglichkeit, Software wiederzuverwenden, verhindert keine Prozessverbesserung.

Wenn Sie über die Prozesse nachdenken, die beim Erstellen von Software erforderlich sind - Entwickeln von Anforderungen, Entwerfen des Systems, Implementieren des Systems, Bereitstellen des Systems, Verwalten von Anforderungen, Verwalten von Konfigurationen, Überprüfen und Validieren des Arbeitsprodukts, Nachverfolgen von Änderungen und eine Reihe anderer (siehe CMMI-Prozessbereiche für eine mögliche Aufschlüsselung von Schlüsselaktivitäten in der Softwareentwicklung - diese werden bei jedem Projekt wiederholt, unabhängig davon, wie viel Wiederverwendung Sie haben. Darüber hinaus verfügt jedes Unternehmen über eine Art von quantitativen und qualitativen Maßstäben, anhand derer bestimmt werden kann, wie gut der jeweilige Prozess oder die jeweilige Aktivität ist und wie gut der gesamte Entwicklungsprozess ist.

An einem Ende des Extrems können wir von einer robusten Software-Produktlinie ausgehen. Auf der anderen Seite können Sie von einer Entwicklung auf der grünen Wiese ausgehen. All diese Prozesse müssen immer noch in unterschiedlichem Maße ausgeführt werden, obwohl sie mit unterschiedlichen Raten oder vielleicht sogar in unterschiedlichen Sequenzen ablaufen können. Beispielsweise kann bei einem hohen Wiederverwendungsaufwand ein größerer Prozentsatz der zugewiesenen Zeit für Integrations- und Verifizierungs- / Validierungsaktivitäten auf Systemebene aufgewendet werden (Anforderungen V & V, Integrationstests, Systemtests, Abnahmetests). Bei neuen Entwicklungsbemühungen kann ein größerer Prozentsatz der Zeit für Entwurf und Implementierung erforderlich sein. Solange Sie einen Prozess mindestens einmal im Verlauf eines Projekts durchführen, können Sie ihn messen (quantitativ und qualitativ). Sobald Sie Anpassungen vorgenommen haben und sehen, wie sich diese Anpassungen auf einen Teil des Prozessbereichs oder auf die allgemeine Fähigkeit zur Bereitstellung von Software auswirken,

Der Schlüssel zur Prozessverbesserung besteht darin, eine logische Aufschlüsselung Ihrer Aktivitäten und Prozesse vorzunehmen, zu bestimmen, wie diese gemessen werden sollen (vorzugsweise konsistent) und wie diese Messungen zu verstehen sind, um Prozessänderungen zu einem bestimmten Zeitpunkt vorzunehmen. Es geht nicht darum, das Projekt zu wiederholen, sondern darum, wie Sie den Vorgang wiederholen.

Ich denke, die Idee, dass andere Ingenieurdisziplinen die Wiederverwendung nicht nutzen, ist falsch. Auch beim Entwerfen von Gebäuden / Maschinen stehen Ihnen Komponenten zur Verfügung, die von vielen anderen Projekten verwendet werden. Entwerfen Sie zum Beispiel Ihre eigenen Schrauben? Motoren? Türen oder Fenster? Natürlich nicht. Diese werden oft von verschiedenen Personen entworfen, die sie dann in verschiedenen Produkten verwenden. Und sie sind häufig standardisiert, was eine noch stärkere Wiederverwendung fördert.

Ich denke, das Problem mag in der Komplexität. Sie können die Komplexität selbst komplexester Gebäude einfach nicht mit komplexer Software vergleichen. Es ist eine allgemein akzeptierte Idee, dass Softwarekomplexität es schwierig macht, sich von der Engineering-Seite her zu nähern. In dem Moment, in dem Sie über einen Prozess verfügen, mit dem Sie Software von akzeptabler Qualität erstellen können, stellt sich heraus, dass die Komplexität der Software, die Sie zum Erstellen von Sprüngen benötigen, in der Größenordnung liegt. Der Prozess kann also nicht verwendet werden. Wenn wir also einen Teil der Software mehrmals wiederholen müssten, bis wir mit dem Ergebnis zufrieden sind, würden wir diese Software niemals fertig stellen.

Deshalb wird für sauberen Code geworben. Die Fähigkeit, früheren Code basierend auf neuen Erfahrungen zu ändern, kann als Form der Wiederverwendung von Designs bezeichnet werden. Anstatt also mehrere Male unterschiedliche Software zu erstellen, überarbeiten und verfeinern wir einzelne Softwareteile, indem wir neue Erfahrungen wiederverwenden und alte Probleme weiterentwickeln. Während Sie versuchen, Software dazu zu bringen, dasselbe zu tun.

Software ist anders als die meisten anderen Disziplinen, so die Wirtschaftlichkeit von wo wir am besten verbringen unsere Zeit oft anders ist.

Während des Baus investieren Sie eine gewisse Menge Zeit und Geld in eine Blaupause (und Software ist weitaus mehr mit dem Erstellen einer Blaupause als mit dem Bauen eines Gebäudes vergleichbar). Es lohnt sich also, eine Menge Arbeit in die Erstellung des richtigen Entwurfs zu stecken. Genauer gesagt zu Ihrer Frage - es lohnt sich, die Anstrengungen zu wiederholen, die erforderlich sind, um das Endprodukt ein wenig zu verbessern.

In Software ist es viel billiger, das Produkt zu erstellen, als es für die Erstellung des Entwurfs war, wenn Sie den Entwurf haben. Zumindest die meiste Zeit - wenn die Software in einen Schrittmacher eingebettet wird, sind Sie in gewisser Weise der Situation eines Brückenbauers viel näher. Im Allgemeinen können durch die Wiederverwendung von Software 90% der Kosten Ihres größten Budgets eingespart werden, im Gegensatz zu 90% eines viel kleineren Budgets für den Bau einer Brücke. Wiederverwendung gewinnt also viel häufiger.

Was die Produktivität angeht - wenn Sie beispielsweise eine Brücke bauen, sehen Sie sich erheblichen realen Einschränkungen ausgesetzt. Stellen Sie sich vor, Architekten bekämen viel Geld, um Brücken für massive Multiplayer-Online-Spiele zu entwerfen, bei denen die Baukosten nahe Null lagen und die Beschränkung erheblich geringer war als in der realen Welt. Sie würden Brücken entwerfen, die nach realen Brückenstandards verrückt komplex sind. Die Blueprint-Phase kann etwas länger dauern.

Außerdem muss nur eine begrenzte Anzahl von Brücken gebaut werden, und da Design nur einen geringen Teil der Kosten ausmacht, können Sie für das Beste zahlen, und einige der Besten können den größten Teil des Designs übernehmen. Es gibt Hunderttausende von Software-Entwicklern, und im Grunde haben alle einen riesigen Rückstand auf Dinge, die sie tun würden, wenn sie Zeit hätten. Sie werden nicht einen Mann finden, der einen massiven Teil von all dem macht - es ist ein bisschen überraschend, dass es Leute gibt, die sich wirklich annähern.

Ihr eigentlicher Punkt scheint zu sein, dass wir durch die Wiederverwendung möglicherweise etwas verlieren, anstatt zu versuchen, Dinge zu wiederholen und zu verbessern. Ich denke du hast einen Punkt. Das Problem ist, dass, obwohl es höchstwahrscheinlich effizienter wäre, einige der grundlegenden Dinge neu zu schreiben und zu verbessern, jeder, der das übernimmt, das gesamte Risiko trägt und wahrscheinlich nicht den größten Teil der Belohnung. (Es gibt auch ein riesiges praktisches Problem der Abhängigkeitshölle, das wahrscheinlich einen Teil des Gewinns beim Umschreiben von Dingen mit sich bringt, aber nicht bis zu dem Punkt, an dem es sich nicht lohnen würde, zumindest wenn man sich das globale Bild ansieht. Copyright und Patente können auch Erzwingen Sie einen geplanten Neuentwicklungsaufwand, indem Sie einiges an Neuentwicklungsarbeit unterbinden, um kleinere Teile des vorhandenen Codes zu wiederholen.

In Bezug auf dem von Wiederholung zu lernen - in allen Disziplinen geschieht dies weniger im Design als in der Konstruktion, weil es ist weniger Wiederholungen, so dass weniger Chance zu lernen, und vielleicht weniger Nutzen. Auch der Prozess wahrscheinlich von Design einfach ist das nicht wiederholbar. Es ist ein bisschen wie ein Prozess zum Schreiben eines Romans. Ein guter Prozess kann mit ziemlicher Sicherheit helfen, und Software ist in der Regel weitaus kollaborativer als ein Roman. Es ist jedoch problematisch, einen Prozess zu wiederholen, wenn das Ziel darin besteht, etwas Neues zu erfinden. Sogar Schriftsteller lernen aus der Vergangenheit, aber ein wiederholbarer Prozess ist ein sekundärer Faktor für kreative Bemühungen. Und wenn ein Teil der Softwareentwicklung wirklich reproduzierbar ist, warum macht das dann kein Computer?

Verhindert die Wiederverwendbarkeit von Software die notwendige Prozessverbesserung und Effizienz, die sich aus der Wiederholung eines Projekts ergibt?

Ich habe in den letzten 17 Jahren als System- und Softwareingenieur im selben großen Projekt gearbeitet, nebenbei bemerkt (unter Berücksichtigung der Airbus A380-Referenz in Ihrem ersten Link) in der Flugzeugindustrie, obwohl meine Zuständigkeiten im Bereich Militärflugzeuge liegen. Geschichten wie diese sind im Grunde genommen reine Fiktion und eigentlich sehr lustig anzusehen, wenn man Insider-Einsichten hat.

Aber für Ihre kurze und prägnante Frage: Aus meiner Erfahrung würde ich sowohl Ja als auch Nein sagen.

Lassen Sie mich zunächst sagen, dass ich alles für Software-Recycling in allen Formen bin (na ja, vielleicht nicht alle ...). Die Vorteile der Wiederverwendung von fast allem, von Code-Snippets und -Algorithmen zum Ausschneiden und Einfügen bis hin zu ganzen Codemodulen und Funktionsbibliotheken, sind im Großen und Ganzen weitaus besser, als immer wieder von vorne zu beginnen (um es ein wenig voranzutreiben).

Der Nachteil ist, wie Sie betonen (oder zumindest schließen), dass Sie sich, wenn Sie Funktionalität hinzufügen, indem Sie einfach einen bestimmten Satz von Komponenten zusammenstellen (und ich vereinfache dies bis zum Äußersten), nicht wirklich als ein Mensch entwickeln Programmierer, Ingenieur oder was auch immer.

Wenn ich mir nur die Software-Ingenieure ansehe, die mich bei der Arbeit umgeben, weiß ich aus langjähriger Erfahrung, dass die meisten von ihnen nichts über das Produkt wissen, das wir konstruieren, und dass sie kein Interesse daran haben, etwas anderes zu lernen, als das Nötigste, was sie produzieren müssen das Dokument oder den Code, dem sie zugewiesen sind.

Ich schwanke hier ein bisschen vom Thema ab, aber mein Punkt ist, dass, wenn die Programmierer nicht lernen müssen , wofür der Code, den sie erstellen, wirklich verwendet wird, und sie nicht das Innenleben des Systems lernen müssen , da sie es können Verwenden Sie bereits geschriebene und getestete Komponenten wieder. Die meisten von ihnen werden sich einfach nicht darum kümmern.

Zugegeben, dies ist auch auf andere Umstände zurückzuführen, zum Beispiel, dass das Produkt, das wir konstruieren, unglaublich komplex ist und es unmöglich ist, dass eine Person alles erfährt (und ich spreche nur von einem der Computer im Flugzeug - der komplexeste von ihnen, aber immer noch).

Wenn unsere Softwareingenieure nicht die Möglichkeit hätten, so viel Code wiederzuverwenden, dann wären sie meiner Überzeugung nach im Allgemeinen besser in ihrem Beruf und im Besonderen viel besser für das Projekt.

Oh, und Sie haben vielleicht bemerkt, dass ich hier viel über sie spreche. Zu diesen Software-Ingenieuren gehöre natürlich auch ich. Die Ausnahme ist, dass ich viel neugieriger und lernbegieriger bin als die anderen :-) Wenn ich vor einer neuen Aufgabe stehe, nehme ich es immer auf mich, so viel darüber zu lernen, wie ich kann, sowohl in der Schule als auch in der Schule Form von Fakten und durch das Studium des Quellcodes (ja, das gefällt mir auch).

Ah - verdammt, wieder auf der Seite ... Meine Entschuldigung ist, dass ich 32 Stunden nicht geschlafen habe, also ist meine Konzentrationsfähigkeit ein bisschen ... was habe ich gesagt?

Wenn noch jemand liest, lautet mein Fazit:

Ja , zu viel Wiederverwendung von Software führt dazu, dass weniger sachkundige Softwareingenieure deutlich weniger effizient sind, wenn sie tatsächlich wissen müssen, wie das Zeug funktioniert. Die Problemanalyse ist ein gutes Beispiel, oder sie kann auch nur feststellen, ob eine vorgeschlagene Entwurfslösung realisierbar ist. Und natürlich ist eine Prozessverbesserung auch schwieriger zu erreichen, wenn Sie nicht genau wissen, was Sie tun :-)

und Nein . Wenn Sie Software sorgfältig wiederverwenden , haben Sie möglicherweise viel Zeit, um Prozessverbesserungen zu erwägen und zu planen.

Wie in der akzeptierten Antwort in einer anderen Programmiererfrage ausgeführt, sind Analogien zur Konstruktion mit Sorgfalt zu behandeln:

Eine empfohlene Lektüre hierfür ist The Software Construction Analogy is Broken

Software wird oft mit Konstruktion verglichen. Leider ist diese Analogie fehlerhaft und die Lehren aus der Bauindustrie sind verdächtig ...

Was ich beobachtet habe, ist, dass gute Softwareprojekte viel Wiederholbarkeit in die Qualitätssicherung "verlagern".

Als ich ein Tester in einem 1,5-jährigen Projekt war, haben wir Testzyklen an wöchentlichen "Checkpoint" -Veröffentlichungen durchgeführt, insgesamt etwa 70 Mal während des Projekts. Das war ... leise gesagt ziemlich wiederholbar (es ändert sich nicht viel in einer Woche). Das Testen nächtlicher Builds war natürlich noch wiederholbarer - etwa 500 Mal während des Projekts (wenige unterhaltsame Showstopper-Fehler waren zu selten, um einen Unterschied zu machen).

Sagen Sie mir jetzt anhand dieser "verdächtigen" Analogie eine Baufirma, die 500 Brücken gebaut hat - alle mit demselben Team.

• Sagen Sie mir im Anschluss, dass ein Unternehmen an jeder seiner neuen Brücken zumeist die gleichen Steine ​​und Eisen verwendet hat (hier verweise ich auf die Tatsache, dass die von uns getesteten Releases Tag für Tag und Woche zumeist die gleichen Codeteile aufwiesen) Woche - "nicht viel ändert sich").
  

Baumeister sind Experten, die dafür bekannt sind, dass sie in ihrem Gebiet Dutzende, Hunderte oder Tausende von Dingen entworfen und / oder gebaut haben.

Gut, nach Ihrer oben zitierten Erklärung der Wiederholbarkeit kann ich also was sagen? Damals hat unsere kleine, nicht sehr spezielle Gruppe von Testern überprüft, siehe oben ("etwa 500") Hunderte von Dingen in unserer Region.

Projektentwickler haben buchstäblich gebaut ("Nightly Builds") - siehe, das Wort ist das gleiche und die Bedeutung stimmt in diesem Zusammenhang - Hunderte Dinge in ihrer Region.

Wenn man diese "verdächtige" Analogie bis hin zu "Tausenden von Dingen" fortsetzen will, sind diese Beträge wiederum nichts Spektakuläres in der Softwareentwicklung, wenn man sich die richtigen Dinge ansieht.

• Als Beispiel, ein weiteres meiner vergangenen Projekte (wieder nichts Spektakuläres, eher reguläres), diesmal als Entwickler, läuft seit mehr als 5 Jahren (8 Hauptversionen, mehrere Dutzend Nebenversionen). Es gab ähnliche wöchentliche Checkpoints ( 5x52~=250von ihnen), ähnliche nächtliche Releases ( 5x365~=1800von ihnen) und ähnliche Entwickler- / QA-Teams, die daran arbeiteten. Tag für Tag, Woche für Woche, Monat für Monat, meistens sich wiederholende Dinge (nicht viel Wechsel zwischen zwei nächtlichen Builds) - wie versprochen, im Bereich von Tausenden von Malen (1800).

Langlebigere Projekte wie Windows oder Java oder AutoCAD können eine Laufzeit von 10, 20 oder 30 Jahren haben, was leicht dazu führt, dass so viele "Tausende" nächtliche Builds und nächtliche Tests wie möglich wiederholt werden.

Das Konzept der Verlagerung der Wiederholbarkeit auf die Qualitätssicherung wird durch die kontinuierliche Integration noch wichtiger ...

die Praxis ... alle Entwickler-Arbeitskopien mehrmals am Tag mit einer gemeinsamen Hauptzeile zu verschmelzen ... CI kann als Intensivierung der Praktiken der periodischen Integration angesehen werden.

Zusätzlich zu automatisierten Komponententests verwenden Unternehmen, die CI verwenden, in der Regel einen Build-Server, um kontinuierliche Prozesse zur Durchführung der Qualitätskontrolle im Allgemeinen zu implementieren . Zusätzlich zum Ausführen der Unit- und Integrationstests führen solche Prozesse zusätzliche statische und dynamische Tests durch, messen und profilieren die Leistung, extrahieren und formatieren die Dokumentation aus dem Quellcode und erleichtern manuelle QA-Prozesse. Diese kontinuierliche Anwendung der Qualitätskontrolle Ziele , die zur Verbesserung der Qualität der Software , und die Zeit genommen zu reduzieren zu liefern, durch die traditionelle Praxis der Anwendung der Qualitätskontrolle zu ersetzen nachAbschluss aller Entwicklung. Dies ist sehr ähnlich zu der ursprünglichen Idee, häufiger zu integrieren, um die Integration zu vereinfachen, und gilt nur für QS-Prozesse ...

Wiederholbarkeit? Es ist genau dort, so viel wie man sich vorstellen kann.

Bei häufiger / kontinuierlicher Qualitätssicherung gehen die Probleme schnell zu den Entwicklern zurück, die gezwungen sind, die Versuche zu wiederholen, bis die fehlgeschlagenen Tests erfolgreich bestanden wurden. In gewisser Weise ähnelt dieser Zyklus des Wiederholens bis zum Durchlauf der Code-Cata ,

eine Übung in der Programmierung, die einem Programmierer hilft, seine Fähigkeiten durch Übung und Wiederholung zu verbessern ...

Einiges von dem, was Sie sagen, ist wahr: z. B. Bibliotheken lösen Funktionen, die nicht von Hochsprachen gelöst wurden, die Probleme lösen, die nicht von der Assembly gelöst wurden, die Probleme lösen, die nicht vom Maschinencode gelöst wurden. Wenn Sie in Java System.out.println () aufrufen, verlieren Sie aus den Augen, wie eine CPU auf ein Gerät ausgibt.

Also ja, du verlierst etwas. Was Sie gewinnen, ist die Fähigkeit, sich auf ungelöste Probleme zu konzentrieren. Möglicherweise müssen Sie sich jetzt mit einigen anderen Aspekten der Technologie befassen (z. B. der Funktionsweise von Netzwerken), um ein Problem zu lösen. Sie müssen jedoch kein Experte für Maschinensprache sein, wenn Sie nur eine Webseite erstellen möchten.

Ebenso lösen Brückenbauer jedes Mal ein etwas anderes Problem (es ist ein anderer Fluss). Sie kümmern sich nicht darum, wie Stahlträger mit einer bestimmten Zugfestigkeit hergestellt oder Schrauben mit einer bestimmten Toleranz bearbeitet werden können. Das überlassen sie Spezialisten, die dieses Problem gelöst haben.

Wenn Sie genau hinschauen, werden Sie feststellen, dass unsere gesamte Gesellschaft und Infrastruktur zu 99% auf Wiederverwendung und nur zu 1% auf echtem Fortschritt basiert. Die meisten neuen Dinge sind nur alte Dinge, denen ein kleines Extra hinzugefügt oder entfernt wurde. Es ist die Anhäufung von menschlichem Wissen. Sie können Code in einer höheren Programmiersprache mit anständigen Bibliotheken schreiben, weil jemand all die umwerfend komplizierten Dinge herausgefunden hat, die erforderlich sind, um an diesen Punkt zu gelangen. Es ermöglicht Ihnen, neue und interessante Probleme zu lösen.

Um dies alles zusammenzufügen und auf Kommentare zu antworten: Sie müssen keine Probleme lösen, die bereits gelöst wurden, um die Kompetenz zu entwickeln. Außerdem wird vieles, was Sie tun, das Rad neu erfinden. Kurz gesagt lautet die Antwort also "Nein". Sie müssen die Funktionen von Bibliotheken nicht erneut implementieren, um kompetent zu werden. Es gibt viele Gelegenheiten, einige davon sind kreativ, um Ihr Handwerk zu verbessern.

Es geht nur um Ressourcen. Wenn Sie vor Jahren Softwareprojekte für große Mainframe-Computer entwickelt haben, gibt es diese möglicherweise seit etwa 15 Jahren mit einer weitgehend statischen Entwicklungsumgebung. Das zur Berechnung der Gehaltsabrechnung geschriebene FORTRAN-Programm oder das COBOL-Programm wurde über Jahrzehnte hinweg perfektioniert, da es ständig verwendet wurde. Es gab Ressourcen, um zu sehen, wie dies verbessert werden könnte. Wir haben keine so langsame Umgebung mehr, um die Fähigkeiten für ein bestimmtes Projekt zu verfeinern und zu verbessern. Aber wir nehmen die Fähigkeiten und passen sie an die nächsten Projektressourcen an, sofern dies möglich ist. Aber am Ende wird es zu einer Auswahl von Geldern, die für das neue Projekt ausgegeben werden, um den Job zu erledigen, oder um den neuen Job mit einer großen Menge an Vergoldung zu erledigen. Vergolden eines Projekts bedeutet, es bis zum n-ten Grad zu verbessern und eine Menge Schnickschnack hinzuzufügen, selbst wenn der Benutzer dies nicht getan hat.

Das Beste, was wir tun können, ist das Gesamtdesign eines neuen Projekts zu betrachten und zu sehen, wie es basierend auf den Erfahrungen des Teams in der Vergangenheit verbessert werden kann. Es ist jedoch eine echte Erfahrung, wenn ein Softwarearchitekt eine Vorstellung davon hat, was tatsächlich als Verbesserung des Designs zur Verbesserung der Fähigkeiten angesehen wird, anstatt einfach das neueste Schlagwort in der Entwicklung wie Agile, OOP usw. zu verwenden.