Gibt es einen Zusammenhang zwischen einigen Softwareentwicklungspraktiken und Erfolgsgeschichten der Softwareentwicklung?

Ich habe das Buch " The Drunkard's Walk: Wie Zufälligkeit unser Leben regiert" von Leonard Mlodinow gelesen und es ist eine wirklich aufschlussreiche Lektüre. Das Buch befasst sich mit Wahrscheinlichkeiten und menschlichem Denken. Und lassen Sie uns einfach sagen, dass einige Dinge manchmal funktionieren, aber es besteht die Möglichkeit, dass die Dinge, von denen Sie dachten, dass sie funktionieren, nichts mit dem zu tun haben, was sie tatsächlich funktioniert hat.

Wahrscheinlichkeiten sind nicht intuitiv.

Es gab mir jedoch eine Idee. Es sollte bereits Studien dazu geben, die versucht haben, die Ergebnisse von Software-Engineering-Bemühungen zu quantifizieren (was natürlich an sich ein schwieriges Problem ist). Und diese Studien sollten zeigen, welche Art von Software-Engineering-Praktiken für den quantifizierbaren Erfolg wirklich wichtig sind.

dh

• Ein Team, das TDD einsetzt, hat mit thisviel geringerer Wahrscheinlichkeit thisProbleme.
• Ein Team, das SOLID-Prinzipien anwendet, hat mit thisviel geringerer Wahrscheinlichkeit thisProbleme.
• usw. usw.

Was ich hier suche, sind Software-Engineering-Praktiken, die eine starke Korrelation zwischen Implementierung und Erfolg aufweisen. Ich bin zuversichtlich, dass diese Dinge existieren, aber dass sie schwer zu bekommen sind, und deshalb stelle ich diese Frage.

Welche Studien oder Praktiken kennen Sie, die einen starken Zusammenhang zwischen Implementierung und Erfolg haben (wo Erfolg etwas willkürlich ist, aber ich denke, Sie haben die Idee)?

Wenn wir die Idee verkaufen wollen, dass Software-Engineering besser ist als Cowboy-Codierung, brauchen wir Beweise.

Das Problem bei dieser Art der Quantifizierung ist, dass es fast unmöglich ist, ausreichend Daten über die Wirksamkeit von Software-Engineering-Praktiken zu erhalten, um eine aussagekräftige Schlussfolgerung zu ziehen.

Am wichtigsten ist, dass Korrelation keine Kausalität impliziert. Beispielsweise kann es sein, dass gute Programmierer schnell auf neue Ideen zugreifen und diese umsetzen. Sie sehen also eine allgemeine Korrelation zwischen dem Projekterfolg und der Einführung neuer Softwareentwicklungstechniken. Dies beweist jedoch nichts über die Wirksamkeit der Techniken selbst, da der gesamte Effekt durch das höhere Talentniveau der Programmierer erklärt werden könnte, die sie anwenden.

Und dann ist es schwierig, die unabhängigen Variablen zu steuern . Wie stellen Sie ein faires Experiment sicher, wenn Sie nicht in der Lage sind, alle folgenden Punkte zu kontrollieren?

• Erfahrung / Können / Motivation des Teams
• Tatsächlicher Umfang der Übernahme der beanspruchten Methodik (machen sie TDD wirklich richtig?)
• Vorhandensein / Nichtvorhandensein schwerwiegender Konstruktionsfehler, die nicht mit der Softwareentwicklungsmethode zusammenhängen (z. B. solche, die während des Projekts eine umfassende Neuarchitektur erfordern)
• Schwierigkeitsgrad der verglichenen Projekte
• Auswirkungen von extern auferlegten Problemen (z. B. wesentliche Änderungen der Anforderungen)
• Selektionsbias (z. B. neigten Menschen dazu, häufiger Daten über erfolgreiche Projekte auszutauschen?)
• Bestätigungsvoreingenommenheit (z. B. haben die Leute den Erfolg von Projekten, die ihre Lieblingsmethode verwenden, übertrieben?)

Selbst wenn Sie sich dazu entschließen, das oben genannte Problem zu lösen, indem Sie mehreren sorgfältig ausgewählten Teams unter denselben sorgfältig kontrollierten Bedingungen das gleiche Problem geben, ist Ihr Experiment wahrscheinlich unerschwinglich teuer, wenn Sie genügend Daten erstellen möchten, um statistisch signifikant zu sein.

Und schließlich ist es fast unmöglich, den Erfolg zu messen :

• Eine Mengenmetrik wie Quellcodezeilen (SLOC) ist erschreckend schlecht. Der Anreiz für Entwickler besteht darin, Monstrositäten mit Millionen Zeilen mit Copy / Paste-Codierung zu erstellen, um "produktiver" auszusehen.
• Eine Metrik für Pünktlichkeit und Budget hängt hauptsächlich vom Ehrgeiz der Schätzungen ab, die zur Erstellung des Plans / Budgets verwendet werden
• Eine ROI-Metrik hängt sowohl von der Marktsituation und der kommerziellen Verwaltung des Produkts als auch von der Qualität der technischen Ausgabe ab (siehe die Geschichte von Microsoft Windows!).
• Story Points sind nützlich, um ein Gefühl für Geschwindigkeit in einem agilen Team zu bekommen, aber nicht wirklich teamübergreifend vergleichbar
• Funktionsbasierte Metriken wie Funktionspunkte oder Anwendungsfallpunkte sind vielleicht das Beste aus einem schlechten Haufen, aber sie sind bürokratisch zu erfassen und spiegeln nicht den Unterschied im technischen Aufwand wider, der zum Erstellen jeder Funktionseinheit erforderlich ist.
• Qualitätsmetriken wie Fehler in der Produktions- / App-Verfügbarkeit sind bekanntermaßen schwer gleich zu berechnen und zu vergleichen - dies hängt maßgeblich von der gewählten Plattform, der Größe der Benutzerbasis und verschiedenen Betriebs- / Bereitstellungsfaktoren ab.

Fazit: Der Versuch, die Auswirkungen von Softwareentwicklungsaufgaben zu quantifizieren, ist eine äußerst schwierige Aufgabe, und trotz vieler Jahre nach dem Thema hat noch niemand einen wirklich effektiven Ansatz gefunden. Infolgedessen bleibt die Bewertung von Softwareentwicklungsmethoden eher eine Kunst als eine Wissenschaft und wird dies wahrscheinlich auch in den kommenden Jahren bleiben.

Interessanterweise gibt es einen Ansatz, der meiner Meinung nach vielversprechend ist: die Anwendung von Lean-Prinzipien . Dies ist kein Allheilmittel und löst das Problem der Bewertung von Softwareentwicklungsmethoden nicht direkt, hat jedoch eine wichtige Erkenntnis: Ein Prozess mit einem bestimmten Abfallelement ist eindeutig weniger effizient als derselbe Prozess ohne dieses Abfallelement. alle anderen Dinge sind gleich . Wenn Sie sich also darauf konzentrieren, Verschwendung im Softwareentwicklungsprozess zu vermeiden, können Sie zumindest sicher sein, dass Sie sich in die richtige Richtung bewegen. Darüber hinaus ist Abfall häufig quantifizierbar, sodass Sie sich auch ein Bild davon machen sollten, wie viel effizienter Sie werden, zumindest in groben Prozentangaben.