Warum kann die IT-Branche große, fehlerfreie Projekte nicht so schnell wie in anderen Branchen abwickeln?

Nachdem ich mir die MegaStructures-Reihe von National Geographic angesehen hatte , war ich überrascht, wie schnell große Projekte abgeschlossen werden. Sobald die Vorarbeiten (Design, Spezifikationen usw.) auf dem Papier erledigt sind, dauert die Realisierung selbst von großen Projekten nur einige Jahre oder manchmal einige Monate .

Beispielsweise wurde der Airbus A380 "offiziell am 19. Dezember 2000 gestartet" und "Anfang März 2005" bereits getestet. Das gleiche gilt für große Öltanker, Wolkenkratzer usw.

Wenn ich das mit den Verzögerungen in der Softwareindustrie vergleiche, frage ich mich, warum die meisten IT-Projekte so langsam sind, oder genauer, warum sie nicht so schnell und fehlerfrei sein können, wenn genügend Leute da sind?

Projekte wie der Airbus A380 bieten beides:

• Große unvorhergesehene Risiken: Dies ist zwar nicht das erste gebaute Flugzeug, es stößt jedoch an die Grenzen der Technologie, und Dinge, die für kleinere Flugzeuge gut funktionieren, funktionieren möglicherweise aufgrund physikalischer Einschränkungen nicht für das größere Flugzeug. Ebenso werden neue Technologien eingesetzt, die noch nicht zum Einsatz kamen, weil sie zum Beispiel 1969, als die Boeing 747 fertig war, nicht zur Verfügung standen.

• Risiken im Zusammenhang mit Personal und Management im Allgemeinen: Personen, die mitten im Projekt gekündigt haben, Unfähigkeit, eine Person zu erreichen, weil sie im Urlaub ist, normale menschliche Fehler usw.

Mit diesen Risiken erreichen die Menschen in sehr kurzer Zeit Projekte wie diese großen Verkehrsflugzeuge , und trotz der Verzögerungen bei der Auslieferung sind diese Projekte immer noch äußerst erfolgreich und von hoher Qualität.

Bei der Softwareentwicklung sind die Projekte kaum so groß und kompliziert wie ein Verkehrsflugzeug (sowohl technisch als auch in Bezug auf das Management) und haben etwas weniger unvorhergesehene Risiken aus der realen Welt.

Dennoch sind die meisten IT-Projekte langsam und spät , und das Hinzufügen von mehr Entwicklern zum Projekt ist keine Lösung (von einem Team von zehn Entwicklern auf zweitausend wird es manchmal möglich sein, das Projekt schneller zu liefern, manchmal nicht und manchmal schadet es nur den projizieren und das Risiko erhöhen, es überhaupt nicht zu beenden).

Diejenigen, die noch geliefert werden, enthalten oft viele Fehler, die aufeinanderfolgende Service Packs und regelmäßige Updates erfordern (stellen Sie sich vor, Sie installieren zweimal pro Woche Updates auf jedem Airbus A380, um die Fehler im Originalprodukt zu beheben und einen Absturz des Flugzeugs zu verhindern).

Wie lassen sich solche Unterschiede erklären? Liegt es ausschließlich an der Tatsache, dass die Softwareentwicklungsbranche zu jung ist, um Tausende von Menschen in einem einzigen Projekt verwalten zu können, um in großem Maßstab nahezu fehlerfreie Produkte sehr schnell zu liefern?

Ed Yourdons Todesmarsch berührt eine Reihe dieser Fragen vom Typ Meta.

Im Allgemeinen mangelt es der Softwareindustrie an vielem, was großen Projekten im Wege steht.

• Standardisierung und Workitem-Aufschlüsselung.

  • Dies ist sicherlich besser geworden, aber die Designkonstruktionen sind immer noch nicht da, um ein großes System auszubrechen. In mancher Hinsicht kann sich die Software nicht einmal darauf einigen, was für ein bestimmtes Projekt benötigt wird , geschweige denn, dass sie die Dinge in Komponenten zerlegen kann.
  • Luft- und Raumfahrt, Hochbau, Auto usw. haben alle sehr komponentengetriebene Architekturen mit relativ engen Schnittstellen, um eine vollständig parallele Entwicklung zu ermöglichen. Die Software lässt in den entsprechenden Bereichen immer noch zu viel durch.

• Eine große Anzahl erfolgreicher, ähnlicher Projekte. Der A380 war nicht das erste große Flugzeug, das Airbus gebaut hat. Es gibt viele große Softwareanwendungen, aber viele von ihnen haben auf die eine oder andere Weise dramatisch gelitten und würden nicht annähernd als "erfolgreich" bezeichnet.

• Eine große Anzahl von Designern und Bauherren, die an einer Reihe ähnlicher und erfolgreicher Projekte gearbeitet haben. Bezogen auf das erfolgreiche Projektproblem, bei dem kein menschliches Talent vorhanden war, macht dies die Dinge aus Sicht der Wiederholbarkeit sehr schwierig.

• "Niemals" zweimal dasselbe bauen. In vielerlei Hinsicht ist ein Flugzeug wie jedes andere Flugzeug. Es hat Flügel, Motoren, Sitze usw. Große Softwareprojekte wiederholen sich selten. Jeder Betriebssystemkern ist signifikant unterschiedlich. Betrachten Sie die Unterschiede in den Dateisystemen. Und wie viele wirklich einzigartige Betriebssysteme gibt es überhaupt? Die Großen werden irgendwann zu Klonen eines Basisobjekts. AIX , Solaris , HP-UX , ... kündigen AT & T System V an . Windows hat bei jeder Iteration unglaublich viel Widerstand geleistet. Linux-Varianten gehen im Allgemeinen alle auf denselben Kern zurück, den Linus gestartet hat. Ich spreche es an, weil sich die Varianten tendenziell schneller verbreiten als die wirklich einzigartigen, proprietären Betriebssysteme.

• Wirklich schlechte Projektschätzung. Da der Wiederholungsfaktor so niedrig ist, ist es schwierig zu prognostizieren, wie groß er am Ende sein wird und wie lange es dauern wird, bis etwas aufgebaut ist. Da Projektmanager und Management den Code nicht in die Hand nehmen und nicht sehen können, was gerade getan wird, werden unrealistische Erwartungen in Bezug auf Zeitpläne generiert.

• QA / QC wird nicht so stark betont, wie es für größere Projekte sein könnte oder sollte. Dies liegt daran, dass die Schnittstellen zwischen den Komponenten lockerer sind und keine strengen Spezifikationen für die Funktionsweise der Komponenten vorliegen. Diese Lockerheit kann unbeabsichtigte Konsequenzen haben und dazu führen, dass sich Bugs einschleichen.

• Konsequent messbare Qualifikationen. Im Allgemeinen sprechen die Leute von der Anzahl der Jahre, in denen sie in X-Sprache oder in der Programmierung gearbeitet haben. Time in wird als Ersatz für das Kaliber oder die Qualität des Könnens verwendet. Wie schon oft erwähnt, ist es schwierig, gute Programmierer zu interviewen und zu finden. Ein Teil des Problems ist, dass die Definition von "gut" sehr subjektiv bleibt.

Ich will nicht nur negativ sein, und ich denke, die Softwareindustrie hat bedeutende Fortschritte gemacht, von wo wir waren. Foren wie dieses und andere haben wirklich dazu beigetragen, die Konversation und Diskussion über Designprinzipien zu fördern. Es gibt Organisationen, die daran arbeiten, das Basiswissen für Softwareentwickler zu standardisieren. Es gibt sicherlich Raum für Verbesserungen, aber ich denke, dass die Branche in relativ kurzer Zeit einen langen Weg zurückgelegt hat.

Die Antwort ist überraschend einfach: diese ‚anderen Industrien‘ haben eine hohe Ausfallrate haben. Wir vergleichen nur die falschen Dinge. Das Schreiben von Software wird häufig als "Build" bezeichnet. Daher vergleichen wir sie mit den Fertigungs- oder Konstruktionsphasen in anderen Branchen. Aber wenn man es betrachtet, ist es überhaupt keine Konstruktion: es ist Design . Software-Designs werden in Code geschrieben, und die Erstellung erfolgt durch Computer, entweder durch Kompilieren oder direktes Interpretieren der Software.

Viele Designs in anderen Branchen dauern entweder viel länger als ursprünglich angenommen, kosten viel mehr oder werden einfach nie fertiggestellt. Klingt bekannt?

Was machen wir also, wenn wir Software planen? Nun, wir entwerfen immer noch, aber zu einem früheren Zeitpunkt.

In der Software gibt es keine bemerkenswerte Fertigungslinie. Das Erstellen der endgültigen Komponente ist (vergleichsweise) billig, und die Replikation dieses Endprodukts ist sowohl perfekt als auch effektiv kostenlos - Sie kopieren die Build-Artefakte.

Um einige Zahlen herauszustellen:

1. Änderung der Anforderungen nach Beginn der Implementierung ; Als zum Beispiel der erste Airbus A380 in der Fabrik gebaut wurde, kann ich nicht glauben, dass, wenn jemand 200 weitere Sitze wünschte, diese dort platziert würden. In einem großen Softwareprojekt können jedoch auch nach Beginn der Entwicklung 5 weitere Benutzertypen hinzugefügt werden.
2. Komplexität - Große Softwareprojekte sind äußerst komplex. wahrscheinlich die komplexesten Projekte menschlicher Art, die entworfen und entwickelt wurden;
3. In der Architektur- und Entwurfsphase werden nicht genügend Ressourcen aufgewendet .
4. Feldunreife - Software-Engineering ist im Vergleich zu anderen Ingenieurschwestern eine relativ junge Disziplin. Dies hat zwei Implikationen: a) Nicht so viele Heuristiken und bewährte Praktiken; b) Nicht so viele sehr erfahrene Spezialisten;
5. Mangel an mathematischen Beweisen - In den meisten Fällen werden mathematische formale Methoden nicht verwendet, um zu beweisen, dass eine Software wie erforderlich funktioniert. Stattdessen wird Testen verwendet. Dies gilt auch für andere Bereiche des Ingenieurwesens, die sich stärker auf die Mathematik stützen. der Grund dafür ist wie Komplexität;
6. Eile - viele Manager haben unerreichbare Fristen; Die Qualität des Codes wird aufgrund der Frist an zweiter Stelle gesetzt.

Strikte Beantwortung der Frage - Ich bin der Meinung, dass andere sehr hohe Erwartungen (insbesondere in Bezug auf die Lieferzeit) an Programmierer haben und nicht genau verstehen, wie schwierig es ist, große Software zu programmieren.

Die Prämisse der Frage ist etwas fehlerhaft. Sowohl der A380 als auch die Boeing 787 wurden Jahre zu spät ausgeliefert.

Im Fall des A380 wurde ein Großteil der Verzögerung durch die französischen und deutschen Airbus-Einheiten verursacht, die unterschiedliche und leicht inkompatible Versionen der CATIA- Konstruktionssoftware verwendeten. Dies äußerte sich in unvereinbarer Weise in Kabelbäumen, die nicht ganz in das Flugzeug passten.

An CATIA, der am weitesten verbreiteten Flugzeugkonstruktionssoftware, war nichts auszusetzen, aber irgendwo ließ jemand die Softwarekonfigurationskugel fallen.

Die Boeing 787 litt auch unter Verzögerungen im Zusammenhang mit der Software, aber die meisten ihrer Probleme betrafen eher traditionelle Probleme mit neuen Flugzeugen wie die Gewichtskontrolle und die Lieferung von minderwertigen Teilen durch Zulieferer.

Sowohl der A380 als auch der B787 mussten ihre Tragflächendesigns ändern, nachdem die ersten Flugzeuge strukturelle Probleme hatten.

Große komplexe Projekte sind für Menschen in allen Bereichen schwierig.

Wolkenkratzer hier. Ich bin mir nicht sicher, ob ich deine Frage beantworten kann, aber ich kann sicher ein bisschen Licht in verschiedene Themen des Threads bringen. Gebäude entstehen tatsächlich sehr schnell. Eine Hauptbeschränkung ist das Gebietsschema (Vorschriften). Im Allgemeinen dauert es jedoch 3 bis 10 Jahre, bis ein hohes Gebäude fertig ist.

Ich denke, ein neues Gebäude mit einem neuen Softwareprojekt zu vergleichen, ist nicht sehr genau. Ein neues Gebäude kommt einer neuen Version eines Kernels oder Betriebssystems näher. In dieser Hinsicht ist die Softwareentwicklung viel schneller. Wir bauen niemals von Null auf, da dies eine Aufgabe mit hohem Risiko ist, für die sich der Kunde niemals anmelden würde. Das meiste Design und die Entwicklung in Gebäuden sind Ableitungen von bewährten und abgeschlossenen Projekten.

Aus eigener Erfahrung wird nur jedes zehnte Projekt jemals realisiert. Der Prozess ist eher entwicklungsgetrieben als designgetrieben. In dem Moment, in dem der Stahlpreis steigt, ist das gesamte Projekt aus dem Fenster oder geplant, da Design die billige Komponente des Prozesses ist.

Das Design benötigt einen Monat für die Konzeption bis zum Schaltplan, zwei bis sechs Monate für die Designentwicklung, weitere sechs Monate für Details und Konstruktionsunterlagen durch ein Team von Architekten, Planungsberatern, Statikern, Windingenieuren, Servicetechnikern, Mengen- und Kostenberatern, Vermessungsingenieuren. Techniker für Barrierefreiheit und die Liste geht weiter ...

Das Argument von virtuell gegen physisch ist nicht sehr genau. Wir arbeiten auch hauptsächlich mit virtuellen Werkzeugen und sind zeit- und maßstabsfern von unserem Endprodukt. In den meisten Fällen können wir nicht einmal Aspekte von Gebäuden im Mockup-Maßstab testen und versuchen mithilfe von Simulationen vorherzusagen, was möglicherweise passieren wird.

In Bezug auf die Komplexität gibt es Unterschiede, aber insgesamt ist es vielleicht ungefähr gleich. Wir haben nicht nur miteinander verbundene Einheiten und mehrere Ebenen von abgestuften Abstraktionen und Schnittstellen, sondern auch Menschen, die sich auf kleine Teile des Prozesses spezialisiert haben, die die Kommunikation sehr erschweren.

Was das Argument Design versus Entwicklung angeht, denke ich, dass beide Prozesse auf Design basieren. Es klingt akademisch gut, diese getrennt zu halten, aber es ist nicht möglich zu entwerfen, wenn Sie nicht wissen, wie die Dinge funktionieren. Sie erhöhen nur das Ausfallrisiko.

Insgesamt ist meine (möglicherweise falsche) Einschätzung gemäß der Frage von OP, dass das Programmieren eher eine Kunst als ein Engineering ist. Warum sollten die Menschen Freude daran haben und es sogar kostenlos tun, Ausdruck und Eleganz darin finden? Auch die Informatik ist eher eine Wissenschaft als ein Ingenieurwesen. Warum sollten Sie versuchen, Algorithmen zu beweisen, anstatt nur vorhandene Teile zusammenzufügen und dafür zu sorgen, dass die Dinge einfach funktionieren? Ich bin mir nicht sicher, ob dies Sinn macht. Ich bin kein Software-Typ.

Ein Aspekt, der mich beim Design und der Entwicklung von Software beeindruckt, ist das Medium. Computer machen menschliches Arbeiten sehr unnatürlich. Alles ist so explizit und es gibt nur wenige Toleranzen. Es ist schwierig, sich mental darum zu kümmern, und manche schaffen es, die Komplexität in sich hineinzugeben. Wenn nichts anderes damit zu tun hat?

Wie lange hat das Design dann gedauert? Jahr? Zwei? 10 Jahre? Das Design ist der komplexeste Teil eines Gebäudes, die Konstruktion selbst ist einfach.

Basierend auf diesem Artikel wird langsam verstanden, dass Softwareentwicklung hauptsächlich ein Designprozess ist, bei dem das Designdokument der Quellcode selbst ist. Und der Designprozess unterscheidet sich grundlegend vom Produktionsprozess. Es erfordert erfahrene Mitarbeiter und ist nicht planbar, da selbst kleine Anforderungsänderungen zu großen Änderungen in der Gesamtarchitektur des Projekts führen können. Dieses Verständnis ist die Grundlage für agile Methoden , die darauf abzielen, die Codequalität als endgültiges Designdokument zu verbessern und das Testen und Debuggen als Teil des Designprozesses zu betrachten, genau wie sie Flugzeugmodelle in Windkanälen testen.

Die Konstruktion selbst wird automatisch von Compilern bearbeitet. Und dank dessen sind wir in der Lage, ganze Produkte in wenigen Minuten zu bauen.

Der Grund, warum Softwareprojekte mit enormen Verzögerungen und überhöhten Kosten abgeschlossen werden, ist, dass Manager immer noch glauben, einen solchen Entwurfsprozess abschätzen, vorhersagen und planen zu können. Dies schlägt öfter fehl, als es tatsächlich gültig ist. Sie sind immer noch der Meinung, dass sie durch die Einbindung der Menschen in einen starren Bauprozess die Qualität irgendwie steigern können, obwohl das Endergebnis meistens mit höheren Kosten und Terminüberschreitungen zu kämpfen hat.

Stellen Sie sich vor, mitten im Design des Airbus A380 meldet sich jemand bei einem Meeting und sagt: "Heh, könnte man ihn als Dreidecker bauen?" Andere sagten mit: "Ja, ja. Ein Dreidecker. Mehr Flügel sind besser." Die nächsten Jahre werden damit verbracht, das A380-Design in ein Triplane zu verwandeln. Bei einem anderen Treffen sagt jemand: "Ein Dreidecker? Das ist alt. Wir wollen einen Doppeldecker. Entfernen Sie einfach einen der Flügel."

Oder stellen Sie sich vor, während eines Brückenbauprojekts sagt jemand: "Heh, wir haben gerade einen Vertrag mit einer Reederei abgeschlossen. Sie müssen die Brücke noch 40 Fuß höher legen, weil ihre Schiffe viel höher sind. Reparieren Sie es. Danke . "

Dies sind nur einige der Gründe, warum große und kleine Softwareprojekte mit einer alarmierenden Rate scheitern.

Als jemand mit einem Maschinenbauhintergrund, der in der IT arbeitet, habe ich mich oft über die Gründe für die niedrige Erfolgsquote in der IT gewundert.

Wie andere in diesem Thread auch, habe ich die Fehler häufig auf die Unreife der IT, das Fehlen detaillierter Standards (ja, ich meine es ernst, haben Sie jemals das Standardblatt einer einfachen Schraube überprüft?) Und das Fehlen standardisierter Standards zurückgeführt Komponenten und Module.

Andere Branchen wie der Hochbau oder der Schiffbau haben ebenfalls viel mehr "Trampelpfade": Wissen und Erfahrung über einen bestimmten Lösungsprototyp, der - in kundenspezifischer Form - immer wieder verwendet wird. Überhaupt gewundert, warum Gebäude, Schiffe oder Flugzeuge unterschiedlicher Größe und Zweckbestimmung irgendwie so ähnlich aussehen? (Es gibt natürlich Ausnahmen von der Regel ...)

Das liegt daran, dass diese Prototypen gut erforscht, verstanden, allgemein verwendet und nachweislich erfolgreich sind. Nicht, weil es nicht anders geht. In der IT-Standardisierung ist dies selten der Fall: (große) Projekte erfinden häufig Komponenten neu, forschen und liefern zur gleichen Zeit und mit denselben Mitarbeitern!

Diese führen zwangsläufig zu einmaligen Produkten, die teuer in der Entwicklung und im Service sind, fehleranfällig sind und unter unsicheren Bedingungen auf unvorhersehbare Weise versagen. Und aus diesem Grund sind diese Produkte natürlich viel schneller veraltet, werden abgeschrieben und zu ebenso hohen Kosten durch nur geringfügig bessere ersetzt. Was die IT braucht, ist das Äquivalent der industriellen Revolution, die Handwerker des Mittelalters zu effizienten Fabriken machte.

Dennoch gibt es Faktoren, die die IT wirklich einzigartig machen. Im Gegensatz zu den anderen genannten Branchen ist die IT wirklich allgegenwärtig: Sie wird in jedem Aspekt unseres modernen Lebens eingesetzt. Es ist also ein kleines Wunder, dass die IT so viele Fortschritte erzielt hat und in der Lage ist, die Ergebnisse zu liefern, die sie erzielt.

Ich fürchte, dass ich Ihrer Aussage nicht zustimme.

Airbus und Boeing sind zwei Beispiele für Unternehmen, die Flugzeuge bauen. Wie viele Firmen, die Flugzeuge bauen, gibt es? Sehr wenige, wenn man es mit der Anzahl der Unternehmen vergleicht, die Software entwickeln.

Das Schrauben eines Flugzeugprojekts ist ebenso einfach wie das Schrauben eines Softwareprojekts. Wenn nur die Eintrittsbarriere in der Flugzeugbauindustrie so niedrig wäre wie in der Softwareindustrie, werden Sie sicherlich viele gescheiterte Flugzeugprojekte sehen.

Sieh dir Autos an. Es gibt hochwertige Hersteller, die sehr langlebige und hochmoderne Automobile bauen (denken Sie an Land Rover, Mercedes), und es gibt solche, die Autos bauen, die kein Jahr halten, ohne dass sie repariert werden müssen (denken Sie an Kia oder Cherry). Dies ist ein perfektes Beispiel für eine Branche mit etwas geringerer Markteintrittsbarriere, in der Sie anfangen, schwächere Spieler zu haben.

Software ist nicht anders. Sie haben viele fehlerhafte Produkte. Windows, Office, Linux, Chrome oder die Google-Suche sind sehr hochwertige Projekte, die pünktlich geliefert wurden und ein ähnliches Qualitätsniveau wie ein Flugzeug hatten.

Der andere Punkt, den viele Menschen vermissen, ist, wie viel Wartung in ein Auto, einen Tanker oder ein Flugzeug investiert wird, das wir als eine Tatsache des Lebens betrachten. Jedes Flugzeug muss vor jedem Start einer technischen Kontrolle unterzogen werden. Sie müssen Ihr Auto alle paar Kilometer überprüfen und dabei regelmäßig Dinge wie Ölwechsel und Reifenwechsel erledigen.

Software braucht das auch. Wenn nur Menschen so viel Zeit für Diagnose, Vorbeugung oder Prüfung des Zustands und der Qualität von Software aufwenden würden wie für mechanische / physikalische Produkte, würde ich viel weniger Aussagen wie diese erwarten. Lesen Sie die Protokolle Ihrer Anwendung jedes Mal, bevor Sie sie starten? Naja .. wenn es ein Flugzeug wäre müsstest du ;-)

Digitale Bausteine ​​können 1 oder 0 sein. Es gibt kein Dazwischen.

Ein mechanisches Design hat eine gewisse Toleranz. Ich kann einen weniger als perfekten Niet in eine Brücke stecken und es wird höchstwahrscheinlich nicht herunterfallen, aber im Code kann sogar nur eine einzige Instanz des Einsetzens einer 0, wo eine 1 sein sollte, das gesamte Programm scheitern.

Aufgrund des logischen und interaktiven Charakters des Computing können selbst sehr kleine Änderungen zu drastischen Ausfällen führen.

Ich habe mich oft das Gleiche gefragt. Es fühlt sich auf jeden Fall (gelegentlich) so an, als wären wir ein Haufen Amateure, die keine Ahnung haben, was wir tun. Ich mag keine Erklärungen, die den Managern oder anderen externen Faktoren die Schuld geben - wir, die Entwickler, sollten für das verantwortlich sein, was wir schaffen.

Ich denke, wir sind in einem Geschäft, in dem Fehler billig sind . Patching-Software ist billig, verglichen mit dem Wiederaufbau eines Wolkenkratzers oder dem Abrufen jedes verkauften Mobiltelefons.

Dies hat eine Kultur geschaffen, in der Käfer ein Teil des Alltags sind . Sie werden mit einem Achselzucken aufgenommen. Während einige Fehler wahrscheinlich unvermeidlich sind, sollten sie unsere tägliche Arbeit beherrschen ? Ich verstehe Manager, die nicht der Meinung sind, dass die Qualitätssicherung die Mühe wert ist, genau weil sie sowieso Fehler erwarten. Ich verstehe keine Programmierer, die sich nicht alle Mühe geben, fehlerfreien Code zu erstellen, weil das Korrigieren von Fehlern verdammt langweilig ist.

Im Wesentlichen glaube ich, dass es ein Kulturproblem ist, und ich hoffe, dass es sich ändern wird.

Die technischen Standards und Praktiken in der IT (als unabhängige Branche) unterscheiden sich stark von denen in der Luft- und Raumfahrt . Dies lässt sich am einfachsten verstehen, wenn man bedenkt, wie IT-Experten auf Standarddokumente für die IT in der Luft- und Raumfahrt reagieren . Zum Beispiel die Joint Strike Fighter C ++ - Standards , die sich in letzter Zeit im Internet durchgesetzt haben.

Viele drücken Verwirrung oder wehmütige Resignation aus (ich wünschte, wir könnten so vorgehen); und viele antworten mit Lächerlichkeit und behaupten, es gäbe keinen praktischen Weg, Konsumgüter auf diese Weise zu liefern. Dies mag angesichts der Erwartungen, die nicht an die Verbraucher, sondern an das Management gestellt werden, sogar richtig sein. Es gibt viel Misstrauen gegenüber Programmierern, die nur ein paar Wochen lang programmieren und programmieren, ohne etwas zu testen. Gott helfe dem Kodierer, der nur zwei Wochen lang etwas entwirft . Nicht so bei Flugzeugen.

In der Software erwarten die Leute wirklich, dass sie gerade etwas haben. Sicher, die Überlegung geht, es wird eine Weile dauern, bis es wirklich solide ist; Aber können wir in einer Woche nicht eine komplexe Sache in einfachen Worten beschreiben lassen ? Man lernt auch, dass komplexe Dinge, die in ehrlichen, komplexen Begriffen beschrieben werden, selten die Vorstellungskraft anregen; und so werden viele ingenieure mitschuldig an einer imaginären welt von wirklich einfachen dingen, die auf kreative weise zusammengesetzt werden (im gegensatz zu einer welt von harten dingen, die wirklich gut gemacht werden).

Ein paar Sachen von mir:

1- Standards und Teile: Sie sind Flugzeug - Hersteller , nicht die Entwickler. Ich bin mir nicht ganz sicher, aber ich vermute, dass viele Teile ausgelagert sind. Sie bauen keine eigenen elektronischen Instrumente, sie bekommen Sitze von einer Firma, die Motoren werden wahrscheinlich woanders entwickelt, usw.

Andererseits beginnen Softwareprojekte fast immer bei Null, wenn nur einige kleine Frameworks / Helfer vorhanden sind.

2- Zeit, um auf den Markt zu kommen: Zeit ist für Flugzeuge kein kritisches Thema. Ich wette, das Design des Airbus wurde Jahre vor seiner Fertigstellung fertiggestellt, und sie haben beschlossen, alle größeren Durchbrüche, die in dieser Zeit passieren könnten, zu vernachlässigen. (Gleiches gilt zum Beispiel für die Automobilhersteller. Die neueste Technologie, die sie derzeit entwickeln, wird in 5-10 Jahren auf die Straße gehen.)

Für Software muss man sehr agil sein, wenn ich jetzt ein riesiges Projekt starte und drei Jahre brauche, um es ohne Änderungen zu entwickeln, stehen die Chancen ziemlich hoch, dass ich mich auf Technologie verlasse, die nicht mehr verfügbar ist oder mein Produkt völlig veraltet ist. Dies bringt wiederum viele Probleme mit sich.

3- Release-Zyklus und Versionen. - Ein Flugzeug muss vollständig fertig sein, wenn es "freigegeben" ist. Es gibt keine stabilen Beta-Versionen, nächtlichen Builds oder ähnliches. Außerdem kann es, sobald es fertig ist, nur geringfügig geändert werden. Sie können einer vorhandenen Boeing kein zusätzliches Level mit 100 Plätzen hinzufügen, es ist einfach nicht möglich.

Software hat andererseits inkrementelle Änderungen, die oft nur "Builds, die funktionieren", aber nicht unbedingt fertige Produkte sind. Auch in der IT ist es nicht ungewöhnlich zu sagen: "Hey, fügen wir unserem Flugzeug einen weiteren Gepäckraum hinzu, der zusätzliche 50 Tonnen fasst."

Ich denke die Antwort ist ganz einfach:

1) Die physische Konstruktion und Implementierung gibt es seit Menschengedenken - wir hatten Tausende von Jahren Zeit, um unsere Methoden und Techniken für die Implementierung physischer Projekte zu entwickeln. Die Software 'Konstruktion', die eine völlig neue und andere Qualifikation erfordert, ist nicht älter als 50 Jahre - wir hatten noch nicht genug Zeit, um alles herauszufinden.

2) Virtuelles Bauen ist schwieriger - Sie müssen Dinge in Ihrem Kopf sehen, die überhaupt keine physische Realität haben. Sie müssen eine Menge Informationen analysieren und abstrahieren, bevor Sie überhaupt wissen, wie Ihr Produkt aussehen soll und welche Schritte zur Erstellung erforderlich sind. Nicht so beim Bau einer Brücke oder eines Gebäudes.

3) Es ist oft viel schwieriger, die Ursache eines Softwarefehlers oder -fehlers zu finden, als dies beim physischen Engineering der Fall ist. Wenn ein Träger knickt, sehen Sie, wo er knickt, und Sie sehen die Stützen, die ihn halten und ausfallen usw. Das Auffinden eines Softwarefehlers kann das Untersuchen einer großen Menge von Code und das Interagieren von Prozessen mit sich bringen - schwierig, zeitaufwendig und nicht an das gebunden Gesetze der Physik und Mathematik in der Art, wie physikalische Strukturen sind.

Ich werde versuchen, mit einer wörtlichen Kopie eines Artikels aus Jack Ganssles Muse zu antworten. Während dies Firmware überall sagt, ersetzen Sie sie nur mental durch Software.

Verglichen mit was?

Firmware ist die teuerste Sache im Universum. In seinem wunderbaren Buch "Augustine's Laws" erzählt Norman Augustine, ehemaliger CEO von Lockheed Martin, eine aufschlussreiche Geschichte über ein Problem, auf das die Verteidigungsgemeinschaft gestoßen ist. Ein Hochleistungskampfflugzeug ist ein empfindliches Gleichgewicht zwischen widersprüchlichen Anforderungen: Reichweite und Leistung. Geschwindigkeit gegen Gewicht. Es scheint, dass die Kämpfer in den späten 70ern ungefähr so ​​schwer waren, wie sie jemals sein würden. Bauunternehmer, die immer größere Gewinne anstrebten, suchten vergeblich nach etwas, das sie hinzufügen konnten, das viel kostete, das aber nichts wog.

Die Antwort: Firmware. Unendliche Kosten, keine Masse. Avionik macht jetzt mehr als die Hälfte der Kosten eines Kämpfers aus. Wenn man bedenkt, dass der jüngste amerikanische Jäger, die F-22, einen coolen Drittel einer Milliarde US-Dollar pro Kopf kostet, ist das eine Veränderung. Augustine lacht vor Freude, als er diese Geschichte erzählt.

Aber warum ist Software so teuer? Tom DeMarco hat diese Frage einmal mit diesen drei Worten beantwortet: Im Vergleich zu was? Er fuhr fort, relativ langweilige Geschäftsfälle zu besprechen, aber diese Antwort ist mir seit Jahren in den Sinn gekommen. Verglichen mit was? Mit Software erstellen wir routinemäßig Produktverhalten von beispielloser Komplexität. Klar, der Code ist teuer. Aber noch nie in der Geschichte der Zivilisation hat jemand etwas so Kompliziertes gebaut.

Betrachten Sie die folgende Blasensorte, die unverschämt aus Wikipedia stammt und nicht auf ihre Richtigkeit überprüft wurde:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

Es sind nur 110 Zeichen ohne Leerzeichen, die vielleicht in ein oder zwei Stunden weggeworfen werden. Angenommen, wir hatten keine Software und mussten eine Sortierung mit einer anderen Strategie implementieren. Was würde es kosten?

Ein Maschinenbauingenieur kann sich damit rühmen, dass sein Beruf lange vor Computern Sortierer gebaut hat. Betrachten Sie den IBM-Kartensortierer Modell 82 aus dem Jahr 1949 ( http://www.columbia.edu/acis/history/sorter.html ) mit einem Durchsatz von 650 Karten pro Minute, der sogar mit 4 MHz weniger aushält als unser Code-Snippet Z80. Das Modell 82 sortierte natürlich jeweils nur eine Spalte einer Karte; Um ein Deck vollständig zu sortieren, sind Dutzende Pässe erforderlich.

Wie lange hat es gedauert, dieses Biest zu entwerfen und zu bauen? Jahre, kein Zweifel. Und seine Funktionalität verblasst im Vergleich zu unserem Code, der viel schneller ist und mit riesigen Datensätzen umgehen kann. Aber das war 1949. Wie lange würde es dauern, eine Blasensorte aus elektronischen Bauteilen aufzubauen - ohne FPGAs und VHDL oder eine CPU?

In einer Stunde schaffte ich ein grobes Blockdiagramm, eines über der Chipebene (Blöcke haben Namen wie "Addierer", "16-Bit-Latch" und dergleichen). Aber die Sequenzierungslogik ist eindeutig ziemlich chaotisch, so dass ich gerade eine PLD eingeworfen habe, unter der Annahme, dass es irgendwann nicht mehr allzu schwierig wäre, die entsprechenden Gleichungen zu schreiben. Und ja, vielleicht verstößt dies gegen die Regel der nicht programmierbaren Logik, aber das Entwerfen und Debuggen all dieser Logik mithilfe von Gattern in einem angemessenen Zeitraum ist so unwahrscheinlich wie Gas mit einem Fassungsvermögen von 1 Liter.

Unter der Annahme von 16-Bit-Wörtern und -Adressen benötigt die Schaltung etwa ein Dutzend 16-Bit-Latches, Addierer und dergleichen. Plus Speicher. Und ich habe keine Ahnung, wie die unsortierten Daten in den Arbeitsspeicher gelangen oder wie die Ergebnisse exportiert werden. Dies sind nicht spezifizierte Designanforderungen. Die reine Softwarelösung löst diese Anforderungen natürlich nur durch das Schreiben des Funktionsprototyps.

Das Übersetzen des groben Blockdiagramms in einen Schaltplan kann einen Tag dauern. Dann haben Sie die Zeit, eine Leiterplatte zu entwerfen und herzustellen, Teile zu bestellen und zu laden (und das Design zu ändern, um die unerwarteten, aber unvermeidlichen Probleme am Ende der Lebensdauer zu lösen) und dann die Schaltung funktionsfähig zu machen. Wir könnten wochenlangen Aufwand und viel Geld für die Platine, Teile und die entsprechende Testausrüstung sprechen.

All dies, um 7 kleine Codezeilen zu ersetzen. Nur wenige echte Embedded-Programme sind weniger als 10.000. viele überschreiten eine Million. Wie viel Hardware und Engineering wäre erforderlich, um ein echtes, übergroßes Computerprogramm zu ersetzen?

Stellen Sie sich ein echtes Programm wie eine Tabelle vor. Wie viel Schaltungsaufwand würde es kosten, einen ohne Prozessor herzustellen? Es könnte die Größe einer Stadt haben.

Firmware ist die teuerste Sache im Universum, aber nur wegen der unvorstellbaren Komplexität der Probleme, die sie löst. Aber es ist viel billiger als jede andere Alternative. Wenn Ihr Chef Sie also gereizt fragt, warum die Software so lange dauert, wissen Sie, was Sie sagen sollen. Verglichen mit was?

Also da! Software / Firmware hat eine beispiellose Komplexität.

Software-Engineering und -Management unterscheiden sich grundlegend von vielen anderen Engineering-Bereichen. Die zu erbringenden Leistungen sind nicht physisch und der Produktionsprozess ist der Entwurfs- und Entwicklungsprozess. Das Erstellen einer weiteren Kopie einer Software verursacht im Wesentlichen keine Grenzkosten. Alle Kosten entstehen bei der Entwicklung der ersten Kopie.

Aufgrund der relativen Jugend des Software-Engineerings und -Managements als Disziplin gibt es einige Fehlinformationen und Falschinformationen, die immer noch als Tatsache angesehen werden ( siehe diese Referenz ), was die Softwareentwicklung und -entwicklung als Ganzes behindert.

Nicht alle Entwickler werden gleichermaßen erstellt. Einige sind gut, andere nicht.

Versuchen Sie, den Code anderer Leute ständig zu lesen, um ein Gefühl dafür zu bekommen, was ich sage. Zu viele zusätzliche logische Anweisungen können das Risiko erhöhen. Diese Risiken können zu Fehlverhalten oder Fehlern führen. Nicht genug logische Anweisungen und jetzt haben Sie keine Referenzen. Der gute Programmierer versteht das und weiß, wann was und wo zu tun ist. Aber niemand ist perfekt. Die Dinge sind komplex. Fügen Sie die schlecht durchdachten Arbeiten anderer hinzu, und es ist leicht zu sehen, wie Projekte ablaufen.

Früher dauerte der Bau von Kathedralen bis zu 100 Jahre.

Einige Airbus-Flugzeuge benötigen 1 Million Codezeilen.

Je mehr Zeit Sie für Verbesserungen aufgewendet haben, desto besser wird es. Geben Sie der Softwareindustrie ein paar Jahrhunderte Zeit, um sich zu verbessern, und wir werden sehen, wie viel Zeit erforderlich ist, um ein solides, riesiges Projekt ohne Fehler zu entwickeln oder Mängel.

Große Projekte treten häufig in großen Organisationen auf. Wenn Sie noch nie in einem großen Unternehmen gearbeitet haben, ist eine Leistung und Produktivität garantiert: Bürokratie.

Überraschenderweise wissen viele Menschen nicht, was Bürokratie ist (sie wird oft mit Politik verwechselt) oder auch wenn sie ein Bürokratieproblem haben.

Wir haben kürzlich ein Projekt zur Implementierung der Smartcard-Authentifizierung abgeschlossen. Es wurde ursprünglich auf drei Monate geschätzt. Es hat 15 Monate gedauert. Es gab keine Kosten, Budget, Umfang oder technischen Gründe für die Verzögerung. Der Umfang war eigentlich ziemlich eng - nur für Konten mit erhöhten Rechten (Administratorkonten), etwa 1.200 Gesamtkonten.

Ein weiterer wichtiger Faktor sind Ihre Geschäftspartner. Dies würde Anbieter einschließen. Wenn Ihre Partner ein Problem haben, das zu einer Verzögerung in Ihrem Projekt führt, gibt es nicht viele Optionen, mit denen das Verzögerungsproblem tatsächlich behoben werden kann. Sie arbeiten nicht direkt für Sie und Sie sind möglicherweise nicht in der Lage, diese eine Person auf einen Partner zu entlassen, der die Ursache sein könnte. Der Partner kann entlassen werden, oder es können finanzielle Sanktionen oder negative Anreize verhängt werden. Dies ändert jedoch nichts an der Tatsache, dass sich das Projekt verzögert hat. Genau dies geschah bei Boeing, als sie mit dem Boeing 787 Dreamliner eine Mammut-Sourcing-Strategie verfolgten .

Ich habe eine kürzere Version für Sie:

Was auch immer einfach zu tun oder zu optimieren ist, wir schreiben ein Programm, um es anstelle von uns zu tun.

Und dann stattdessen mit dem Meta-Prozess kämpfen.

Es ist per se nicht so viel wahr, aber jeden Tag werden Tausende von Blogs eingerichtet, anstatt Blog-Engines zu schreiben. An jedem Arbeitstag werden Tausende von Excel-Makros geschrieben, anstatt speziell dafür entwickelte Datenbankanwendungen zu schreiben.

Es gibt viele andere Faktoren, von denen einige hier erwähnt wurden, aber ich wollte diesen Punkt in die Diskussion aufnehmen.

Mangel an Rechenschaftspflicht ... Menschen werden angeklagt, wenn ein Flugzeug abstürzt. Die Softwareindustrie lehnt jede Verantwortung für Softwaremängel ab und schafft daher keinen Anreiz, ein robustes und sicheres Produkt zu entwickeln.

Die meisten großen Projekte weisen einen hohen Grad an Trennbarkeit von Unterprojekten auf, in denen Sie eine kleine Anzahl von Entwurfsbeschränkungen definieren können. Das gesamte Projekt wird funktionieren, wenn diese Unterprojekte abgeschlossen sind. Wenn in einem Teilprojekt etwas schief geht, wird der gesamte Aufwand nicht in Frage gestellt. Sie suchen nur nach alternativen Möglichkeiten, um das Teilprojekt fertigzustellen (z. B. verwenden Sie eine andere Engine).

Dies ist in Softwareprojekten sowohl praktisch als auch aus menschlicher Sicht möglich, aber schwierig.

Zum Teil haben andere Branchen auf die harte Tour gelernt, dass diese Art der Trennbarkeit eine gute Sache ist. Wenn Sie beispielsweise Rolls-Royce-Triebwerke verwenden, müssen Sie keine speziellen Rolls-Royce-Bolzen und Befestigungspunkte verwenden, die nur für Flügel mit einem bestimmten Design geeignet sind. Wenn Sie dann versuchen, zu Pratt und Whitney zu wechseln, Sie müssen Ihren gesamten Flügel von Grund auf neu gestalten (was wiederum eine komplette Neugestaltung des Rumpfes erfordert, was wiederum erfordert, dass Sie andere Sitze kaufen, was wiederum erfordert, dass Sie ein anderes Bordunterhaltungssystem kaufen, welche...). Es mag ein paar Verknüpfungen geben - man kann Motoren nicht einfach ohne Sorgfalt austauschen -, aber große Projekte funktionieren im Allgemeinen besser, wenn solche Dinge minimiert werden.

Ich postuliere, dass große Softwareprojekte, die als Cluster kleiner Softwareprojekte mit sauberen Schnittstellen untereinander entworfen wurden, nicht besonders oft scheitern, solange das große Projekt tatsächlich vom Cluster kleiner Projekte gelöst wird. (Es ist möglich, diesbezüglich einen Fehler zu machen.)

Das Erstellen von Softwaresystemen unterscheidet sich stark vom Erstellen physischer Strukturen. Das heißt, die Implementierung ist sehr unterschiedlich. Während Sie zum Beispiel einen riesigen Tanker bauen, erledigen Sie viele relativ einfache (wenn auch nicht leichte!) Aufgaben, wie das Zusammenschweißen von Teilen mit einem Roboter oder von Hand, das Anziehen aller Schrauben und Muttern, das Streichen und das Einarbeiten der Dekoration die Ausrüstung und Möbel und so. All dies ist wirklich sehr einfach zu erledigen.

Bei Software wird es jedoch viel komplexer . Wie genau implementieren Sie beispielsweise die sichere Anmeldung und die Benutzeranmeldeinformationen, die einen Teil des Produkts speichern? Welche Bibliotheken und Tools können Sie verwenden? Mit welchen Bibliotheken und Tools sind Sie vertraut? Wie genau schreiben Sie die Hashing + Salting-Funktion und wie stellen Sie sicher, dass sie sicher ist? Sie können dies auf so viele Arten tun, dass es unmöglich ist, tatsächliche praktische Entwurfsmuster für diese Art von Dingen festzulegen. Ja, die die Entwurfsmuster haben in einem kleineren Maßstab existieren als „Best Practices“, aber jedes einzelne Software - System ist sehr verschieden von den anderen, und die Feld Fortschritte und Veränderungen bei so schnellem Tempo , dass es im Wesentlichen unmöglich ist , Schritt zu halten.

Wenn Sie ein Haus bauen, stoßen Sie nicht wirklich auf solche Probleme, bei denen Sie bemerken, dass die Hauptstützwände unzulänglich zu sein scheinen und ersetzt werden müssen. Sie müssen den bisherigen Fortschritt abreißen und von der Basis aus mit dem Wiederherstellen der Stützwände beginnen . Sie lösen solche Probleme in der Entwurfsphase , da es relativ einfach ist, vorherzusagen, welche Art von Stützwänden Ihr Gebäude benötigt.

Dies ist jedoch bei Software nicht der Fall. Sie können das gesamte Produkt nicht wirklich als eine Einheit entwerfen und dann implementieren. Der Software-Design-Prozess ist in der Regel iterativ und die Ziele und Anforderungen ändern sich, während das Produkt implementiert und getestet wird. Softwareentwicklung als Ganzes ist ein iterativer Prozess, bei dem sich die Dinge normalerweise ändern, wenn sie am wenigsten erwartet werden, und oftmals bringen solche Änderungen Herausforderungen mit sich, die mehr Arbeit, mehr Komplexität und unglücklicherweise und letztendlich mehr Geld, Zeit und harte Arbeit erfordern, um die richtigen Ergebnisse zu erzielen.

Der Grund, warum es schwierig ist, große Projekte zu realisieren und Projektzeitpläne und Roadmaps abzuschätzen, liegt im Wesentlichen darin, dass Softwareentwicklung und insbesondere funktionierendes Design sehr komplexe Bereiche sind. Komplexität ist das Grundproblem.

Die Definition von "Großprojekt" ist verzerrt.

Technisch gesehen kann ein großes Projekt pünktlich und einwandfrei geliefert werden, vorausgesetzt, es wurde im Laufe der Jahre viele Male gebaut.

• Ein Pac-Man-Klon.
• Ein Taschenrechner
• Ein Texteditor

Ich bin sicher, Sie denken ... "Aber das sind kleine Projekte! Ein Texteditor ist einfach ." Ich würde mit Ihnen nicht einverstanden sein. Computer sind unglaublich kompliziert. Nur die Installation und Benutzer auf einem Betriebssystem einrichten kann manchmal schwierig sein, und Sie haben nicht einmal schreiben das Betriebssystem oder die Hardware bauen.

Die Projekte, über die Sie sprechen, sind riesige Projekte, ähnlich der Weltraumforschung. Woher weißt du, wie lange es dauert, um intergalaktische Reisen zu entwickeln? Auf welchem ​​Modell bauen wir es auf? Sie haben die bekannten Bekannten, die bekannten Unbekannten, die unbekannten Bekannten und schließlich die unbekannten Unbekannten, die in der Softwareentwicklung häufig vorkommen.

Ich denke, das Problem ist die Erwartung. Nur weil die Technologie da ist, heißt das noch lange nicht, dass sie für eine Weile erfolgreich (oder sinnvoll) sein wird. Wenn sich andere Branchen so verhalten würden wie die Softwareindustrie, würden wir bis Ende des Jahrzehnts Staubsauger mit Schwarzlochantrieb zum Verkauf anbieten. Oder ein "Visionär" hätte die Ressourcen, um eine Mondbasis aufzubauen und zu entscheiden, dass ein Starbucks das Erlebnis für die Besucher wirklich "abrunden" würde. Ich glaube nicht, dass das Problem in der Softwareindustrie liegt, sondern in den Erwartungen, die an sie gestellt werden.

Obwohl es kaum das Einzige ist, was erwähnt werden könnte, ist meines Erachtens eine grundlegende Sache erwähnenswert. Die meisten Produkte sollen zum vorhandenen Verhalten passen. Sogar ein Produkt, das einen radikalen Durchbruch darstellt (zum Beispiel das Auto), passt sich im Allgemeinen dem vorhandenen Verhalten an und macht es einfach ein bisschen einfacher / einfacher / billiger / was auch immer. Ja, es gibt oft auch einige Nebeneffekte auf das vorhandene Verhalten (z. B. Kraftstoff für das Auto anstelle von Futter für die Pferde), aber die meisten letzteren sind eher geringfügige Nebeneffekte.

Im Gegensatz dazu ist fast jede Software, die das Verhalten der Benutzer nicht ändert (zum Beispiel, um sie ihre Arbeit wesentlich einfacher erledigen zu lassen), ab dem ersten Tag ein völliger Fehlschlag betreffen das Verhalten von Benutzern auf individueller Ebene, aber auch das Verhalten großer Gruppen - oft die gesamte Organisation.

Kurz gesagt, das Entwerfen der Software selbst ist oft der einfachste Teil der Arbeit. Der schwierige Teil besteht darin, die Arbeitsplätze der Menschen für sie neu zu gestalten. Das ist schwer zu beginnen; es auf eine Weise zu tun, die nicht nur funktioniert, sondern auch akzeptiert wird, ist noch viel schwieriger.

Airbus A380 war kein erfolgreiches Projekt, wie Sie erwähnt haben. Ich arbeite zufällig in einem CAD / CAM-Unternehmen, und es wurde mir mitgeteilt, dass es (wir hatten auch das Airbus-Projekt) um einige Jahre verzögert war, weil sie in verschiedenen Unternehmen unterschiedliche Softwareversionen verwendeten. Das heißt, verschiedene Teile wurden in verschiedenen Teilen der Welt entworfen. Und während der Integration haben sie festgestellt, dass nicht alle Designs integriert werden können, und müssen sie daher in einer Version neu gestalten. Wenn ich es mir also ansehe, glaube ich nicht, dass es erfolgreich war. Hätte es 2-3 Jahre zuvor stattgefunden, wäre es für Airbus ein Game Changer gewesen.

Auch in Bezug auf robuste Software sehen Sie jedes Flugzeug, Auto (ABS, EPS, Klimaautomatik usw.) oder Space Shuttle, das zu mehr als 50% über Software verfügt, und glauben, dass es sehr robust ist. Es ist nur so, dass wir uns mehr der Software nähern, und es gibt viel mehr Softwareprogramme, so dass wir mehr Fehler darin sehen.

Besuchen Sie: http://www.globalprojectstrategy.com/lessons/case.php?id=23 und sehen Sie, wie erfolgreich der Airbus A380 war.

Hier ein Software-Ingenieur mit einem technischen Hintergrund und einer Frau, die im Baugewerbe arbeitet. Wir haben lange Diskussionen (und Auseinandersetzungen) über die Unterschiede unserer Jobs geführt.

Bei der Softwareentwicklung geht es darum, neue Dinge zu entwerfen . Fast alles Grundlegende wurde in einer Open-Source-Bibliothek irgendwo getan. In fast jedem Job, in dem ein Softwareentwickler eingestellt wird, muss sie etwas entwerfen, das es nicht gibt.

In so etwas wie Konstruktion und den meisten Formen des Ingenieurwesens sind Dinge, die sich sonst in einer "Bibliothek" in Software befinden würden, bereits vollständig entworfen. Willst du einen Turm bauen? Kopieren Sie einfach die Pläne aus einer vorhandenen Struktur und fügen Sie sie mit ein paar Änderungen ein.

Einer der Hauptgründe, warum ich beschlossen habe, kein Ingenieur zu werden, ist, dass Sie die meiste Zeit damit verbringen, eine 10% ige Verbesserung einer vorhandenen Erfindung zu entwerfen, wenn dieselbe Zeit verwendet werden könnte, um etwas Sichtbareres wie ein soziales Netzwerk zu programmieren .

Es gibt nicht viele neue Konstruktionen im Maschinenbau. Ein äußerst erfahrener Ingenieur ist jemand, der ein vorhandenes Design in etwas Neues verwandeln oder verbessern kann. Von fast jedem Programmierer wird jedoch erwartet, dass er Designs ändert, sie hackt oder etwas Neues erstellt.

Sehen Sie sich noch einmal an, wie weit sich die Standards von Assembly über C über C ++ bis hin zu Java, JavaScript, C #, PHP usw. vollständig geändert haben . Es gibt nicht viel Code, der seit 10 oder 20 Jahren recycelt werden kann. Dies ist etwas ganz anderes als ... die Automobil- oder Luftfahrtindustrie, in der Sie Konstruktionen aus Jahrzehnten verbessern können.

Projektmanagement ist in der Software notorisch schwierig . Zeitschätzungen werden am besten von Leuten durchgeführt, die die Arbeit erledigen , aber wenn sie damit beschäftigt sind, Schätzungen vorzunehmen, schreiben sie keinen Code . Das verleitet dazu, auf Projektmanagement zu verzichten.

Oft hängt eine Menge Code von bestimmten Personen ab, und wenn diese Personen zu spät oder nicht in der Lage sind, eine Leistung zu erbringen, bewegt sich der Code nicht weiter. Wenn Sie dagegen ein Auto bauen möchten, können Sie einfach verschiedene Personen einstellen, um die Reifen, das Fahrgestell, die Batterie, den Motor usw. zusammenzubauen. Objektorientierte und vorhandene Frameworks machen dies möglich, aber es ist möglicherweise nicht praktisch, wenn Sie alles von Grund auf neu entwerfen.

In der Software sind möglicherweise Fehler zulässig . Testen kann teuer sein. In der Software ist es sehr verlockend, all diese Tests zu überspringen, wenn Sie nur einen Absturz beheben können. Bei den meisten Konstruktionsformen kann ein Absturz tödlich sein.

Sie verfügen über Programmiermethoden, die umfangreiche Tests erfordern, z. B. extreme Programmierung (die tatsächlich für Software-Megaprojekte verwendet wurde). Bei engen Fristen (die absichtlich verkürzt werden können) ist es jedoch verlockend, die gesamte Programmierung zu überspringen und mit Fehlern zu starten. Der Joel Spolsky- Stil, "immer alle Fehler zu beheben", wird auf lange Sicht mehr Zeit sparen, aber der Undisziplinierte wird dies überspringen und scheitern.

Kleine Projekte sind besser . Meine Frau hat mich einmal gebeten, einen Job in einer großen Firma zu bekommen. Es endete mit einem Argument, dass große Unternehmen schlechte Unternehmen sind ... für sie verfügte ein großes Unternehmen über eine Menge Ressourcen, Erfahrung, funktionales Projektmanagement und die richtigen Verfahren. Für mich ist eine große Firma ein Dinosaurier, in dem Sie den größten Teil Ihrer Zeit damit verbringen, Code zu reparieren, zu testen und zu dokumentieren.

Ich habe IT-Projekte in Millionenhöhe gesehen, an denen weniger als 10 Personen gearbeitet haben. Mehr Leute hätten das Projekt verlangsamt und unnötige Bürokratie hinzugefügt. WhatsApp ist ein Beispiel für ein "kleines" Projekt, das Milliarden von Dollar wert ist. Es ist nicht so, dass große Projekte nicht möglich sind, aber Sie brauchen einfach nicht Tausende von Menschen, um Software im Wert von Milliarden von Dollar zu produzieren.

Ein Grund, der in den anderen Fragen nicht wirklich behandelt wurde, ist, dass das Gebiet der Software mit einer Geschwindigkeit innoviert, die in der materialbasierten Welt nur selten vorkommt.

Ein Grund dafür ist, dass die Softwareentwicklung ein positiver Feedback-Zyklus ist, da Software (Programmiersprachen, Build-Tools, IDEs) zum Erstellen von Software verwendet wird. Es ist das offensichtlichste Beispiel für das Gesetz von Ray Kurzweil, mit dem die Renditen beschleunigt werden, was zu einem exponentiell wachsenden Fortschritt führt. Sobald Sie einen Rahmen, Programmiersprache, Kommunikationsprotokoll gemeistert haben , ist es Zeit, sich auf die nächste.

Wenn Flugzeuge wie Software gebaut würden, würden wir das Material mit jedem anderen Modell austauschen, ihre Kapazität und Geschwindigkeit alle 18 Monate verdoppeln, die Motorentechnologie für jedes neue Modell durch etwas neu erfundenes ersetzen und gleichzeitig die Fähigkeit zum Schwimmen und zur Suche nach Außerirdischen hinzufügen Leben.

Oh, und im Idealfall hört es auf Sprachbefehle und fungiert auch nach Beendigung Ihrer Geschäftsreise als ein Kino, eine Paintball-Arena und ein Nachtclub mit dunklem Raum. Das gleiche! (Die Firma, die Flugzeuge baute, die Sie gerade zuverlässig von A nach B brachten, ging ein Jahr nach dem Erscheinen der mit Kino, Paintball und Nachtclub ausgestatteten Firma auf die Palme.)

Das Hauptproblem bei der Softwareentwicklung sind für mich Anwendungsfälle, Benutzer und plattformübergreifende Anwendungen.

Anwendungsfälle

Wie viele Anwendungsfälle hat ein Flugzeug? Das meiste davon ist nur von einem Ort zum anderen zu fliegen. Vielleicht gibt es mehr wie Radar, Verkehrskontrolle usw., aber der Anwendungsfall ist klar und nicht viel. In der Softwareentwicklung sehen wir uns mit unklaren Anforderungen und Anwendern konfrontiert, die nicht wissen, was sie wollen. Unterschiedliche Benutzer benötigen unterschiedliche Konfigurationen / Abläufe. Kann ein Flugzeug nach Belieben angepasst werden (ich möchte einen Fernseher und einen Kühlschrank haben!)?

Benutzer

Wer betreibt ein Flugzeug? Ein Pilot, ein Copilot, einige Stewards (sofern gezählt) und Turmbediener. Sie sind alle Profis und haben klare Stellenbeschreibungen. Software wird von Noobs und Dummies verwendet, ganz zu schweigen von bösen Hackern und Crackern, und muss dennoch mit anderen Modulen (wie OpenID oder Google AdSense ) integrierbar sein. Wenn ein Flugzeug von Dummies bedient werden kann, ohne von Raketen oder Ninja-Räubern getroffen zu werden, kann man sagen, dass das Flugzeug mit der Software die gleiche Qualität hat.

Plattformübergreifend

Ein Flugzeug fliegt nur in den Himmel der Erde. Ich bin mir nicht sicher, wie sie mit dem nebligen, windigen oder heißen, kalten und feuchten Klima umgehen sollen, aber ein Flugzeug ist nicht dafür ausgelegt, mit unterschiedlicher Gravitation zu fliegen (ich bin erstaunt, ob es zum Mars fliegen kann ). Manchmal muss eine Anwendung verschiedene Plattformen überleben, z. B. Internet Explorer, Google Chrome , Firefox und Safari für Browser (sorry Opera ) oder Windows XP / 7/8 oder Linux für Betriebssysteme. Ganz zu schweigen von mobilen Geräten und unterschiedlichen Auflösungen und Ausrichtungen.

Wenn Sie der Meinung sind, dass andere Branchen Projekte ohne Zwischenfälle abschließen, sollten Sie die Geschichte über das Gebäude des Citigroup Centers lesen, das 1977 gebaut wurde. Auch nach fast 7 Jahren Planung und Bau wurde das Gebäude mit einem schwerwiegenden Konstruktionsfehler fertiggestellt, der einen Zusammenbruch von a verursacht hätte Sturmereignis alle 16 Jahre erwartet.

Mit anderen Worten, für jedes Jahr, in dem das Citicorp Center stand, bestand eine Wahrscheinlichkeit von 1 zu 16, dass es zusammenbrach.

Die ursprünglichen Designer waren sich der Probleme nicht bewusst, aber zum Glück wurde sie von einem Studenten entdeckt, der das Gebäude studierte.

Alles schien in Ordnung zu sein - bis er, wie LeMessurier sagte, einen Anruf erhielt. Laut LeMessurier meldete sich 1978 ein Student der Architektur bei ihm mit einer kühnen Behauptung über das Gebäude von LeMessurier: Das Citicorp Center könnte im Wind umkippen.

Reparaturen wurden im wahrsten Sinne des Wortes im Schutz der Nacht durchgeführt, wobei die geringste Anzahl von Personen involviert war, um die Geheimhaltung des Konstruktionsfehlers zu wahren.

Für den das Gebäude umgebenden Radius von 10 Blöcken wurde ein Notfall-Evakuierungsplan erstellt.

Sie schweißten die ganze Nacht und hörten bei Tagesanbruch auf, als die Bewohner des Gebäudes wieder zur Arbeit gingen.

Die Geschichte blieb ein Geheimnis, bis der Schriftsteller Joe Morgenstern mithörte, wie sie auf einer Party erzählt wurde, und LeMessurier interviewte. Morgenstern brachte die Geschichte 1995 in The New Yorker auf den Punkt.

Welches wirft die Frage auf; Wie viele andere schwerwiegende Konstruktionsfehler in Projekten wurden ohne öffentliche Anerkennung heimlich repariert oder ignoriert?

• Der Designfehler, der einen NYC-Wolkenkratzer fast ausgelöscht hat (slate.com)
• Citigroup Center (wikipedia.com)