Warum sind die meisten Programmierer schlechte Bugfixer?
-
DEvent schrieb:
Wieso ist Software so zerbrechlich, im Vergleich zu, z.B. Brücken? Wenn man eine Brücke baut, kennt man alle Variablen im Voraus und sind recht begrenzt
So ein Bullshit: http://www.youtube.com/watch?v=3mclp9QmCGs Nein, es ist kein Resonanzphaenomen. Bei der Millennium Bridge gab es auch Problem (wohl aber nicht die gleichen). Warum stuerzt wohl die Golden Gate Bridge nicht ein? Die Ingenieure hatten vielleicht selbst keine Ahnung, haben aber acht Mal soviel Baumaterial genommen.
Warum sollte die Auffindung bestmöglicher Techniken in der Softwareentwicklung binnen 60 Jahren abgeschlossen sein
War sie doch schon bei der Geburt, als Lisp 1960 erschienen ist.
-
zum Beispiel schrieb:
Korrektur:
ich meine mit "überkomplex" natürlich nicht alle heutigen OS, sondern z.B. Desktop-Systeme mit Binärgrößen in GBytes. Kleine OS und solche für embedded systems usw sind natürlich allgemein nicht überkomplex.
Auch eine Applikation ist über-komplex. Eine Brücke muss nur ein Feature haben: Es muss X Autos/Stunde aushalten. Zählt mal auf, was ein Browser machen muss. a) html, b) css, c) javascript, d) flash, e) java, f) silverlight, g) tabs, h) menu, ...
Bei einer Brücke kann man auch auf die Gesetze der Physik vertrauen. Bei Software kann man auf nichts vertrauen, weder auf die Umgebung noch auf den Input. Eine Brücke ist einfach, mach sie richtig oder sie fällt um. Bei einer Software werden die Bugs manchmal erst nach Jahren entdeckt.
Aber wir haben einen Vorteil: Wir können das Design jederzeit ändern und innerhalb Sekunden (bei C++ dauert es wohl eher Minuten) haben wir ein neues Produkt, dass wir durch testen und dem Kunden überreichen können. Wenn eine Brücke falsch gebaut wurde, dann dauert es erst Jahre bis eine bessere errichtet ist. Auch kann man keine echten Brücken testen, sondern nur Modelle.
Interessant dazu ist das Video
http://www.rheinjug.de/videos/gse.lectures.app/Player.html
Emergent Design & Evolutionary Architecture Autor: Neal Ford - 21.09.2009
-
Eine Brücke muss nur ein Feature haben: Es muss X Autos/Stunde aushalten .. Eine Brücke ist einfach
Hoer einfach auf zu labern. Du hast keine Ahnung von Brueckenbau.
Ein hauptsaechlicher Unterschied ist, dass beim Brueckenbau Menschenleben auf dem Spiel stehen und deswegen auch sorgfaelltiger gearbeitet wird.
-
Die meisten Brücken werden doch nach "Schema F" gebaut. Und es gibt Brückenarchitekturen die sich bewährt haben (z.B. Hängebrücke). Und diese Brückenarchitekturen werden immer wieder benutzt, mit anderen Parametern (Länge, Höhe usw.). Und dann wird gebaut. Bei Software sieht das doch anders aus: es wird immer wieder neu entwickelt, und nicht einfach nur ein Parameter geändert.
Brücken die nicht nach Schema F gebaut werden, sind doch eher selten. Software die nach Schema F gebaut wird ist eher die Ausnahme.
Solange wir jede Software immer wieder neu entwickeln, werden wir auch immer neue Fehler haben. Würde jede Brücke neu entwickelt werden, und jeder Architekt meinen sich selbstverwirklichen zu müssen, würde wohl auch jede Brücke Fehler haben.
-
Die Tacoma-Bruecke sah fuer mich auch nach einem Standardmodell aus, also fuer mich als Laien.
Und dann wird gebaut. Bei Software sieht das doch anders aus: es wird immer wieder neu entwickelt, und nicht einfach nur ein Parameter geändert.
Ach, und die ganzen Designpattern und so benutzt eh keiner. Bibliotheken? Nie davon gehoert. Softwarearchitektur ist bestimmt nur was fuer Frickler. Ingenieure haben ihre formalen Methoden, genauso wie die Softwareentwicklung.
-
Der hier oft zitierte Vergleich mit Brücken belustigt mich als Bauingenieur und hat dennoch gewisse Analogien zur Software-Entwicklung.
Die Tacoma-Bridge (Hängebrücke) ist durch windverursachte Eigenschwingungen (Torsion) eingestürzt. Dieser Möglichkeit hatte man beim Entwurf keine Aufmerksamkeit gewidmet.Fazit: Brücken und Software sind oft komplexe Systeme. Vernachlässigt man etwas, so gibt es Bugs oder den Crash.
-
Man sollte das auch beim Brückenbau nicht unterschätzen, daß da am Tag X jede Niete da sein muß mit dem Monteur, der sich am richtigen Ort montiert. Bzw. sinngemäß.
Die Komplexität liegt hier in der Ablaufplanung um die Idee in die Realität umzusetzen und jedes Bit (==Niete) korrekt zu setzen.
Ich bin zwar kein Brückenbauer, befasse mich aber mit Fabrikplanung, wo die Softwaretechnik nur einen Teil ausmacht, in dem Gesamtplan muß am Ende des Tages der letzte Feuerlöscher montiert sein und die Maschine am richtigen Platz stehen. Da gibt es Race Conditions (bestimmte Dinge sind zu früh oder zu spät da), Deadlocks (gegenseitiges Warten auf bestimmte Resourcen oder Platzprobleme), und obwohl das Design richtig ist, simuliert wurde, und viele Leute geprüft haben (FMEA, Sicherheitsanalysen, etc), wimmelte es in der Ablaufplanung von Schwierigkeiten.
Das liegt daran, weil bei aller Planung (unter Zeitdruck) es irgendwann nicht mehr möglich ist alle Details "offline" zu durchdenken. Man kann nicht beliebig in die Tiefe denken, für ein Gewerk vielleicht, aber für alle? Das kann einer nicht leisten, es gibt dann die unterschiedlichen Vorstellungen der Entwickler, und auch die Kunden wissen nicht wirklich, wie die Details sein sollen, weil sie es auch nur bruchstückhaft überblicken. Dazu kommen Lieferanten (entspricht den fertigen Komponenten von Libs und OS), die einem nur eine Blackbox nach Spezifikation (design by contract) liefern, aber man kann nicht in deren Eingeweide blicken.
Und es ist auch so, daß die Verbesserung und Detailierung von Spezifikationen die Kosten erhöht, die Planungszeit verlängert, aber eben nicht wesentlich zu einer Verbesserung beim Rollout führt, weil die Knackpunkte nur "fraktaler" vorhanden sind.
Um Abläufe weiter zu beschleunigen, setzt man auch da zu anderen Ansätzen wie simultaneous engineering, was man sich teilweise auch mal boshaft so vorstellen kann: man baut die Wand, und schlägt die Löcher dann passend rein. Wer sich hier an eXtreme Programming erinnert fühlt liegt nicht so falsch...
Es ist die Komplexität in der Tiefe und Breite, die eine Fehlerfreiheit verhindert. Der Unterschied zur Software ist, daß man die Bugs beim Laufen in der Fabrikhalle sieht, und demnach leichter identifizieren kann.
Software hat den Nachteil, daß man nicht so leicht reinschauen kann (und viele Entwickler das sogar auch zu ihrem Vorteil ausnutzen), so daß ein Bugfixer natürlich gewisse "detektivische Fähigkeiten" mitbringen muß.
-
Marc++us schrieb:
Man sollte das auch beim Brückenbau nicht unterschätzen, daß da am Tag X jede Niete da sein muß mit dem Monteur, der sich am richtigen Ort montiert. Bzw. sinngemäß.
Die Komplexität liegt hier in der Ablaufplanung um die Idee in die Realität umzusetzen und jedes Bit (==Niete) korrekt zu setzen.Nicht die Niete und nicht das Niet.
Vor 50 wurde die letze Brücke genietet, oder?Marc++us schrieb:
Und es ist auch so, daß die Verbesserung und Detailierung von Spezifikationen die Kosten erhöht, die Planungszeit verlängert, aber eben nicht wesentlich zu einer Verbesserung beim Rollout führt, weil die Knackpunkte nur "fraktaler" vorhanden sind.
Deswegen arbeiten wir in der Softwaretechnick auch mit Nieten.
-
Stellt sich DEvent blöd oder ist der wirklich so dumm?
-
berniebutt schrieb:
Der hier oft zitierte Vergleich mit Brücken belustigt mich als Bauingenieur und hat dennoch gewisse Analogien zur Software-Entwicklung.
Die Tacoma-Bridge (Hängebrücke) ist durch windverursachte Eigenschwingungen (Torsion) eingestürzt. Dieser Möglichkeit hatte man beim Entwurf keine Aufmerksamkeit gewidmet.Das kenn ich. Bei uns in der nähe wurde vor einigen Jahren eine Fußgängerbrücke gebaut. Sie wurde so konzipiert, dass sie selbst dann noch stabil ist, wenn die ganze Brücke gerammelt voll mit Fußgängern ist.
Trotzdem musste die Brücke im Nachhinein verstärkt werden. Es wurde einfach nicht daran gedacht, dass wenn viele Menschen hintereinander gehen, sie fast unweigerlich in den Gänsemarsch übergehen. Das simultane Auftreten von hunderten von Füßen war dann doch zu viel und die Brücke kam ins schwanken
-
Denkt aber daran, daß Ihr bei dem Vergleich mit der Brücke eine wichtige Sache vergesst: die Berechnung der Statik entspricht so ungefähr dem Programmdesign mit UML und der Erstellung von ein paar ER-Diagrammen. Wir alle wissen aber, daß das noch kein Programm ist.
DER BAU der Brücke ist die Codierung... der Baggerm der Erde wegschiebt, der Betonmischer, der um 11:15 anfährt, damit das kontinuierliche Gießverfahren nicht stockt, etc, das müßt Ihr einbeziehen in den Vergleich. Und da wimmelt es auch von Bugs im Ablauf.
-
Ich denke dass der Vergleich besser funktionieren würde, wenn man den Bau von Gebäuden statt von Brücken nimmt.
Sowohl Gebäude als auch Programme gibt es in verschiedensten Grössen und Komplexitätsstufen.Und bei grossen komplexen Gebäuden bzw. Gebäudekomplexen spielen auch viel mehr verschiedene Dinge mit rein als bei Brücken. Sowohl in der Planung als auch in der Ausführung.
Bzw. bei einer einfachen Gartenhütte reicht es wenn man ein paar Bretter nimmt und zusammennagelt.
-
Marc++us schrieb:
DER BAU der Brücke ist die Codierung... der Baggerm der Erde wegschiebt, der Betonmischer, der um 11:15 anfährt, damit das kontinuierliche Gießverfahren nicht stockt, etc, das müßt Ihr einbeziehen in den Vergleich. Und da wimmelt es auch von Bugs im Ablauf.
Das denke ich nicht. Codierung ist Design, der Bau einer Brücke ist das Übersetzen des Designs in ein Produkt, auch Kompilierung genannt.
Normalerweise ist Source Code kein Produkt, weil Source Code alleine ist nicht lauffähig. Gerade C++ Programmierer müssen das wissen. Auch Java wird kompiliert, ebenso wird Python auch vor-kompiliert. Das Produkt ist der in Maschinensprache (oder VM Sprache oder Systemsprache) übersetzte Source Code, alle Abhängigkeiten, die benötigte Konfiguration und die Dokumentation.
Ein Architekt plant auch Monate voraus, es wird nicht einfach ein Bagger bestellt und los geht es mit dem Bau. Aber ich denke, dass die Planung und das Design dauern genauso lang wie der Bau (oder der Bau dauert länger). Deswegen kann ein Architekt nicht einfach das Design mitten im Projekt ändern oder er kann nicht viele Möglichen Bauten oder Brücken durch testen. Beim Programmieren ist die Hauptaufgabe das Design, die Planung. Die Herstellung dauert im Idealfall nur Minuten und deswegen können wir das Produkt sehr oft testen. Wir können auch das Design ändern und anpassen.
-
DEvent schrieb:
Beim Programmieren ist die Hauptaufgabe das Design, die Planung. Die Herstellung dauert im Idealfall nur Minuten und deswegen können wir das Produkt sehr oft testen. Wir können auch das Design ändern und anpassen.
das klingt aber schwer nach nem einzeiler, aber den muß ich auch nicht designen/planen oder etwa doch
btw. bei der software die ich so kenne wurden schon ein paar bildchen gemalt usw. aber das meißte passiert doch on the fly beim programmieren, oder wurden für linux oder eine andere software uml-diagramme gezeichnet
der vergleich wäre evtl. du hast ein haus, das ist etwas älter, soll ja doch mal vorkommen, dieses ding hat einen kamin und soll nun eine hoch moderne zentral heizung verpasst kriegen. das der architekt das vor 100 jahren noch nicht eingeplant hat sollte ja klar sein... und das dafür der ganze putz runter muß auch oder...
aber software, ja da sollte am besten deine steinzeithütte träger für solar-panels mitbringen
lg lolo
-
Eine gewisse Planung ist immer notwendig. Schaut euch Schach an. Wenn man "einfach so" spielt, dann gewinnt man in den seltensten Fällen.
-
... schrieb:
Eine gewisse Planung ist immer notwendig. Schaut euch Schach an. Wenn man "einfach so" spielt, dann gewinnt man in den seltensten Fällen.
nun ja, also ich plan kein schach, sondern versuch eigentlich möglichst wenig fehler zu machen -> möglichst wenig stellen übrig zu lassen die gefährlich werden können. aber ich bin auch ein mieserabler schach spieler
auch beim schach ist noch kein meister vom himmel gefallen...
lg lolo
-
Bzw. bei einer einfachen Gartenhütte reicht es wenn man ein paar Bretter nimmt und zusammennagelt.
Dann haben wir in der Softwarewelt aber viele Gartenhuetten von der Groesse des Empire State Buildings.
-
DEvent schrieb:
Das denke ich nicht. Codierung ist Design, der Bau einer Brücke ist das Übersetzen des Designs in ein Produkt, auch Kompilierung genannt.
Alle Analogien haben ihre Grenzen... Du hast sie jetzt erreicht.
Aber das zu erklären würde zu weit führen, ich bin mir auch nicht ganz sicher ob es sich lohnt.
-
knivil schrieb:
Bzw. bei einer einfachen Gartenhütte reicht es wenn man ein paar Bretter nimmt und zusammennagelt.
Dann haben wir in der Softwarewelt aber viele Gartenhuetten von der Groesse des Empire State Buildings.
Es ist übrigens außerordentlich erheiternd, mit Softwareentwicklern Jenga zu spielen.
-
Marc++us schrieb:
Alle Analogien haben ihre Grenzen... Du hast sie jetzt erreicht.
Aber das zu erklären würde zu weit führen, ich bin mir auch nicht ganz sicher ob es sich lohnt.
ES LOHNT SICH NICHT!
