Gab es in den letzten 20 Jahren nicht wirklich eine Sache, die zu enormen Softwareentwicklungsgewinnen geführt hat? [geschlossen]

In No Silver Bullet macht Fred Brooks eine Reihe von Vorhersagen über die Zukunft des Software-Engineerings, am besten zusammengefasst durch:

Weder in der Technologie noch in der Verwaltungstechnik gibt es eine einzige Entwicklung, die für sich genommen eine Verbesserung der Produktivität, der Zuverlässigkeit und der Einfachheit verspricht .

Sein Argument ist sehr überzeugend. Brooks schrieb 1986: hat er recht? Produzieren Entwickler im Jahr 2014 weniger als zehnmal schneller als ihre Kollegen im Jahr 1986? Wie hoch war der Produktivitätsgewinn tatsächlich?

Produzieren Entwickler im Jahr 2014 weniger als zehnmal schneller als ihre Kollegen im Jahr 1986?

Ich würde mir vorstellen, dass sich die Produktivität seitdem mindestens um eine Größenordnung verbessert hat. Aber nicht durch die Nutzung einer einzigen Entwicklung, weder in der Technologie noch in der Managementtechnik.

Produktivitätssteigerungen sind auf eine Kombination von Faktoren zurückzuführen. Hinweis: Dies ist keine vollständige Liste:

1. Bessere Compiler
2. Beträchlich leistungsstärkere Computer
3. Intellisense
4. Objektorientierung
5. Funktionsorientierung
6. Bessere Speicherverwaltungstechniken
7. Grenzüberprüfung
8. Statische Code-Analyse
9. Starkes Tippen
10. Unit Testing
11. Besseres Design der Programmiersprache
12. Codegenerierung
13. Quellcode-Kontrollsysteme
14. Wiederverwendung von Code

Und so weiter. Alle diese Techniken führen zusammen zu Produktivitätssteigerungen. Es gibt keine einzige Silberkugel, die jemals eine Beschleunigung um eine Größenordnung hervorgebracht hat.

Es ist zu beachten, dass einige dieser Techniken seit den sechziger Jahren existieren, aber erst in letzter Zeit eine weit verbreitete Anerkennung und Akzeptanz festgestellt haben.

Die Antwort von Robert Harvey ist gut, aber ich denke, er hat ausgelassen, was möglicherweise der Hauptgrund dafür ist, dass Programmierer produktiver sind als je zuvor: die weit verbreitete Verfügbarkeit von Softwarebibliotheken.

Als ich meine Karriere begann, gab es keine STL, .NET, QT usw. Sie hatten rohes C oder C ++, und das war es auch schon.

Was früher Tage oder Wochen gedauert hat oder funktioniert hat (XML-Analyse, TCP / IP-Verbindungen, HTTP-Kommunikation), kann jetzt mit ein paar Zeilen C # -Code erledigt werden. Hier haben wir die Produktivität der Entwickler insgesamt um Größenordnungen gesteigert.

Unser aktuelles Produkt verwendet ein Docking-Fenster-Framework, das wir von einem Anbieter gekauft haben. Auf diese Weise habe ich in wenigen Minuten eine voll funktionsfähige Docking-Fenster-Benutzeroberfläche. Ich schaudere, wenn ich mir überlege, was in den Tagen der Verwendung der Win32-API dazu nötig wäre.

Aus Gründen der Argumentation bin ich mit der Behauptung von Fred Brooks nicht einverstanden .

Es gibt eine technologische Verbesserung, die allein eine Produktivitätsverbesserung um eine Größenordnung ermöglichte: das Internet und genauer gesagt die zunehmende Verfügbarkeit von Internetverbindungen in jedem Haushalt in den letzten zwei Jahrzehnten.

Die Möglichkeit, auf nahezu jedes Problem, auf das Sie als Entwickler stoßen, sofort eine Antwort zu finden, führt zu einer enormen Produktivitätssteigerung. Sie wissen nicht, wie Sie das n-te Element in JQuery auswählen sollen? Die Google-Suche führt zu einer Antwort auf die genaue Frage zum Stapelüberlauf . Sie wissen nicht, wie man overflowCSS benutzt? Mozillas MDN ist da . Haben Sie vergessen, welches virtualSchlüsselwort in C # bedeutet? Google hilft wieder.

Als ich anfing zu programmieren, hatte ich kein Internet. Ich hatte Bücher und einige digital formatierte Dokumentationen lokal gespeichert, aber das Durchsuchen von Büchern und Dokumentationen war ein langsamer Prozess, und egal wie viele Bücher ich hatte, es gab viele Probleme, die dort nicht erwähnt wurden.

Noch wichtiger ist, dass fast jedes Problem, auf das Sie stoßen, bereits von jemand anderem angetroffen wurde. Das Internet hilft dabei, Personen zu finden, bei denen dieser Fehler aufgetreten ist und die ihn erfolgreich behoben haben. Dies ist keine Art von Information, die Sie in Büchern oder offiziellen Dokumentationen wie MSDN finden. Stattdessen werden solche Informationen normalerweise gefunden:

• Offensichtlich auf Stapelüberlauf. Ich habe zum Beispiel kein Buch gesehen, in dem dieses Problem erwähnt wurde .

• In Blogs. Ich fand in Blogs eine Menge Hilfe, wenn ich bestimmte Probleme hatte, sei es mit der WCF-Konfiguration oder einem nicht startenden Proxyserver oder einem kryptischen Fehler bei der Verwendung einer bestimmten API auf einem Computer mit einer anderen Kultur als en-US.

• In Fehlerberichten zu Open-Source-Software. Zum Beispiel war es kürzlich sehr hilfreich, als ich versucht habe, Ubuntus MAAS zu verwenden, und als ich PXE verwendet habe. Sie finden diese Art von Informationen auch nicht in Büchern.

Die Bedeutung der sofortigen Verfügbarkeit einer Antwort auf die meisten Probleme, die auftreten können, wird besonders deutlich, wenn wir berücksichtigen, dass die meiste Zeit, die ein Team für ein Projekt aufbringt, für dessen Wartung aufgewendet wird.

• Das Internet hilft in der Architektur- und Designphase nicht viel (Programmierer.SE könnte helfen, aber es wäre für einen Architekten viel wertvoller, Bücher über Architektur und Design zu lesen, Designmuster zu lernen usw.).

• Es wird bei Test- und Implementierungsschritten hilfreich, wenn tatsächliche Probleme auftreten.

• Aber die meisten Probleme, die während der Wartung auftreten, treten auf, wenn Hilfe von anderen über das Internet von entscheidender Bedeutung ist . Ein einfaches Beispiel: Ein WCF-Dienst funktioniert auf meinem Computer einwandfrei , scheitert jedoch ausnahmslos, wenn er in der Produktion eingesetzt wird, während er in den letzten zwei Wochen funktioniert hat. Dies ist mir passiert, und ich bin Blog-Autoren und der Stack Overflow-Community dankbar, dass sie mir geholfen haben, das Problem in wenigen Stunden und nicht in wenigen Wochen zu lösen.

Wäre es gerechtfertigt, die Produktivität um das Zehnfache zu steigern? Schwer zu sagen.

• Einerseits gibt es Fälle, in denen Sie sofort eine Antwort finden, während Sie möglicherweise tagelang alleine danach gesucht haben (oder gezwungen sind, einen großen Teil der Anwendung neu zu schreiben).

• Auf der anderen Seite verbesserte sich die Gesamtproduktivität aufgrund mehrerer Faktoren, wie z. B. besseres Projektmanagement (Agile, TDD usw.), besseres Teammanagement ( Radical Management von Stephen Denning), bessere Tools (Debugger, Profiler) , IDEs usw.), bessere Hardware (nein, ich werde nicht sehr produktiv sein, wenn ich gezwungen bin, in Assembler zu schreiben, da die CPU langsam und der Arbeitsspeicher sehr begrenzt ist) usw.

Ich würde sagen, das Internet ist ein ziemlich guter Kandidat. StackOverflow und Google sind die leistungsstärksten Tools eines modernen Entwicklers. Sofortiger Wissensaustausch auf globaler Basis! Heutzutage müssen Sie die Antworten nicht mehr kennen, Sie müssen nur noch wissen, wie Sie die Antworten kennen lernen - und das ist ein vollkommen angemessener Ersatz, mit dem Entwickler weniger Zeit mit Lesen und mehr Zeit mit Codieren verbringen und somit produktiv sein können. Das bedeutet, dass jeder Programmierer auf der Welt Zugriff auf alle Antworten hat und nur weiß, wie er die richtigen Fragen stellt.

Ich würde vorschlagen, dass die Trends, die uns in die andere Richtung ziehen (dh zu einer geringeren Produktivität), mindestens so stark sind wie die Trends, nach denen Sie gefragt haben. Die Erfahrung mit Client / Server-Entwicklungstools wie VB6 oder PowerBuilder kam dem Ideal der "Rapid Application Development" (RAD) ziemlich nahe. Sie müssen Ihre Formulare zeichnen, und es gab offensichtliche Haken für Ihren Prozedur- oder SQL-Code.

Zumindest anfangs zerstörte die Webentwicklung viele Techniken und Infrastrukturen, die diese Dinge ermöglichten, und viele Client / Server-Entwickler hörten einfach auf, Entwickler zu sein, oder hielten sich beispielsweise verzweifelt an VB6.

Der Übergang zu einer stark kundenorientierten Webentwicklung war eine weitere Erfahrung. Microsoft kehrte mit WebForms zum RAD-Ideal zurück und geriet dann schnell in Ungnade. Stattdessen wurde von den Entwicklern erwartet, dass sie die Infrastruktur (z. B. XMLHttpRequest, das nur selten für XML verwendet wird) missbrauchen und auf einer niedrigen Abstraktionsebene herumlungern, um ihre Websites interaktiver zu gestalten

Es gibt gute Gründe für all diese Übergänge, und es ist weder gerechtfertigt, einen Prozess, bei dem eine native EXE-Datei (die auf dem einzelnen Client installiert und verwaltet werden muss) erstellt wurde, mit der Webentwicklung zu vergleichen, noch ist es völlig gerecht, einen Prozess zu vergleichen, der stark von der Webentwicklung abhängt auf Postbacks mit einem, der eine nahtlosere Erfahrung liefert. Aber ich werde sagen, dass die Praktiken, die derzeit in Mode sind, zu einigen überraschend niedrigen Denkprozessen bei Menschen führen, die Client / Server, RAD und dergleichen verpasst haben. Client / Server-Schaltflächen haben einfach funktioniert, und man musste sich mit Sicherheit keine Gedanken über die zugrunde liegenden Datenkanäle machen, über die Daten an die Ereignishandler gesendet wurden, die dies ermöglichten.

Umgekehrt neigen zeitgenössische Entwickler dazu, zu glauben, dass diejenigen von uns, die Client / Server-Entwicklung (oder sogar postbackbasierte Web-Entwicklung) betrieben haben, dazu tendieren, auf Verknüpfungen zurückzugreifen (und dies in einer schlechten Weise bedeuten). Das ist verständlich, aber ich denke immer noch, dass die Art und Weise, wie die gegenwärtige Entwicklung durchgeführt wird, überraschend niedrig ist, und die Tage der Suche nach einer "Silberkugel" scheinen der Ära gewichen zu sein, in der wir uns über diejenigen lustig gemacht haben, die die Weisheit des Bergbaus und der Erziehung in Frage stellen Wir haben unser eigenes Blei geschmolzen.

Die Technologie hat sich sehr weiterentwickelt und jetzt haben wir alles, was Robert Harvey in seiner Antwort aufführt, aber:

• Das Problem scheint, Anforderungen zu ändern . Der Kunde weiß, dass beim Ändern der Anforderungen eines Softwareprojekts keine Materialverschwendung entsteht. Diese Art von Anforderungsänderungen treten so gut wie nie auf, wenn ein Projekt der physischen Welt wie ein Gebäude zur Hälfte abgeschlossen ist.

• Ein weiterer wichtiger Aspekt ist, dass die Programmierung nach wie vor sehr handwerklich ist . RAD-generierter Code wird in den seltensten Fällen in die Produktion aufgenommen, ohne zuvor von Hand geändert zu werden.

• Code ist weiterhin sehr komplex , und diese Komplexität scheint mit neuen Technologien nicht abzunehmen.

• Die Zahl der nicht eingehaltenen Fristen oder Budgetüberschreitungen ist weiterhin höher als in anderen Disziplinen, und häufig entstehen technische Schulden, um diese einzuhalten , was versteckte Kosten verursacht.

• Etwas , das hat, ohne Zweifel, passiert ist , dass Kompartimentierung aufgetreten ist. Die schiere Menge an Technologien, die man kennen muss, ist, dass Programmierer eine kleine Anzahl von Technologien spezialisieren mussten, um wirklich gut darin zu werden, und verschiedene Arten von Experten für die Durchführung eines großen Projekts benötigen.

• Über die Komplexität von Software spricht, dass es zwar buchstäblich Hunderte von Autoherstellern auf der Welt gibt, die Liste der Unternehmen, die ein Betriebssystem (Desktop, Mobile, Embedded oder auf andere Weise) erstellen und warten können, jedoch mit den Fingern gezählt werden kann von deinen Händen.

• All das hat zu einer Situation geführt, in der nicht genügend Menschen studieren, um Programmierer zu werden , und die Regierungen haben Kampagnen ins Leben gerufen, um mehr Studenten zu motivieren, diesen Karriereweg einzuschlagen.

• Ein Vorgeschmack auf die Reife der Softwareindustrie ist, dass in Softwarelizenzen weiterhin angegeben wird, dass "<companyX> keine Zusicherungen über die Eignung dieser Software für einen bestimmten Zweck macht. Sie wird" wie sie ist "ohne ausdrückliche oder stillschweigende Garantie" bereitgestellt. Stellen Sie sich einen Hardware-Hersteller vor, der angibt, dass sein Produkt nicht für einen bestimmten Zweck geeignet ist. Das ist jetzt der Stand der Technik.

Während man sich mit bestimmten Metriken auseinandersetzen könnte (dh, die Dinge haben sich um den Faktor 9,98 verbessert?), Muss ich (sozusagen als Oldtimer) der allgemeinen Meinung von Brooks zustimmen.

Erstens wurde seit 1970 kaum eine wirklich neue Technologie erfunden. Ja, integrierte Schaltkreise wurden länger, niedriger, breiter und Glasfasern haben die Kommunikationsgeschwindigkeit verbessert, aber für jeden Schritt nach vorne gibt es einen Zurück.

Die Compilertechnologie hat eine etwa 10-fache Verbesserung der "Produktivität" des Programmierers im Vergleich zu 1970 ermöglicht, als eine Zahl durch die tatsächliche Codierungszeit dividiert wurde. Die Verbreitung neuer oder "überarbeiteter" Programmiersprachen und -umgebungen bedeutet jedoch, dass der durchschnittliche Programmierer immer mehr Geld ausgibt Zeit im "Aufhol" -Modus und weniger in produktiven Aktivitäten. Apple, Google und Microsoft haben alle neue und im Wesentlichen inkompatible "Upgrades" für ihre Umgebungen herausgegeben, und zwar mit einer Geschwindigkeit, die knapp unter der liegt, die bei ihren Servern und Programmierkunden Aufruhr hervorrufen würde. Ebenso wird HTML / CSS / Javascript / whatever immer komplexer.

Früher hätte die Geschwindigkeit, mit der Dokumentation erstellt und verbreitet werden konnte, all diese "Innovation" begrenzt und gebremst, aber dank des Internets ist eine strenge Dokumentation nicht mehr wirklich erforderlich - spucken Sie einfach die Funktionen aus und verlassen Sie sich auf Blogger Finde die Details heraus und stelle sie zur Verfügung.

Hinzugefügt: Ich habe seit gestern darüber nachgedacht und insbesondere über das Projekt nachgedacht, an dem ich von 1978 bis 2008 gearbeitet habe. Dieses Projekt (IBM System / 38 und seine Nachfolger) war von Anfang an einzigartig gemacht, um die Komplexität davon zu kontrollieren (einer ist die Aufteilung der Software in zwei ungefähr gleiche Teile, mit einer "Maschinen" -Schnittstelle zwischen ihnen). In dem speziellen Bereich, in dem ich gearbeitet habe, widmeten sich einige meiner Kollegen ebenfalls der Kontrolle der Komplexität (obwohl wir diesen Begriff zu dieser Zeit nicht oft verwendeten). Das Ergebnis war ein (zunächst) recht robustes Produkt, das von Anfang an bei den Kunden sehr gut ankam. Und es war eine Freude, daran zu arbeiten - wie in einem gut ausgebildeten Orchester.

Natürlich hat sich im Laufe der Jahre Komplexität eingeschlichen, in der Regel auf Geheiß von Marktplanern und Managern, die es nicht verstanden haben, Komplexität zu kontrollieren (was sich irgendwie von der einfachen Aufrechterhaltung der Einfachheit unterscheidet). Ich habe nicht das Gefühl, dass dies unvermeidlich war, aber es war in diesem Fall unmöglich zu verhindern, dass ein Manager (wie ursprünglich Glenn Henry) die Kräfte der Verwirrung zurückdrückte.

Vieles, was wir in den letzten über 30 Jahren in der Praxis des Software-Engineerings gelernt haben, hat die Form "Technologie X kann die anfängliche Entwicklung neuer Software beschleunigen, aber wenn Sie nicht so viel oder länger darüber nachdenken, wie und Wenn Sie es so verwenden, wie Sie es gespeichert haben, wird es Ihre Anwendung auf lange Sicht in einen Sumpf technischer Schulden verwandeln, was Sie um ein Vielfaches mehr Zeit und Mühe bei der Wartung kostet. "

Zu den Technologien, die unter diesen Rasierer fallen, gehören: handcodierte Assemblersprache, Compiler, Interpreter, Prozedurbibliotheken, Imperative Programmierung, funktionale Programmierung, objektorientierte Programmierung, manuelle Speicherzuweisung, Speicherbereinigung, statische Typen, dynamische Typen, lexikalischer Bereich, dynamischer Bereich , "sichere" Zeiger, "unsichere" Zeiger, das Fehlen von Zeigern als Sprachkonzept, Binärdateiformate, Dateiformate mit strukturiertem Markup, Makros, Vorlagen, Vermeiden von Makros und Vorlagen, gemeinsamer Speicher, Nachrichtenübergabe, Threads, Coroutinen, Asynchrone Ereignisschleifen, zentralisierte Remotedienste, verteilte Dienste, lokal installierte Software, Arrays, verknüpfte Listen, Hash-Tabellen und Bäume.

Die Tatsache, dass viele der Elemente in der obigen Liste in Gruppen zusammengefasst sind, die zusammen den bekannten Lösungsraum ausschöpfen, ist sehr beabsichtigt und sollte Ihnen an und für sich etwas sagen. Man könnte argumentieren , dass die nur eindeutig, across-the-board Verbesserungen in der Praxis haben wir, seit sie zum ersten Mal auf der Z3 geschaltet ist block strukturierte Programmierung (im Gegensatz zu Spaghetti - Code im Gegensatz) und Speicherschutz (Junge, ich jemals nicht verpassen die Tage, an denen ein Tippfehler meinen gesamten Computer ausschalten konnte).