Warum sind die meisten Programmierer schlechte Bugfixer?
-
zum Beispiel schrieb:
Andererseits mußte man vor 40, 50 Jahren typischerweise mit ungleich schwächerer Hardware auskommen, was den Programmierern enormes Effizienz-Denken und allerlei Tricks zur Reduzierung von Speicher- und Zeitbedarf abverlangte - wenn zur Implementation beispielsweise nur 8 K oder 38 K RAM zur Verfügung standen. Ziemlich anspruchsvoll, wenn man damit und mit 5 oder 10 MHz Takt auskommen mußte, um ein komplettes Mehrbenutzer-Betriebssystem zu implementieren.
Meinst du das jetzt als Beispiel, dass die Programmierer von damals besser waren? Wenn man so effiziente Programme schreiben muss, heißt das meist, dass man oft tricksen muss. Man muss also ein effizientes Design haben, kein gutes. Ein gutes Design ist robust, erweiterbar, testbar; ein effizientes Design ist getrimmt auf niedrigen Speicherverbrauch und Schnelligkeit.
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. Da gibt es Wetter, Regen, Wind, Erdbeben, Hitze, Kälte. Alles wird von der mechanischen Physik recht eindeutig beschrieben und jede Brücke hat die gleichen Variablen, die der Architekt beachten muss. Dazu ist der Wertebereich ebenfalls konstant. Die Umgebungstemperatur fluktuiert nicht von -1^32 auf 1^32 Grad, die Erdanziehung ändert sich nicht und die Windstärke bleibst auch recht konstant, weil alle Brücken auf der Erde gebaut werden.
Wie ist es mit Software? Eine Software kann unendlich viele Variationen des Inputs ausgesetzt sein; ebenso variiert die Umgebung mit jedem Benutzer und der eingesetzten Hardware. Kein Softwareentwickler kann alles Input einer Software vorhersagen oder dagegen Testen. Deswegen ist Software ein lebendes Produkt, dass sich ständig selbst verbessert. Eine Brücke ist einmal hingestellt und wird für Jahrzehnte nicht mehr verändert. Eine Software ist nie fertig, die Anforderungen ändern sich, Bugs werden behoben, die Umgebung ändert sich, usw.
Dazu kommt, dass Softwareentwicklung sehr neu ist. Es wird zwar von uns erwartet, dass wir die gleiche Qualität wie ein Architekt liefern, aber es wird vergessen, dass wir nur auf ca. 60 Jahre Erfahrung zurückgreifen können wogegen der Architekt auf ca. 6000 Jahre zurückgreifen kann.
-
-
DEvent schrieb:
Es wird zwar von uns erwartet, dass wir die gleiche Qualität wie ein Architekt liefern, aber es wird vergessen, dass wir nur auf ca. 60 Jahre Erfahrung zurückgreifen können wogegen der Architekt auf ca. 6000 Jahre zurückgreifen kann.
Hier die Beta 3:
-
DEvent schrieb:
Meinst du das jetzt als Beispiel, dass die Programmierer von damals besser waren? Wenn man so effiziente Programme schreiben muss, heißt das meist, dass man oft tricksen muss. Man muss also ein effizientes Design haben, kein gutes.
"effizient" ist ja nicht das Gegenteil von "gut".
Eher im Gegenteil: um ein effizientes Design herzustellen, muß man das
Problem sehr gut verstanden haben, das führt oftmals früher oder später
von selbst zu einem guten Design.DEvent schrieb:
Ein gutes Design ist robust, erweiterbar, testbar;
ein gutes Design ist in der Regel zunächst mal einfach. Daraus folgt oft schon alles Andere.
Wenn nicht - klar: schwierige Probleme können nicht immer nur einfache Lösungen haben - muß man gut abwägen, ob die zusätzliche Beschreibungs-Komplexität den Vorteil an Effizienz wirklich wert ist. Denn:
1. Komplexität kostet, auch zur Entwicklungszeit
2. Entwicklungszeit ist gewöhnlich teurer als LaufzeitDEvent schrieb:
Wieso ist Software so zerbrechlich, im Vergleich zu, z.B. Brücken?
weil man für Brücken einen einzelnen, gut erprobten, Kalkül (Newtonsche Mechanik => Differentialgleichungen) kennt, den man seit Jahrhunderten erfolgreich zur Berechnung und Beschreibung einsetzt.
DEvent schrieb:
Wie ist es mit Software?
da fehlt so ein einheitlicher, überschaubarer, seit Jahrhunderten erprobter Kalkül. Die OOP zielt in diese Richtung.
DEvent schrieb:
Eine Brücke ist einmal hingestellt und wird für Jahrzehnte nicht mehr verändert. Eine Software ist nie fertig, die Anforderungen ändern sich, Bugs werden behoben, die Umgebung ändert sich, usw.
das kommt erschwerend hinzu.
Umso wichtiger, daß man Programmiersprachen einsetzt, die dynamische Änderungen einfach machen.
DEvent schrieb:
Dazu kommt, dass Softwareentwicklung sehr neu ist.
sehe ich auch so.
-
@DEvent
Architekten bauen keine Brücken. Die Leute, die so etwas machen sind Bauingenieure.
Mit rund 60 Jahren ist die Softwareentwicklung nicht neu. Man hat genug Erfahrung zur Entwicklung stabiler und wartbarer Programme. Das kostet nur etwas mehr Sorgfalt und ein wenig mehr Zeit bei der Planung und der Realisierung.
Marktlücke? Nein! Wenn ein Programm knallt, dann stimmt gewöhnlich gar nichts. Machen kann man da schon vieles, nur machen möchte ich das nicht wirklich! :p
-
berniebutt schrieb:
Mit rund 60 Jahren ist die Softwareentwicklung nicht neu. Man hat genug Erfahrung zur Entwicklung stabiler und wartbarer Programme.
Welchen Grund hat dann die allmonatliche Flut an Patches und Bugfixes für Betriebssysteme, Viewer, Plugins, ... ?
Softwareentwicklung ist - an kulturhistorischen Zeitmaßstäben gemessen - neuer als neu.
Im Ggs etwa zur elementaren Geometrie, die ist über 2000 Jahre alt, oder zur elementaren Arithmetik, die dürfte wohl über 5000 Jahre alt sein. Das sind bestens erprobte Kalküle und Techniken mit einem angemessenen, praxistauglichen Metasystem.
Als sich die Arithmetik noch in der Entwicklung befand - also in der Steinzeit bis zum Mittelalter - gab es auch hier verschiedene Beschreibungssysteme (Dezimalsystem, Zwölfersystem, Knoten, Fingerrechnen, Abakus, ...), von denen sich dann innerhalb von Tausenden (!) von Jahren die heute gültige Arithmetik mit Dezimalsystem und + - / * durchgesetzt hat.
Warum sollte die Auffindung bestmöglicher Techniken in der Softwareentwicklung binnen 60 Jahren abgeschlossen sein, wo andere Kulturtechniken dafür Jahrtausende brauchten ?
-
DEvent schrieb:
Ein gutes Design ist robust, erweiterbar, testbar;
Warum erweiterbar? Das kostet durchaus Zeit, und ist je nach Aufgabenstellung gar nicht immer notwendig.
DEvent schrieb:
Wieso ist Software so zerbrechlich, im Vergleich zu, z.B. Brücken?
Wir dürfen auch nicht vergessen: Software ist digital. Eine Brücke ist analog. Wenn man irgendeine Kraft oder einen Durchmesser ausgerechnet hat, der soll 25,8cm sein, ist der nun in Realität 25,4, wird die Brücke nicht einstürzen. Viele Dinge sind linear, d.h. eine kleine Abweichung führt zu entsprechenden kleinen Abweichungen.
Bei Software steht da if (a==25.4) - 25.3 ist bereits falsch, das if greift nicht. Das macht viel aus.
-
Durchaus interessant zu erfahren, dass Brücken heute noch so konstruiert und gebaut werden wie vor 6000 Jahren. Naja, Hauptsache die Brücke hält den drüberhumpelnden Vergleich aus...
Marc++us schrieb:
Wir dürfen auch nicht vergessen: Software ist digital. Eine Brücke ist analog. Wenn man irgendeine Kraft oder einen Durchmesser ausgerechnet hat, der soll 25,8cm sein, ist der nun in Realität 25,4, wird die Brücke nicht einstürzen. Viele Dinge sind linear, d.h. eine kleine Abweichung führt zu entsprechenden kleinen Abweichungen.
Bei Software steht da if (a==25.4) - 25.3 ist bereits falsch, das if greift nicht. Das macht viel aus.
Ganz so digital ist Software aber auch nicht. Da gibt es kritische Bugs (die das System lahmlegen/stören), weniger kritische Bugs (die das System lahmlegen/stören würden, man das aber durch Anpassung der Parameter umschiffen kann), unkritische Bugs (abschaltbares nice-to-have-feature ist kaputt), unschöne Bugs (toter Code) und eine ganze Latte an Schönheitsfehlern (ungenaue/veraltete Doku, etc. pp.).
Dein Beispiel aus der Statik lässt die Brücke nicht einstürzen weil die Ingenieure Sicherheiten einplanen müssen, weil wenn Fehler dann Mensch tot. Also werden irgendwelche Träger um x% stärker ausgelegt. Gleiche Problemstellung gibt es ja auch bei sicherheitsrelevanter Software weil dort u.U. auch Bug dann Mensch tot gilt. Dort legt man halt die Variablen nicht um x% größer aus sondern ein Softwaremodul überwacht ein anderes auf Plausibilität (einfachstes Beispiel Watchdog-Einheiten).
-
zum Beispiel schrieb:
Warum sollte die Auffindung bestmöglicher Techniken in der Softwareentwicklung binnen 60 Jahren abgeschlossen sein, wo andere Kulturtechniken dafür Jahrtausende brauchten ?
Der Vergleich ist nicht ganz fair. Die Mathematik ist nicht über die Jahrtausende mit der gleichen Intensität betrieben worden wie in den letzten Jahrzehnten die Informatik. Sich mit Wissenschaft im weiteren Sinne zu beschäftigen ist eigentlich Luxus. Die alten Griechen, die wir mit diesem Begriff meinen, sind ja nicht die Griechen an sich, sondern eine Handvoll von Philosophen, die den ganzen Tag nichts weiter getan haben, als zu philosophieren, während um sie herum Heerscharen von Sklaven die Arbeit gemacht haben. Im Mittelalter hatten diese Rolle die Mönche inne (die leider kaum Mathematik betrieben haben), der Rest musste schuften oder sich den Schädel einhauen. Erst seit der Industrialisierung, also seit etwas mehr als 200 Jahren, haben wir überhaupt die Möglichkeit, Leute im großen Stil speziell dafür abzustellen, sich über nicht direkt essbares Gedanken zu machen.
Man sollte also die Mathematik um vielleicht 1800 als gegeben annehmen und ihre Entwicklung in den letzten 210 Jahren mit dem der Informatik in den letzten 60 Jahren ins Verhältnis setzen. (Der Vergleich wäre immer noch etwas schief, da die Informatik durch den zweiten Weltkrieg einen starken Anfangsschub bekommen hat.)Oder aus einem anderen Blickwinkel betrachtet: Soll man der Informatik jetzt auch 5000 Jahre Zeit bis zur Reife geben?
-
Marc++us schrieb:
Bei Software steht da if (a==25.4) - 25.3 ist bereits falsch, das if greift nicht. Das macht viel aus.
if( static_cast<int> (a) == 25 ) cout << "Brücke stürzt meistens nicht ein."
-
Bashar schrieb:
Weil die meisten Programmierer schlechte Programmierer sind.
Kann ich bestätigen.
-
Bashar schrieb:
Der Vergleich ist nicht ganz fair. Die Mathematik ist nicht über die Jahrtausende mit der gleichen Intensität betrieben worden wie in den letzten Jahrzehnten die Informatik.
es wird sicherlich schneller gehen, schon wegen des höheren Bildungsstands und der Kommunikationsmöglichkeiten im Vergleich zum Mittelalter.
Dennoch glaube ich nicht, daß die Softwaretechnik heute nach 60 Jahren ihren Endzustand erreicht hat. Da kommt noch das ein oder andere Plugin
Vllt befinden wir uns, was Softwaretechnik angeht, jetzt ungefähr da, wo sich die Geometrie und Arithmetik im Griechenland der Antike (Euklid, Pythagoras ...) befand.
Wobei ich eher den Eindruck habe, daß sich die Softwaretechnik im Moment in einer Art Zwischen-Renaissance befindet.
- schließlich stammen einige maßgeblichen Paradigmata (funktionale, OO- und deklarative Programmierung) aus den 50er, 60er und 70er Jahren des letzten Jahrhunderts und werden jetzt nach und nach für den Mainstream (wieder-)entdeckt.
Wer wird der Adam Riese der Informatik sein?
Bashar schrieb:
Oder aus einem anderen Blickwinkel betrachtet: Soll man der Informatik jetzt auch 5000 Jahre Zeit bis zur Reife geben?
Natürlich nicht.
-
zum Beispiel schrieb:
Wer wird der Adam Riese der Informatik sein?
Donald Ervin Knuth
-
volkard schrieb:
zum Beispiel schrieb:
Wer wird der Adam Riese der Informatik sein?
Donald Ervin Knuth
Bob Tarjan?
-
ihr wißt, daß Adam Ries(e) derjenige war, der das Zahlenrechnen unter's Volk gebracht hat (indem er dem Dezimalsystem zum Durchbruch verhalf) ?
-
Alles schön dargestellt mit euren Beispielen und Adam Riese!
Tausende von Jahren, um etwas neues zu beherrschen? Ist doch Quatsch! Solarmodule und LEDs gibt es auch noch nicht sehr lange. Doch ich kann sie für wenig Geld überall kaufen, und sie beleuchten meinen Garten.
Mit Software ist das nun etwas anderes. Das ist wie die Herstellung eines Uhrwerkes oder der Bau einer Maschine. Viele Dinge greifen da ineinander und müssen präzise aufeinander abgestimmt sein. Irgendwo ein defektes Zahnrad oder eine zu schwache Kupplung - ihr wisst schon: ein Bug.
Zurück zur Frage: Ein sorgfältiger Programmierer kümmert sich schon im Entwurf um das mögliche Auftreten von Bugs und wichtiger noch, um das schnelle Auffinden derselben. Das bleibt ein Ideal, ganz erreichbar wird es allerdings nie sein.
Fremde unsauber geschriebene Programme sind gewöhnlich schwer zu bugfixen. Man kann nur erkennen, wo und warum es knallt. Die Schwächen des Entwurfes erkennt man damit jedoch nicht.
Reicht mal rüber eure nicht laufen wollende Programme. Ich mache einen doppelten Stundensatz und garantiere für nichts!
-
zum Beispiel schrieb:
berniebutt schrieb:
Mit rund 60 Jahren ist die Softwareentwicklung nicht neu. Man hat genug Erfahrung zur Entwicklung stabiler und wartbarer Programme.
Welchen Grund hat dann die allmonatliche Flut an Patches und Bugfixes für Betriebssysteme, Viewer, Plugins, ... ?
Das kann man auch nicht direkt vergleichen, da Software permanenten Angriffen ausgesetzt ist (die meisten der Patches sind Sicherheitsfixes). Gibt es irgendeine Brücke auf der Welt, die so konstruiert ist, dass man sie nicht mit genügend Sprengstoff zum Einsturz bringen kann? Wohl eher nicht. Software muss aber gegen manigfaltige Angriffe geschützt sein, also hat der Architekt/Ingenieur ungleich mehr Arbeit auf der Sicherheitsseite.
-
sorry, daß ich das anders sehe.
Die Sicherheitslücken sind nicht die Wurzel des Problems, sondern ein Symptom.
Das eigentliche Problem lautet: übermäßige Komplexität.
Heutige OS sind überkomplex, sodaß sie schon lange nicht mehr von einem einzelnen Menschen zu erfassen sind.
Überkomplexe Systeme sind eher gefährdet für Bugs und Spezifikationslücken als einfache Systeme, die ein einzelner Mensch erfassen kann.
Beispiel:
ps aux | wc -l 156=> auf meinem Desktop-PC laufen 155 Prozesse. Davon habe ich selbst 5 gestartet.
=> 97% der Prozesse auf meinem System dienen der Selbstverwaltung des Systems.
Ein klassischer Fall von Überkomplexität
-
Kausale Kette?
-
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.
