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

509

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?

Arseni Mourzenko
quelle
127
Interessante Frage. Ich bin versucht zu sagen, dass die Qualität eines durchschnittlichen Arbeitnehmers in der Softwareindustrie weniger qualifiziert und qualifiziert ist als zum Beispiel im Tiefbau, wo jeder Ingenieur einen rigorosen und intensiven Abschluss gemacht hat und wahrscheinlich auch seine Charta erhalten hat. Darüber hinaus ist der Komplexitätsraum großer Software (z. B. eines Betriebssystems, MS Office) wahrscheinlich viel größer als der eines Flugzeugs. Mit Sicherheit noch viel mehr Orte zum Scheitern! Und noch ein letzter wichtiger Punkt: Die meisten Programme funktionieren mehr oder weniger, auch wenn sie schlecht geschrieben und sehr fehlerhaft sind ... die Ausfallkosten sind in der Regel viel geringer als bei einem Flugzeug!
Noldorin
155
Finden Sie jemanden, der tatsächlich in einer dieser anderen Branchen arbeitet (aber nicht in der PR) und fragen Sie ihn nach "großen, fehlerfreien Projekten". Ich kann praktisch garantieren, dass Sie schmerzliches Lachen verdienen.
Michael Borgwardt
151
Die Realisierung eines Softwareprojekts dauert Sekunden oder Minuten. Das passiert, wenn Sie in Ihrer IDE auf "Kompilieren" klicken. Auf der anderen Seite ist Programmierung Design . Wie lange hat das Design des A380 gedauert?
Ant
53
Das Fernsehprogramm ist ein Hype. Sie strahlen nur erfolgreiche Projekte aus. Jeder Kanal wird die Aufmerksamkeit der Zuschauer auf Programme lenken.
Pandu
117
Stellen Sie sich vor, Sie installieren zweimal pro Woche Updates für jeden Airbus A380. Stellen Sie sich vor, feindliche Roboter durchsuchen das Flugzeug ständig nach Sicherheitslücken, während ungeübte Piloten nach dem Zufallsprinzip Knöpfe drücken. Ich wette, Sie benötigen regelmäßige Patches.
Nathan Long

Antworten:

337

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.

user53019
quelle
23
Es war schwierig, eine Antwort unter mehreren sehr guten Antworten auszuwählen, aber ich wähle diese letztendlich aus, obwohl sie nicht die höchsten Stimmen hat. In der Tat, sowohl diese Antwort als auch die von m3th0dman genau, warum es eine solche Spezifität in der IT-Branche gibt, die hilft zu verstehen, was in Zukunft zu tun ist, um die Lücke zu schließen. Verglichen mit der Antwort von m3th0dman scheint diese viel detaillierter zu sein.
Arseni Mourzenko
3
+1 Aber ich möchte nur hinzufügen, dass Software, da sie im Bereich des Verstandes existiert, nahezu unbegrenzte Möglichkeiten hat, während jede gebaute Ebene mit den endlichen Anforderungen der Realität konkurrieren muss.
Spencer Rathbun
5
Sehr gut beantwortet. Als interessantes Beispiel: Stellen Sie sich vor, ein großes Flugzeug wurde von einer Gruppe von Leuten ohne Prozess- oder Firmengeschichte entworfen und implementiert - Leute, die sich gerade zusammengeschlossen und ein Unternehmen gegründet haben, um ein Flugzeug im Maßstab einer 747 von Grund auf neu zu bauen. So werden 90% der Softwareprojekte, die ich gesehen habe, durchgeführt. Die anderen 10% mit erfahrenen Architekten und Unternehmen mit Geschichte und Prozess scheinen viel erfolgreicher zu sein. Schauen Sie sich als Gegenbeispiel den Entwicklungsprozess hinter Software an, bei dem Menschen sterben, wenn sie versagt.
Bill K
7
Ich denke, Sie haben die falsche Antwort akzeptiert. Danny Woods hatte Recht, Fehler in anderen Branchen sind ebenso häufig, und das Programmieren baut nicht auf dem Design auf. Die Erstellung in der Software-Welt erfolgt durch den Compiler und ist praktisch kostenlos. Ihre ursprüngliche Frage war sehr aussagekräftig. Sobald die Vorarbeiten (Entwurf, Spezifikationen usw.) auf Papier erledigt sind, ist die Entwurfs- und Spezifikationsarbeit einer physischen Struktur eine GENAUE Spezifikation für den Aufbau der Struktur. Das einzige, was dazu in der Software-Welt passt, ist Code. Code ist Design, Compilation ist Konstruktion.
Michael Brown
5
Aber die Frage selbst ist fehlerhaft. Wir müssen uns allerdings kritisch mit unseren eigenen Mängeln auseinandersetzen. Es ist lächerlich zu tun, als ob die Softwareindustrie die einzige ist, die erfolglose Projekte hat. Zu sagen, dass "sobald das Design fertig ist", ist ebenso aussagekräftig. Auch wenn Sie nicht der Meinung sind, dass Programmierung eine Designaktivität ist, wie oft sehen Sie detailliertes, eisernes Design, das im Vorfeld für Software erstellt wurde? Die Leute geben unscharfe Spezifikationen für Software ab, weil sie damit rechnen, die Software ändern zu können, wenn die Spezifikationen nicht stimmen, ohne sich darum zu kümmern, wie sich diese Änderungen auf die gesamte Lösung auswirken könnten.
Michael Brown
452

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.

Danny Woods
quelle
47
Selbst in der vom OP genannten Branche hatten Aerospace, der Boeing 787 Dreamliner und JSF F-35 erhebliche Verzögerungen. Letzte Woche ist ein Parkplatz in einem der großen Einkaufszentren in Sydney eingestürzt. Sydney hat sehr strenge Baustandards, aber Fehler passieren.
Teambob
23
Tausendmal so. Auch der Zeitplan Link zeigt auf die Frage , dass das Projekt von 1988 tatsächlich in der Entwicklung war der Quellcode ist das Design: developerdotstar.com/mag/articles/reeves_design.html
PKH
2
Viele große Projekte wie das F-35, Hubble Telescope usw. kamen aufgrund der Software-Seite der Entwicklung zu spät. Der Hubble lag tatsächlich jahrelang im Speicher, weil die Software nicht bereit war.
MrLane
11
@ MrLane: In der realen Welt funktioniert es so. Es wird ein Zeitplan festgelegt, wann die Hardware und die Software ausgeführt werden sollen. Die Hardware-Designer stellen dem Software-Team einen ICD zur Verfügung, damit das SW-Team seinen Code ohne die Hardware schreiben kann. Die Hardware verschiebt ihren Zeitplan um ein Vielfaches und ändert ihre Schnittstellen, um die Hardwareprobleme zu umgehen, ohne das SW-Team zu benachrichtigen. Endlich funktioniert die Hardware und wird viel zu spät ausgeliefert. Natürlich funktioniert der SW aufgrund der Vielzahl unerwarteter hw "Features" nicht. Weil es billiger ist, Hardwareprobleme in ... zu beheben
Dunk
11
Software muss das sw-Team nun die Änderungen am ICD einarbeiten und Problemumgehungen für fehlerhafte Hardware finden. Also, zusätzlich zu der Tatsache, dass die Hardware viel zu spät geliefert wird und das SW-Team nun auch fehlerhafte Hardware repariert, wer wird dafür verantwortlich gemacht, dass es zu spät ist? Nun, das Software-Team ist noch nicht fertig. Es ist die Software, die zu spät ist. Jeder vergisst immer die Zeitpläne für Elektrotechnik, Mechanik und Systemtechnik, von denen sw abhing und die dann dazu zwangen, sw umzuschreiben und zusätzliche Anforderungen zu stellen. Sie sehen nur, dass das sw-Team immer noch programmiert. Somit ist die Software zu spät.
Eintauchen
180

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.

m3th0dman
quelle
55
Ein formaler mathematischer Beweis in Software ist neben der Tatsache, dass es oft praktisch unmöglich ist, richtig zu machen, letztendlich nichts anderes, als das Programm zweimal zu schreiben (einmal in der eigentlichen Programmiersprache und einmal in der formalen Beweisspezifikationssprache) und beides zu überprüfen Versionen machen genau das gleiche.
Tdammers
5
Es gibt Tools, mit denen Sie beides gleichzeitig schreiben können: Coq unterstützt die "Programmextraktion", um ein Programm in OCaml oder Scheme aus einem zertifizierten Coq-Programm zu extrahieren.
jkff
66
Msgstr "Änderung der Anforderungen nach dem Start der Implementierung". Ich nenne das das "Umzugsproblem". Sie bauen ein Haus, geben dem Badezimmer den letzten Schliff und der Eigentümer möchte die Toilette an einem anderen Ort haben. Sie geben ihnen den Kostenvoranschlag. Sie sträuben sich und sagen: "Warum so sehr, ich will nur die Toilette 8 Fuß entfernt haben?". Anschließend erklären Sie, dass Sie neue Leitungen installieren, Wände / Böden aufreißen usw. müssen, um zur Toilette gehen zu können. Späte Änderungen sind immer teuer.
Die Lazy DBA
7
Ich würde sagen, dass das Testen eines Flugzeugs viel schwieriger ist als das Testen einer Software. Mit dem Flugzeug ist all die mathematische Magie, die Sie heraufbeschworen haben, nutzlos, wenn Sie dachten, dass der Software-Simulator oder die von Ihnen erstellten Windturbinen nicht wirklich die Funktionsweise widerspiegeln, wenn Sie sich dort oben befinden. Formale Beweise in Software sind nur ein schweres Problem im Vergleich zu formalen Beweisen im Engineering, die unmöglich sind.
Lie Ryan
2
# 1 in Ihrer Liste ist die wichtigste IMO. Ich möchte noch zwei Dinge hinzufügen: - Viele große Änderungen können in einem kurzen Zeitraum vorgenommen werden (zum Beispiel 'Lasst uns das Kommunikationsprotokoll wechseln!'), Die nichts kaputt machen Kurzfristig, aber viele davon machen es auf lange Sicht sehr schwierig, das Projekt zu managen. - Die Änderungen in der Umgebung, in der die Software ausgeführt wird, können sich in kurzer Zeit drastisch ändern. Während die Grundvoraussetzungen für ein Flugzeug gleich bleiben (muss in Stürmen fliegen, muss auf festen Landebahnen landen, ..), kann eine Software völlig kaputt gehen, wenn zum Beispiel die neue Version des Betriebssystems herauskommt.
Sydney
140

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.

Jim in Texas
quelle
10
Einverstanden. Ich glaube, es gibt eine falsche Einstellung, dass Software "schlampiger" produziert wird als physisches Material, weil schlechte Software mit Korrekturen endet, die sehr gut sichtbar sind, und jeder mit defekter Software zu tun hat. Wenn ein Flugzeug ein Miststück ist und sie daran arbeiten müssen, senden Sie es nicht zurück. In den meisten Fällen beklagen sich die Mechaniker untereinander, es sei denn, es handelt sich um einen großen Defekt. Und das passiert auch.
Ben Brocka
6
Ich denke, die Frage bleibt bestehen, obwohl die Beispiele fehlerhaft sind. Es ist statistisch erwiesen, dass Softwareprojekte viel höhere Endkosten haben und viel länger dauern als vorhergesagt.
Euphoric
18
Es ist zu beachten, dass der Entwurf und die Implementierung eines kommerziellen Verkehrsflugzeugsystems von Natur aus den Abschluss eines massiven und äußerst komplizierten IT-Projekts umfasst , das vollständig und ordnungsgemäß funktionieren muss.
Pointy
6
Und da der A380 erst 2010 einen großen Rückruf hatte, würde ich ihn auch dann nicht als "fehlerfrei" bezeichnen.
Muhammad Alkarouri
3
Außerdem wurden im Laufe der Jahre VIELE Konzeptflugzeuge finanziert und gestrichen, insbesondere Militärverträge. Flugzeuge sind überhaupt keine guten Beispiele, weil wir erst viele Jahre oder Jahrzehnte später von vielen (klassifizierten) Ausfällen hören.
SilverbackNet
112

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?

Der Baumeister
quelle
2
+1 Danke für den Einblick. "Entwerfen, wenn Sie wissen, wie die Dinge funktionieren" -> "Entwerfen, wenn Sie nicht wissen, wie die Dinge funktionieren"?
Tokland
Hey Baumeister, ich habe einige Änderungen an diesem Beitrag vorgeschlagen. Ich denke, Sie haben ausgezeichnete Punkte. Ich habe nur versucht, ein bisschen Grammatik aufzuräumen.
Steven
Ich stimme definitiv dem Punkt zu, dass das Programmieren eher eine Kunst als ein Ingenieur ist. Kreativität ist für mich oft ein zentraler Aspekt im Software-Design.
Lanzafame
1
Ich bin mit der Behauptung nicht einverstanden, dass ein großes Softwareprojekt und ein Tower eine ähnliche Komplexität aufweisen - basierend auf meiner Erfahrung als Statiker und Softwareentwickler würde ich sagen, dass die Softwarekomplexität viel höher ist. Es gibt wahrscheinlich eine Reihe von Gründen dafür, aber ich würde vorschlagen, dass es im Ingenieurwesen eine Menge Spielraum gibt. Die Obergrenze des Konstruktionsentwurfs ist fast immer durch die Kosten gegeben, und das ist eine weiche Einschränkung. Software muss genau sein , da Computer mit Mehrdeutigkeiten nicht gut umgehen können. Platte funktioniert nicht? Fügen Sie eine Scheiße Stahl hinzu, sie wird Recht haben.
Simon Robb
Einige Leute entwerfen und bauen Gebäude zum Vergnügen. Sagen Sie es meinem Arbeitgeber nicht, aber jetzt, wo ich darüber nachdenke, ähnelt ein Teil meiner Software der Sagrada Familia: Eigenwillig, zu viele Ornamente, nie ganz fertig; aber von interessantem Design, Spaß zu bauen und zu verwenden und immer noch zu stehen.
Peter A. Schneider
44

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.

Euphorisch
quelle
2
"Dieses Verständnis ist die Grundlage für agile Methoden". Genau. Die Wasserfallmethode ist für Wolkenkratzer sinnvoll: Sie möchten, dass jedes Detail in der Blaupause stimmt, bevor Sie das Fundament einfüllen. Aber wenn das Abreißen und Wiederherstellen von Wolkenkratzern kostenlos und nahezu augenblicklich wäre, wie das Kompilieren von Code, würden Sie wahrscheinlich einen iterativen Prozess verwenden.
Nathan Long
22
@NathanLong: Vor allem, wenn alle drei Jahre neue Betonformen herauskamen und jemand herausfand, wie man mehrere Aufzüge in einem einzigen Schacht betreiben kann, und plötzlich war Stahl nicht mehr cool und alle entschieden sich, ihre Gerüste aus Kohlenstoff zu bauen Ballaststoff. In der Softwareindustrie geht so etwas ständig vor.
TMN
2
"Softwareentwicklung ist meistens ein Designprozess, bei dem das Designdokument der Quellcode selbst ist." Sie haben gerade meine Augen geöffnet. Vielen Dank.
Bro Kevin D.
@TMN Stellen Sie sich vor, Sie würden beim Erstellen eines Wolkenkratzers die Farbpalette des Innenraums ändern, weil sie nicht richtig aussieht. Das gilt für jede Komponente des Gebäudes. Der Versuch, mehrere Aufzüge auf einem einzigen Schacht zu betreiben, ist eine Sache, aber Sie müssen 20 Aufzüge von verschiedenen Anbietern testen, bevor Sie überhaupt versuchen, sie alle am Schacht zu befestigen ...
Loïc Faure-Lacroix
@ LoïcFaure-Lacroix: Ingenieure könnten 20 verschiedene Aufzüge testen, Entwickler würden einfach den im Blogbeitrag beschriebenen verwenden, in dem sie zum ersten Mal davon erfahren haben. Als sich das Gebäude öffnete und ein Problem mit den Aufzügen auftrat, stellten sie fest, dass die Firma, die sie baute, nicht mehr existierte. Als sie versuchten, Ersatz von einem anderen Lieferanten zu erhalten, stellten sie fest, dass ihre ursprünglichen Aufzüge einen nicht standardmäßigen Schacht verwendeten ...
TMN
39

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.

Kennah
quelle
8
Genau das passiert. Die Managementtypen oder die Kunden ändern alle 10 Sekunden ihre Meinung, was die Entwickler nur frustriert. Ich habe meinen letzten Job wegen so einem Mist gekündigt
Erin Drummond,
3
Dies fällt mir ein: youtube.com/watch?v=BKorP55Aqvg&feature=kp
miraculixx
21

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.

Peter Mortensen
quelle
5
+1. Gutes Beispiel für die Normung (Normblatt einer einfachen Schraube). In der IT sind die normalisierten Komponenten selten. Nehmen Sie Registrierungsformulare: Jede Website erfindet ihre eigene neu, und nur wenige Entwickler wissen, wie sich ihr Registrierungsformular mit Unicode, mit leeren Zeichenfolgen, mit zu langen Zeichenfolgen usw. verhält.
Arseni Mourzenko
1
@MainMa: schlechtes Beispiel, erstellen Sie Ihre Schaltflächen, Textfelder, Optionsfelder, Optionsfelder aus divs? Nein, Sie verwenden die Formularelemente des Browsers erneut. und die Browser verwendeten die Formularelemente des Betriebssystems.
Lie Ryan
4
Ich habe eher über die Einbauten gesprochen, nicht über die Kontrollen. Nehmen Sie eine zufällige Website. Können Sie chinesische Zeichen als Passwort verwenden? Können Sie 25-stellige Passwörter verwenden? Was passiert, wenn Sie ein Leerzeichen in Passwort oder Benutzername eingeben? All dies könnte normalisiert werden, ist es aber nicht und jede Person erfindet das Rad für jedes Projekt neu, oft schlecht, dh kein Hashing und / oder Salting, oder Passwörter, die auf 16 Zeichen begrenzt sind (Beispiel: MSN) usw.
Arseni Mourzenko
4
Ein Wechsel der IT von "Handwerkern" zu "Fabriken" ist möglicherweise nicht möglich. Fabriken führen einen Prozess aus, der bereits erstellt wurde. Arbeiter in einer Fabrik führen ihren Prozess mit wenig oder gar keinem menschlichen Gedanken aus. Aufgrund dieser Tatsache haben viele Fabriken Menschen durch Roboter ersetzt. In der Software führen Sie keinen Prozess aus, sondern erstellen einen. Das Erstellen von Software ähnelt eher dem Entwerfen der Fabrik und ihrer Prozesse als dem Ausführen der Fabrik. Obwohl die Softwareerstellung von Standards profitieren könnte, kann sie nicht grundsätzlich zu einer Fabrik werden.
mike30
@ArseniMourzenko Es ist ein schlechter Vergleich, "Datenblätter für Schrauben" (dh Werkzeuge, Ausrüstung) mit "Registrierungsformularnormen" zu vergleichen. Registrierungsformulare ähneln eher "einem Dach" oder "einer Haustür" (tatsächlich gibt es zig Möglichkeiten, diese zu erstellen). Ein Bolzen ist im Vergleich eher mit dem Verhalten einer Prozessor-Pipeline vergleichbar. Es ist nirgendwo in der Nähe zu dem, was wir brauchen: zuverlässige OS (mit streng definierten Eigenschaften, nicht „Daten , die die Scheibe treffen können auf den Mount - Optionen je nach verwendeten“) und dito Entwicklungs - Tool (sie müssen für Standard 90% des Codes zu überprüfen , um die Lage sein , Eigenschaften)
sehe
15

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 ;-)

Karim Agha
quelle
5
Windows wurde oft nicht rechtzeitig ausgeliefert (Longhorn, auch bekannt als Windows Vista, sollte ursprünglich im Jahr 2003 ausgeliefert werden). Ich kenne Office nicht, aber die meisten anderen Softwareprojekte, die Sie explizit erwähnt haben, haben keine Zeitpläne, oder ihr Veröffentlichungszeitplan ist so häufig, dass sie alle Funktionen enthalten, die in der Veröffentlichung bereitstehen, und alles andere abschieben, bis es fertig ist .
Ken Bloom
2
Dies ist ein besseres Beispiel für qualitativ hochwertige Software: 420.000 Zeilen und fehlerfrei: die Software, die das Space Shuttle antreibt . Wohlgemerkt, es waren enorme Kosten damit verbunden, diese Art von Qualität zu erhalten.
dodgy_coder
@dodgy_coder, ein sicheres Flugzeug zu bauen ist auch nicht billig ;-)
Karim Agha
1
@ PaulNathan anständig ist sehr subjektiv;)
James Khoury
3
@KarimA .: Ein sicheres Flugzeug zu bauen ist nicht billig, aber ein großer Teil dessen, was ein Flugzeug sicher macht, ist Software ... Ein wichtiger Teil des Flugzeugdesigns ist also das Softwaredesign!
Ehrfurcht
10

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.

Ashpool
quelle
21
Ich hörte einmal jemanden sagen: "Bauen wäre wie Programmieren, wenn das ganze Haus explodieren würde, wenn man den letzten Türknauf nach hinten auf das Haus legt."
Morgan Herlocker
9

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.

Waxwing
quelle
5
Verstehen Sie Programmierer, die nicht alle Anstrengungen unternehmen, um fehlerfreien Code zu erstellen, da dies doppelt so lange dauern würde und das Management sich gestern
Beta
4
Sollte das nicht auch für andere Branchen gelten? Ich leugne nicht, dass externe Faktoren nicht existieren, aber ich glaube, dass eine Veränderung von innen kommen muss. Wenn Softwareingenieure ihre Rolle als Experten auf ihrem Gebiet anerkennen würden, würden ihre Empfehlungen und Schätzungen respektiert und vom Management nicht nachgeprüft. Oder bin ich zu naiv?
Seidenschwanz
2
Ich bin oft überrascht, wenn ich gelegentlich einen Kunden besuche und ihm bei der Verwendung des von mir programmierten Produkts zuschaue. Es gibt Fehler und Funktionen, die die Arbeitsweise sehr erschweren, und als Programmierer sehe ich, wie einfach das für den Benutzer viel besser gemacht werden könnte, aber der Benutzer hat sich nie darüber beschwert, weil er der Meinung ist, dass es die Mühe nicht wert ist um es zu melden.
Ehrfurcht
7

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).

Festkörper
quelle
5

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."

racoonie
quelle
5

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.

Vector
quelle
4

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.

Vaibhav Garg
quelle
3

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.

joshin4colours
quelle
3
+1 auf die Unreife der Software-Entwicklung. Das Bauingenieurwesen hatte einige tausend Jahre Zeit, seine Praktiken zu entwickeln. Die Luft- und Raumfahrt hatte hundert und basiert auf anderen technischen Disziplinen. Software ist noch jung. Es ist auch normalerweise schlecht verstanden. Menschen können als Kinder Brücken über Ströme bauen oder Papierflieger bauen - das Gleiche gilt nicht wirklich für Software.
Andy Burns
3

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.

Der Herzog
quelle
3

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.

NotGaeL
quelle
Der Kölner Dom wurde 1248 gegründet und 1880 fertiggestellt. 632 Jahre.
gnasher729
3

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 .

Greg Askew
quelle
3

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.

Aadaam
quelle
Genau. Große Programme können fehlerfrei und termingerecht geliefert werden, da sie über drei Jahrzehnte hundertmal durchgeführt wurden. Zum Beispiel ein Texteditor.
Droogans
Darüber hinaus laden wir einfach das alte Programm von der Website herunter und erstellen eine Kopie. Aber aus irgendeinem Grund zählt das nicht als erfolgreiches großes Softwareprojekt.
BDSL
3

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.

GreyGeek
quelle
1
Das habe ich schon lange gesagt. Wenn Sie verklagt würden, wenn Ihre App abstürzt, wäre Code viel robuster ... Und es gibt viele Unternehmen, die ich verklagen möchte - nehmen Sie zum Beispiel MS: Wie viele Stunden gehen aufgrund all ihrer Updates und Patches verloren und Bugs und Revisionen, die andere Sachen kaputt machen. Verklage sie für diese verlorenen Stunden und die Qualität wird SCHNELL zunehmen.
Vector
In diesem Fall würden sich die Kosten erhöhen und die Funktionen verringern.
Jim G.
1
@JimG. Die Frage war nach der Zuverlässigkeit, nicht nach der Funktion oder dem Preis. Wenn Sie ein zuverlässigeres Produkt herstellen müssen, ergeben sich natürlich größere Einschränkungen für Ihren Konstruktionsbereich, und andere Aspekte (Funktionen und Kosten) können darunter leiden.
GreyGeek
4
Die Kosten für eine Boeing 737 betragen 50 bis 80 Millionen US-Dollar. Sie zahlen jedes Mal, wenn Sie in ein Büro einsteigen - zahlen Sie jedes Mal, wenn Sie ein Büro eröffnen? Wenn ich jedes Mal bezahlt würde, wenn jemand meine Software benutzt, wäre ich der Zuverlässigkeit verpflichtet.
FlavorScape
1
@ Jim G: Ich hätte lieber 1 stabile Version eines Produkts als 5 beschissene.
Giorgio
2

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.)

Rex Kerr
quelle
2

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.

zxcdw
quelle
+1, und um die Idee weiter zu führen, es ist ein Misserfolg, die Komplexität von Menschen außerhalb der Branche zu schätzen, die zu unrealistischen Erwartungen, irrationaler Politik und Design ohne Manschette führt. Der öffentliche Sektor in Großbritannien ist ein perfektes Beispiel. Bei einem öffentlichen Gebäude versucht das Management beispielsweise, das Design mit Expertenmeinung, umfassender Beratung und wasserdichter Projektplanung zu perfektionieren, bevor der Rasen geschnitten wird. Wenn Sie jedoch dieselben Personen vor ein neues IT-System stellen, werden Sie in letzter Minute Änderungen an den Anforderungen, dem DB-Schema und der Benutzeroberfläche bemerken. "Wie schwer kann es sein? Es ist nur ein bisschen Tippen"
Julia Hayward
1

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.

Droogans
quelle
Staubsauger mit Schwarzlochantrieb? Was ist mit funktionaler Sicherheit?
Peter Mortensen
Fehlende funktionale Sicherheit? Es ist ein Feature! Wir empfehlen die Verwendung unveränderlicher Strukturen, wenn Sie versuchen, etwas mit dem Schwarzloch-Staubsauger zu reinigen.
Droogans
1

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.

Jerry Coffin
quelle
1

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.

Peter Mortensen
quelle
1

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.

Muz
quelle
0

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.)

Peter A. Schneider
quelle
Ich verstehe deinen Standpunkt nicht. Erstens sind viele Sprachen ziemlich alt. Java ist mehr als zwanzig Jahre alt. Python ist fast dreißig Jahre alt. Ja, es gibt neue Sprachen, aber es ist nicht so, dass wir alle eine Sprache aufgeben, um alle zwei Jahre eine neue Sprache zu wählen. Während die Einführung eines neuen Frameworks, einer neuen IDE oder einer neuen Sprache für ein Team möglicherweise ein Faktor der Langsamkeit ist, finde ich diejenigen, die vertraute Tools verwenden, auch nicht besonders schnell. Und die Flugzeugindustrie? Flugzeuge wie die Boeing 787 haben viele neue Dinge, die schwierig zu implementieren waren.
Arseni Mourzenko
@ArseniMourzenko Nun, Java war heiß auf Web- Client- Programmierung, nachdem es herauskam, und auf GUI- Erstellung, als Swing herauskam, aber beide Moden hielten nur ein paar Jahre an. Heck, es gab kein WWW vor den neunziger Jahren. Web-Programmierung ist, wo Flugzeuge im Jahr 1910 oder so waren. Aber dieses Tempo hält an .
Peter A. Schneider
-1

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.

Fendy
quelle
-1

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?

cmcginty
quelle