Was ist ein gutes Beispiel für eine fehlgeschlagene Softwareentwicklungsidee oder -technik?

Speziell, was sind einige Beispiele dafür, wo Ideen der Massen einfach falsch waren. Warum haben sich die Leute überhaupt an die Ideen gehalten? Und warum wurden die Ideen verworfen? Oder vielleicht sind die Ideen noch lebendig und gut und wenn ja, warum?

Zum Beispiel könnte ich CORBA (und andere ähnliche Technologien) als etwas beschreiben, das versucht hat, das Problem der Kommunikation zwischen Softwarekomponenten zu lösen. Viele hielten es für notwendig, Verträge zwischen verschiedenen Komponenten zu definieren. Letztendlich löste HTTP + JSON das Problem für die Massen und andere verschiedene RPC-Mechanismen wie Thrift und Proto-Bufs sind aufgetaucht.

Grundsätzlich konkurrieren Ideen und Technologien wie in der Welt außerhalb von Computern um Aufmerksamkeit, Hebelwirkung usw. Einige gewinnen, andere verlieren; und einige scheinen für einige Zeit der Gewinner zu sein und verschwinden dann mit dem Aufkommen von The Next Big Thing in der Dunkelheit. Es kann oder kann nicht etwas damit zu tun haben, was eigentlich das bessere war. Erleben Sie VHS gegen Betamax oder den jüngeren Krieg zwischen den verschiedenen DVD-Formaten.

CORBA war riesig, umständlich und schwer zu bedienen, aber es war das Beste, was manche Leute zu dieser Zeit erfinden konnten (beachten Sie, dass es entwickelt wurde, bevor das World Wide Web - und HTTP, Java, XML, ... - allgemein bekannt wurden). Und es war auch ein klassisches Beispiel für das Design des Komitees , bei dem jede Idee, um alle zufrieden zu stellen, vollgestopft wurde, was sie letztendlich nutzlos aufgebläht machte (zumindest mit den heutigen Augen). Ganz zu schweigen von seinem Preis, der mit dem Aufkommen von FOSS bald unerschwinglich wurde.

Letztendlich löste HTTP + JSON das Problem für die Massen

Zumindest für jemanden, der nicht gesehen hat, dass ein paar ähnliche "Endlösungen" steigen und letztendlich fallen ... Es ist gut zu bedenken, dass es zu seiner Zeit eine ähnliche Stimmung über CORBA gab ;-)

Ich denke, es ist passend, aus dem Aufstieg und Fall von CORBA zu zitieren :

Die Geschichte von CORBA ist eine, die die Computerbranche schon oft gesehen hat, und es ist wahrscheinlich, dass die aktuellen Middleware-Bemühungen, insbesondere Webdienste, eine ähnliche Geschichte nachstellen werden. [...]

Insgesamt muss der Technologieeinführungsprozess der OMG als Hauptgrund für den Rückgang von CORBA angesehen werden. Der Prozess fördert das Design durch Komitees und politische Manöver bis zu einem Punkt, an dem es schwierig ist, technische Mittelmäßigkeit zu erreichen, geschweige denn technische Exzellenz. Darüber hinaus führt das Hinzufügen unzusammenhängender Merkmale zu einer allmählichen Erosion der architektonischen Vision. [...]

Ein demokratischer Prozess wie der der OMG ist für die Erstellung guter Software einzigartig ungeeignet. Trotz der bekannten Verfahrensprobleme zieht es die Industrie jedoch vor, sich bei der Herstellung von Technologie auf große Konsortien zu verlassen. Web-Services, die derzeitige Silberkugel der Middleware, verwenden einen ähnlichen Prozess wie die OMGs und leiden nach vielen Berichten auch unter Infighting, Fragmentierung, mangelnder architektonischer Kohärenz, Design by Committee und Feature Bloat. Es scheint unvermeidlich, dass Webdienste eine Geschichte erstellen, die der von CORBA sehr ähnlich ist.

Jetzt aus einem anderen Blickwinkel: Als ich Ihren Begriff "Ideen der Massen" las, dachte ich über ganz andere Dinge nach als CORBA oder andere Standards; Dies ist normalerweise die Idee einer Person oder einer kleinen Gruppe. Ich dachte über berüchtigte Praktiken / Standpunkte wie "Cowboy-Codierung", "Code und Gebet", "es funktioniert auf meiner Maschine" usw. nach. Dies sind meiner Meinung nach echte "Ideen der Massen", da dies fast jeder Anfänger ist Der Entwickler beginnt instinktiv, Code zu schreiben. Und sie sind falsch, da sie weder räumlich noch zeitlich skaliert werden können - auf diese Weise können keine großen, wartbaren und erweiterbaren Programme erstellt werden. Ich bin jedoch der Meinung, dass es leider immer noch eher die Norm als die Ausnahme ist, wenn Menschen versuchen, auf diese Weise in professionellen Geschäften auf der ganzen Welt zu arbeiten.

Das andere Extrem davon sind die Vorstellungen vieler Manager und Theoretiker über den "richtigen Ansatz" für die SW-Entwicklung, der sich in Big-M-Methoden wie CMM, RUP, Wasserfall usw. manifestiert. Die Idee, die dahinter steckt, ist, dass alles, was Sie brauchen, ist der richtige Prozess, und es wird automatisch beginnen, qualitativ hochwertige Software auf deterministische Weise zu produzieren, unabhängig davon, wer die Entwickler tatsächlich sind. Beachten Sie, dass dasselbe Spiel auch mit agilen Methoden gespielt werden kann - es ist nur eine Änderung der Beschriftung. Jeder Manager, der der Ansicht ist, dass die Auswahl (und Beibehaltung) der richtigen Mitglieder für sein Entwicklungsteam weniger wichtig ist als der Entwicklungsprozess, muss scheitern, je nachdem, welcher Prozess gerade stattfindet. Dieser Glaube an den Prozess scheint jedoch immer noch weit verbreitet zu sein - vielleicht wird er noch in Managementschulen gelehrt?

Ein häufiges Beispiel für Menschen, die falsch liegen, ist das Wasserfallmodell. Dies ist ein Diagramm des stereotypen Wasserfallmodells, das auch in Winston Royces Artikel "Managing the Development of Large Software Systems" erscheint .

Diesem Bild folgt dieser Text:

Ich glaube an dieses Konzept, aber die oben beschriebene Implementierung ist riskant und führt zum Scheitern ... Die Testphase, die am Ende des Entwicklungszyklus stattfindet, ist das erste Ereignis, für das Timing, Speicherung, Eingabe / Ausgabe, Übertragungen usw. sind Erfahrungen im Unterschied zu analysiert. Diese Phänomene sind nicht genau analysierbar. Sie sind beispielsweise nicht die Lösungen für die standardmäßigen partiellen Differentialgleichungen der mathematischen Physik. Wenn diese Phänomene jedoch die verschiedenen externen Einschränkungen nicht erfüllen, ist ausnahmslos eine umfassende Neugestaltung erforderlich. Ein einfacher oktaler Patch oder das Wiederherstellen eines isolierten Codes behebt diese Art von Schwierigkeiten nicht. Die erforderlichen Designänderungen sind wahrscheinlich so störend, dass die Softwareanforderungen, auf denen das Design basiert und die die Begründung für alles liefern, verletzt werden. Entweder müssen die Anforderungen geändert werden, oder es ist eine wesentliche Änderung des Designs erforderlich. Tatsächlich ist der Entwicklungsprozess zum Ursprung zurückgekehrt, und man kann mit einer 100-prozentigen Überschreitung des Zeitplans und / oder der Kosten rechnen.

Später in diesem Artikel stellt Royce alternative Prozessmodelle vor, bei denen zwischen der aktuellen Phase und der vorherigen Phase und einem Zyklus zwischen Anforderungsanalyse-Design und einem weiteren Zyklus zwischen Design-Code-Test iteriert wird. Er identifiziert auch eine Reihe von Dokumenten und in welchen Phasen sie abgeschlossen werden sollten, und befürwortet die Einbeziehung der Kunden und mehrere Wasserfälle in jeder Phase, einschließlich Analyse, Test und Verwendung aller beteiligten Artefakte. Tatsächlich könnte das, was Royce diskutiert, als ein früher Ansatz für agile Methoden angesehen werden - allerdings immer noch sehr planorientiert, aber eine Grundlage für die agile Bewegung.

Warum sich die Leute an den ersten Wasserfall klammerten, weiß ich nicht. Ich denke, sie gehen gerne Risiken ein und laden zum Scheitern ein.

Automatische Generierung von Code aus einer höheren Abstraktionsebene oder automatische Programmierung .

Dem Wikipedia-Artikel fehlen historische Informationen, aber dies war ein Traum von Managern, seit Programmierer teurer als Computer wurden.

Nach der Entwicklung höherer Sprachen wie Fortran und Cobol kam die Entwicklung von Sprachen für spezielle Bereiche wie das Verfassen von Berichten. Easytrieve und SAS waren einige Beispiele.

In den 1980er Jahren waren CASE-Tools der letzte Schrei. CASE steht für Computer Aided Software Engineering. Es wurde angenommen, dass die konsequente Anwendung technischer Prinzipien die Softwareentwicklung beschleunigen würde. Der Hauptgrund, warum sich diese Tools neben den Kosten nicht durchgesetzt haben, war der hohe Grad an Datenstandardisierung, der erforderlich ist, damit die Tools effektiv funktionieren.

Das Internet wurde in den 90er Jahren bekannt. Die Arten der Programmierung, die das Internet ermöglichte, explodierten. Programmierer mussten Illustrationen, Karten, Fotos und andere Bilder sowie einfache Animationen mit einer nie zuvor gesehenen Geschwindigkeit mit wenigen bekannten Methoden verarbeiten. Die Anzahl der Technologien zur Herstellung dieser Objekte hat sich vervielfacht. Träume von automatischer Programmierung verblassten.

Das Auslagern von Programmen an billigere Standorte ist eine der wenigen verbleibenden Methoden, um die Programmiererkosten zu senken. Die Probleme beim Outsourcing umfassen Kommunikationsprobleme und Spezifikationsprobleme.

Formale Methoden

Es war einmal vorgeschlagen worden, Software als richtig zu erweisen. (Die Idee ist, dass das Testen nicht zeigen kann, dass es keine Fehler gibt, aber Beweise könnten dies.) Leider hat das Entwickeln eines Beweises für ein Programm einige Hauptnachteile:

• Es ist schwieriger und zeitaufwändiger als das Schreiben des Programms.
• Es muss das gesamte Programm abdecken, dh Sie benötigen Proofs für jede Bibliothek, jedes Betriebssystem usw.
• Es beweist nicht das Fehlen von Fehlern, da diese Fehler versehentlich verursacht werden können.

Dieses Konzept war in den 70er Jahren sehr beliebt.

Verknüpfung: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods