Warum sind die meisten Programmierer schlechte Bugfixer?
-
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.
-
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?
