Warum sind die meisten Programmierer schlechte Bugfixer?
-
Bashar schrieb:
Nö, die Masse ist durchschnittlich (wie soll es auch anders sein?) und 80% sind schlecht.
Das kann nicht sein.
-
marktluecker schrieb:
Marktlücke:
Verding dich doch einfach als bugfinder.Solche Leute gibt es.
Die lassen sich nach Erfolg bezahlen, da sind Summen im fünf- bis sechsstelligen Bereich angesagt.
-
Bashar schrieb:
Die Spitze gibt es immer noch, aber die Pyramide ist nach unten gewachsen.
Vielleicht haben sich aber auch letztlich die Anforderungen nach unten verschoben. Für viele Applikationen reicht möglicherweise der vom Arbeitsamt umgeschulte VB-Programmierer völlig aus.
Früher hat man bei vielen Sachen gar nicht an ein Programm gedacht, da schrieb man das auf Zettel auf, heute wird das in Software gemacht. Aber nicht jede Applikation ist eine Steuerung für Atomkraftwerke.
-
Marc++us schrieb:
marktluecker schrieb:
Marktlücke:
Verding dich doch einfach als bugfinder.Solche Leute gibt es.
Die lassen sich nach Erfolg bezahlen, da sind Summen im fünf- bis sechsstelligen Bereich angesagt.
Zählen die schon zu den Sicherheitsexperten? Oder beziehst du dich mehr auf den "Putztrupp" ala "Hier wird das Label falsch gesetzt"?
-
Ich habe die bisherigen Beiträge im Schnelldurchlauf gelesen - und wundere mich. Nur triviale Programme haben keine Bugs, aber welches Programm ist schon trivial? Seit den Anfängen der Programmierung gehört zur Programmierung auch ein sauberer Programmentwurf und die Integration einer geordneten Fehlersuche. Die Hersteller der Compiler haben da als Hilfe Debug und Event-Handling angeboten - nur das tut es nicht oder nicht auf Dauer!
Die Frage ist wichtig. Es geht um Programmierstil. Wenn der schlecht ist, kann man nichts machen!
-
[...] that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
(C.A.R. Hoare)
-
Debugging setzt Wissen über die Funktionsweise dessen vorraus, was man gerade macht, Programmieren nicht. Mit heutigen Entwicklungsumgebungen und Werkzeugen kann man viele Technologien benutzen ohne diese verstehen zu müssen. Solange alles läuft, prima... Wenns dann aber nicht geht sind solche Leute aufgeschmissen.
-
gui-code bzw. 3d-engine code (hab ich zwar noch nicht gemacht, kann ich mir aber gut vorstellen) um nur einige beispiele zu nennen, also alle code stellen mit vielen objecten, recursion, schleifen und events sind ein horror zum debuggen. da kann man machen was man will und die debugger helfen dir auch nicht (nur wenig). in so einem fall lässt dir das ganze am besten auf die console ausgeben, oder setzt breakpoints auf variablen werte, nur auf welche;) ...
lg lolo
-
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.
