- Ändernde Anforderungen und Unsicherheit, Wiederholungsarbeit und Behelfslösungen, die oft als Besonderheiten von Software gelten, kommen auch im klassischen Ingenieurwesen häufig vor; beide Bereiche haben mehr Gemeinsamkeiten als Unterschiede
- Die Unterscheidung klassisches Ingenieurwesen = Waterfall, Software = Agile ist zu stark vereinfacht. Bei physischen Produkten sind die Iterationskosten höher, daher wird mehr im Voraus entworfen, aber auch Tunnelbau, Tiefbau und Elektronik nutzen inkrementelle Entwicklung und Anpassung vor Ort
- Auch das klassische Ingenieurwesen erlebt Probleme, die Pläne über den Haufen werfen — etwa die Insolvenz eines Zulieferers, Änderungen an Fertigungsanlagen oder unerwartete Bodeneigenschaften —, daher ist es schwer zu behaupten, nur Software sei besonders unvorhersehbar
- Der tatsächliche Unterschied liegt in der hohen Konsistenz und schnellen Änderbarkeit von Software sowie in ihren vergleichsweise flexiblen Einschränkungen. Physische Produkte müssen Materialstreuung und Verschleiß sowie harte Grenzen wie Festigkeit und Größe und schwer rückgängig zu machende Änderungen verkraften
- Schnelle Korrekturen erleichtern Experimente und Validierung, können aber auch den Druck erhöhen, physische Mängel mit Code zu umgehen. Jedes Ingenieurfeld kann von den Methoden der anderen bei Entwurf, Verifikation und Automatisierung lernen
Die Verteidigungslogik hinter der Behauptung, Software sei etwas Besonderes
- Erdöllagerstätten sind keine mit Öl gefüllten Ballons, sondern poröse Gesteinsstrukturen; daher ist es bei plötzlichem Druckverlust schwer zu beurteilen, ob eine lokale Hohlstelle die Ursache ist oder ob eine Verbindung zum Meer entstanden ist
- Man injiziert kleine Haselnussschalen in die Hohlräume, füllt sie allmählich auf, gleicht den Druck aus und prüft so, ob das Problem innerhalb der Struktur liegt
- Dass Ölunternehmen in Norwegen zu den größten Käufern von Haselnussschalen gehören, zeigt, dass auch klassisches Ingenieurwesen auf unerwartete Materialien und Reaktionen vor Ort angewiesen ist
- Beim Vergleich von Software mit klassischem Ingenieurwesen wird Software wegen Unterschieden bei Zulassung oder Strenge teils niedriger bewertet, zugleich aber auch als Sondergebiet behandelt, das sich nicht im Rahmen gewöhnlichen Ingenieurwesens verstehen lasse
- Das Argument, Anforderungen änderten sich so schnell, dass man keine Vorausplanung und keine ingenieurmäßigen Methoden anwenden müsse, wirkt als Abwehrmechanismus
- Die NoEstimates-Bewegung will Schätzungen ganz abschaffen, weil Software sich im Unterschied zum klassischen Ingenieurwesen schwer schätzen lasse
- Doch die meisten Probleme, die in der Software als besonders schmerzhaft gelten, gibt es auch in anderen Ingenieurdisziplinen, und Ingenieurinnen und Ingenieure mit Erfahrung in beiden Welten sehen die Natur der Arbeit als sehr ähnlich an
Fünf häufig genannte Unterschiede
- Wenn man das gesamte klassische Ingenieurwesen wie einen einzigen Bereich behandelt oder mit dem Bauingenieurwesen gleichsetzt, verschwinden die Unterschiede zwischen den einzelnen Unterdisziplinen
- Als allgemeine Unterschiede zwischen Software und klassischem Ingenieurwesen werden oft folgende Punkte genannt
- Klassisches Ingenieurwesen passe zu Waterfall, Software zu Agile
- Klassisches Ingenieurwesen sei vorhersagbar, Software schwer vorhersagbar
- Ingenieurwesen sei überwiegend Fertigung, Code dagegen Entwurf — also sei „Code gleich Entwurf“
- Klassisches Ingenieurwesen sei strenger als Software Engineering
- Software bewege sich viel schneller als klassisches Ingenieurwesen
- Bei einigen Punkten gibt es reale Unterschiede, aber die meisten sind falsch oder es fehlt der entscheidende Kontext für eine Bewertung
Die einfache Trennung in Waterfall und Agile
- Der verbreiteten Erzählung zufolge habe Winston Royce 1970 Waterfall nach dem Vorbild von Bauprozessen geschaffen; dieses Verfahren sei wegen seiner Schwäche gegenüber geänderten Anforderungen 2001 durch das Agile Manifesto ersetzt worden
- Tatsächlich war Waterfall nie so starr oder so allgegenwärtig, wie es heute oft dargestellt wird
- In den 1970er- und 1980er-Jahren nutzten Entwicklerinnen und Entwickler verschiedenste inkrementelle Modelle wie ad hoc geplante Abläufe, das Spiral Model oder das V Model
- Agile ist eher das natürliche Ergebnis damaliger Entwicklungen als eine abrupte Revolution
- Es stimmt, dass klassisches Ingenieurwesen mehr Vorabentwurf und getrennte Testphasen nutzt, doch das liegt weniger an der Starrheit von Waterfall als an der Ökonomie der Iterationskosten
- Je mehr Zeit und Geld eine Iteration kostet, desto sinnvoller ist es, einen einzelnen Durchlauf länger zu planen
- Wenn eine Leiterplatte nicht auf Anhieb funktioniert, muss sie erneut ins Werk geschickt werden, was leicht mehrere tausend Pfund und zwei Wochen zusätzlich kosten kann
- Auch die Grenze zwischen Entwurf und Umsetzung ist nicht eindeutig
- Ein verkleinertes Modell eines Bauingenieurs oder ein Tonmodell in Originalgröße, das ein Fahrzeugingenieur baut, um Ästhetik und Aerodynamik zu prüfen, kann zugleich als Entwurf und als Umsetzung gelten
- Auch in anderen Industrien gibt es Vorgehensweisen ähnlich zu Agile
- Die Neue Österreichische Tunnelbaumethode stützt sich auf iterative Entwicklung und improvisierte Reaktion vor Ort
- Das Handbook of Industrial Engineering betont die Zusammenarbeit zwischen Abteilungen und schnelles Kundenfeedback
- Auch im Bauingenieurwesen verschiebt sich der Fokus nach Baubeginn hin zu offener Kommunikation und Anpassung, um Probleme auf der Baustelle zu lösen
Auch klassisches Ingenieurwesen ist schwer vorherzusagen
- Betrachtet man nur die fertige Brücke oder das fertige Produkt, übersieht man leicht Reibungsverluste, Budgetüberschreitungen und Verzögerungen während des Prozesses
- Schon eine um 1 Zoll falsch gesetzte Wand oder die Insolvenz eines zentralen Zulieferers kann den ganzen Plan ins Wanken bringen
- In der Software wirkt es oft so, als wechselten dominante Frameworks oder Sprachen alle ein bis zwei Jahre, aber auch das klassische Ingenieurwesen erlebt Veränderungen bei Werkzeugen und Produktionsumgebungen
- Führt eine Halbleiter-Foundry neue Fertigungsanlagen ein, ändern sich auch die Pläne für Chipdesigns
- Das geschieht nicht so schnell wie bei Libraries, heißt aber nicht, dass es keine Veränderungen gibt
- Auch Eigentumsverhältnisse können sich während eines Bauprojekts ändern, etablierte Verfahren können plötzlich dauerhaft versagen, oder neue Fakten tauchen erst spät in der Entwicklung auf
- Wenn sich erst nach Beginn der Fundamentarbeiten für eine Brücke herausstellt, dass ein bestimmter Boden anders gefriert als erwartet und bei Erdbeben übermäßig verflüssigt wird, muss man beim Entwurf wieder ganz von vorn anfangen
- Die Vorstellung, nur Software sei besonders unvorhersehbar, entsteht oft daraus, dass man die tatsächlichen Arbeitsabläufe anderer Ingenieurdisziplinen nicht sieht
Die Behauptung „Code ist gleich Entwurf“
- „Code ist gleich Entwurf“ war eine Gegenreaktion auf die Vorstellung, man müsse nur mit UML ein perfektes Modell erstellen und könne daraus automatisch Code generieren
- Nick Coghlan, Kernentwickler von CPython und früherer Systemintegrationsingenieur bei Boeing, sieht darin einen grundlegenden Unterschied zwischen Software und seiner früheren Arbeit
- Er koordinierte unabhängige Systemteams etwa für Flugzeuge, Flugsicherung und Antennenarrays, damit sie kompatible Schnittstellen schaffen
- Für Halbleiteringenieure ist der gesamte Weg vom ersten CPU-Schaltplan bis zum fertigen Chip aus der Foundry ein Entwurfsprozess; die Fertigung kann im Vergleich ein relativ einfacher Schritt sein, bei dem man das Design abgibt und Chips zurückbekommt
- Haben fertige Chips oder mechanische Produkte Fehler, muss der Entwurf geändert werden; Entwurf und Herstellung sind also nicht wirklich getrennt
- „Fettling“ im Maschinenbau bezeichnet die Anpassung des Entwurfs an kleine Unvollkommenheiten im Fertigungsprozess
- So entsteht ein Kreislauf, in dem die Fertigung den Entwurf verändert und der geänderte Entwurf wiederum die Fertigung verändert
- Schon der Umfang von Entwurf ist unscharf
- Architekturübersicht, formale Spezifikation und Detailzeichnung sind allesamt verschiedene Ebenen von Entwurf
- In komplexen Projekten wie einem Brückenplan gibt es viele Detailebenen, die sich wiederholt überlagern
- Dass der Bau die meiste Zeit und das meiste Geld verschlingt, trifft nur auf Teile des Bauingenieurwesens zu, die sich auf Brücken und Gebäude konzentrieren; das lässt sich nicht als Bild für das gesamte klassische Ingenieurwesen verallgemeinern
- Auch das Bauingenieurwesen umfasst viele verschiedene Bereiche, die für den Bau von Städten nötig sind, und lässt sich nicht auf Brücken und Gebäude reduzieren
Missverständnisse über Strenge
- Die Trennung, klassisches Ingenieurwesen leite sorgfältig aus ersten Prinzipien her, während Software auf Copy-and-paste beruhe, bildet die reale Arbeit nicht ab
- Die scheinbar geringere Strenge von Software ist nicht nur eine Kulturfrage, sondern kann ein vernünftiger Kompromiss sein, der aus den materiellen Eigenschaften folgt: Umsetzung und Test sind leichter
- Oft ist der einfachste Weg, Annahmen zu prüfen, etwas direkt zu implementieren und auszuführen
- Schon das schnelle Sammeln empirischer Informationen ist eine strenge Form der Validierung
- Auch die Annahme, Produkte des klassischen Ingenieurwesens seien konsistenter und systematischer als Software, stimmt nicht
- Bei Dokumentationserhalt und umfassender Verifikation liegt Software mitunter sogar vorn
- In vielen Bereichen des klassischen Ingenieurwesens liegen zentrale Informationen in Excel-Dateien oder alten Aktenschränken und altern oder gehen kaputt
- Viele Ingenieurinnen und Ingenieure in traditionellen Disziplinen würden gern automatisierte Tests einführen, die in der Software selbstverständlich sind
- Selbst bei physischen Bauwerken werden weiterhin Behelfslösungen eingesetzt, etwa indem man bei Bedarf zusätzliche Halterungen anbringt
Tatsächlicher Unterschied 1: Konsistenz
- Software wird vollständig aus Logik synthetisiert und verschleißt nicht wie eine Feder; deshalb ist sie viel konsistenter als die Ergebnisse anderer Ingenieurdisziplinen
- Wenn eine Sortierfunktion eine Liste von Zahlen bei nicht fehlerhaften Eingaben nur in 95 % der Fälle sortiert, ist das schwer als normales Verhalten zu akzeptieren
- Bei physischen Materialien und Bauteilen gehören Abweichungen vom Sollwert grundsätzlich dazu
- Widerstände gibt es von 1Ω bis zu hunderten Millionen Ω; ihre Farbringe stehen für einen theoretischen Widerstandswert
- Grün, Blau und Rot bedeuten 5.600Ω, doch mit einem goldenen Toleranzring kann der tatsächliche Wert um bis zu 5 % abweichen
- Von 100 gleichen Widerständen können einige 5.320Ω und andere 5.880Ω haben, weshalb man jeden einzeln messen muss
- Berücksichtigt man zusätzlich Verschleiß und Temperaturschwankungen, werden die Abweichungen noch komplexer
- Ähnliche Probleme gibt es bei allen physischen Materialien; selbst der Schraubenhersteller Fastenal warnt davor, Edelstahlschrauben nicht in Aluminiumplatten zu verwenden
Tatsächlicher Unterschied 2: Geschwindigkeit von Änderungen
- Software lässt sich viel schneller ändern als andere technische Systeme
- Im klassischen Ingenieurwesen muss man nach dem Teilen der Spezifikation auf Fertigung und Einbau im Werk oder in der Maschinenwerkstatt sowie auf wochenlange Tests warten
- Bei manchen technischen Änderungen ist der Preis pro Änderung klar beziffert, etwa 5.000 Dollar pro Schritt aus dem Budget
- Code kann nach einer Änderung innerhalb von Sekunden mit der gesamten Test-Suite ausgeführt werden
- Unter den nicht softwarebezogenen Disziplinen kam die Chemietechnik diesem Tempo am nächsten, doch selbst dort sind Umstellungen im Minutentakt kaum vorstellbar
- Dass andere Ingenieurdisziplinen Entwurfswerkzeuge und Simulationen immer stärker in Software verlagern, liegt ebenfalls daran, dass sich Ideen vor der Umsetzung schnell prototypisieren lassen
- Die Fähigkeit zu schnellen Änderungen hat auch eine negative Seite
- Wenn Probleme in elektronischen oder mechanischen Geräten nicht vollständig gelöst werden, konzentriert sich der Druck oft auf Softwareingenieurinnen und -ingenieure, das Ganze mit Code-Workarounds auszugleichen
- Diese Abhängigkeit kann fatale Folgen haben
- Bei den beiden Abstürzen der Boeing 737 MAX im Jahr 2019 starben mehr als 300 Menschen
- Die Untersuchung nannte einen Bug im automatischen Flugkontrollsystem MCAS als Ursache
- Boeing ergänzte MCAS, statt ein spät erkanntes Problem der aerodynamischen Eigenschaften durch eine physische Designänderung zu beheben
Tatsächlicher Unterschied 3: Einschränkungen und irreversible Änderungen
- Produkte des klassischen Ingenieurwesens haben physische Grenzen, die unbedingt eingehalten werden müssen — etwa bei Gewicht, Festigkeit, Widerstand oder Temperatur
- Beim Chipdesign kann sogar um Zeitreserven im Bereich von Bruchteilen einer Nanosekunde mit anderen Teams verhandelt werden
- Auch in Software gibt es Einschränkungen wie Speichergröße, 10-Zyklen-Reaktion eines Sensors oder API-Call-Limits
- Doch Software-Einschränkungen sind oft weiche Grenzen, bei denen sich der Zustand mit zunehmender Überschreitung verschlechtert, sodass man sie zugunsten von Entwicklungsgeschwindigkeit oder einfacheren Algorithmen etwas verschieben kann
- Im klassischen Ingenieurwesen sind es oft harte Grenzen, bei deren Überschreitung das Produkt schlicht nicht funktioniert
- Ist eine Kiste auch nur ein wenig zu breit, passt sie nicht durch die Tür
- In einem Fall war eine für eine Ölbohranlage bestimmte Förderschnecke einige Zoll höher als der Raum, in den sie eingebaut werden sollte; man konnte das Gerät nicht verkleinern und die Decke wegen der vier Stockwerke darüber auch nicht anheben
- Also schnitt man ein Loch in die Decke, setzte das Gerät ein und baute um das Loch herum einen Kasten, damit oben niemand hineintritt
- Diese Änderung bleibt dauerhaft Teil der Struktur und muss bei jeder späteren Änderung weiter berücksichtigt werden
- Softwareingenieurinnen und -ingenieure können Behelfslösungen oft wieder entfernen; physische Behelfslösungen im klassischen Ingenieurwesen werden dagegen leicht zu dauerhaften Strukturen
Anders, aber nicht besonders
- Software hat eigene Sicherheitsprobleme, aber wie das Bauingenieurwesen mit Wetter und die Chemietechnik mit chemischen Eigenschaften zu kämpfen hat, hat jede Disziplin ihre eigenen Schwierigkeiten
- Alle Ingenieurdisziplinen schätzen abstraktes Denken im Voraus, geordnete Arbeit und angemessene Behelfslösungen und stehen vor wechselnden Anforderungen und unbekannten Unbekannten
- Die einzelnen Disziplinen sind voneinander isoliert; so wie Softwareingenieurinnen und -ingenieure wenig über Maschinenbau wissen, kennen auch Chemieingenieurinnen und -ingenieure die reale Arbeit anderer Ingenieurfelder oft kaum
- Gerade weil Software nicht etwas Besonderes ist, kann sie von Verbesserungsmethoden anderer Ingenieurdisziplinen lernen; umgekehrt kann klassisches Ingenieurwesen von Software bei Dokumentation, Verifikation und Automatisierung lernen
- Der Folgeartikel What Engineering Can Teach Us and Learn From Us behandelt konkrete Lektionen, die beide Seiten austauschen können
1 Kommentare
Lobste.rs-Meinungen
Ich stimme großen Teilen des Textes zu, aber er ist hinsichtlich der Strenge des Software Engineering übermäßig optimistisch. Noch immer ist es keineswegs selbstverständlich, dass automatisierte Tests, insbesondere robuste Tests über mehrere Ebenen hinweg, Teil des Entwicklungsprozesses sind; manche betrachten die Entwickler selbst als einzige Kontrollinstanz, oder Organisationen behandeln Prozesse als Hindernisse und schaffen sie ab
Die Branche erfindet alle paar Jahre das Rad neu, ohne bewährte Best Practices systematisch zu verankern. Selbst Standardisiertes ist meist nur ein loser gemeinsamer Wortschatz, der von Unternehmen zu Unternehmen stark Unterschiedliches bedeutet; „Agile“ und „Tests“ sind typische Beispiele. Viele Entwickler denken bei Tests nur an Unit-Tests, manche schließen auch Komponenten- und Integrationstests ein, aber in manchen Unternehmen wird nach genau diesen Schritten bereits in die Produktionsumgebung deployt
Wie ich in einem früheren Kommentar schrieb, sollte Code-Review in einer gesunden Organisation nur einer von mehreren Prozessen sein, die für Qualität verantwortlich sind, und nicht das einzige Nadelöhr, das über ein Deployment in Produktion entscheidet. Es gibt viele Teams und Unternehmen, in denen Qualitätssicherungsprozesse nach dem Merge praktisch verschwunden sind
Es geht nicht darum, Verantwortung zu verwässern, sondern darum, Qualität in den Prozess einzubetten, noch bevor Code geschrieben wird. Dazu gehören Three-Amigos-Sessions, in denen mehrere Rollen Spezifikationen und Anforderungen besprechen, testgetriebene Entwicklung, statische Analyse, integriert in die IDE und in jede Kontrollstufe, sowie Qualitätssicherungs- und Testautomatisierungsexperten, die nicht mit den Entwicklern identisch sind
Im Bauingenieurwesen ist nicht eine einzelne Person zugleich Entwerfer, Ausführender und allein Verantwortlicher für eine Brücke. Es gibt mehrere Stufen wie Berechnungen und Dokumentation, Gegenprüfung, behördliche Genehmigung, Audits und Inspektionen während der Bauausführung; selbst ein Einfamilienhaus durchläuft Pläne, Genehmigungen, Erlaubnisse und Inspektionen. Auch technische Katastrophen sind oft das Versagen eines Gesamtprozesses, der an mehreren Stellen nichts verhindert hat
Wenn man Softwareentwicklung mit Bauingenieurwesen vergleichen will, muss man auch anerkennen, dass das Prozessniveau überhaupt nicht gleich ist. Im besten Fall kommt es oft eher einem Wohnungsentwickler nahe, der das billigste Haus baut und dabei gesetzliche Anforderungen umgeht
Deshalb liegt der Kompromisspunkt zwischen Kosten und Wirkung von Tests und Verifikation bei allgemeiner Software zwangsläufig anders als im Bauingenieurwesen, sofern es nicht um Bereiche wie MRI-Steuersoftware geht
Alle drei Texte sind hervorragend, ich kann die Lektüre nur empfehlen. Dazu kann man auch frühere Diskussionen ansehen
https://lobste.rs/s/fv8swh/crossover_project (Projektankündigung)
https://lobste.rs/s/lmvroa/are_we_really_engineers (erneute Diskussion)
https://lobste.rs/s/8j8sdc/are_we_really_engineers (noch eine erneute Diskussion)
Auch dieser Vortrag von Glenn Vanderburg ist sehr relevant
Der größte Unterschied zwischen Softwareentwicklung und klassischem Ingenieurwesen ist die Reibung bei Änderungen. Software lässt sich relativ günstig ändern und ist flexibel, was völlig neue Möglichkeiten eröffnet
Auch klassisches Ingenieurwesen kann die Änderbarkeit innerhalb physikalischer und chemischer Grenzen softwareähnlich erweitern, je mehr Simulationen erstellt werden
Die Aussage „Von einer Sortierfunktion erwartet man nicht, dass sie eine nichtpathologische Zahlenliste nur mit 95% Wahrscheinlichkeit sortiert“ trifft inzwischen auf LLM-generierten Code tatsächlich zu. Meistens funktioniert er, aber eben nicht immer
~hwayne: Ich frage mich, warum er seinen Account deaktiviert hat