Warum sind die meisten Programmierer schlechte Bugfixer?
-
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!
-
Bashar schrieb:
Es ist übrigens außerordentlich erheiternd, mit Softwareentwicklern Jenga zu spielen.
In Nösberts ist ein Jenga-Spiel und das haben wir auch benutzt. Ich fand das ganz normal.
-
volkard schrieb:
In Nösberts ist ein Jenga-Spiel
Der arme.
-
Marc++us schrieb:
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.
Probiere es doch.
Vielleicht hast du mich nicht ganz verstanden. Ich behaupte der Source Code ist das Design. Das Produkt ist nicht der Source Code, es ist der nach Maschinensprache oder VM Bytecode übersetzte Source Code, plus die Abhängigkeiten und die Dokumentation. Der "Bau" des Produktes ist hauptsächlich das Kompilieren und dauert nur Minuten. Kurz gesagt, das lauffähige Programm plus die Dokumentation ist das Produkt. Der Source Code ist das Design des Produktes.
Programmierer verbringen fast ihre gesamte Zeit am Design des Produktes, der Bau geschieht aber in Minuten. Somit können Programmierer das Design anpassen, ein Produkt bauen und es gleich testen. Bei einem physischem Objekt dauert der Bau genauso lange oder länger als das Design. Deswegen kann man auch nicht das Design ändern, neu bauen und testen. Für das Testen muss man hier mit Modellen arbeiten. Die Programmierer können aber das echte Produkt testen.
Wenn du mir nicht glaubst, schau dir Emergent Design & Evolutionary Architecture Autor: Neal Ford - 21.09.2009 von Slide "Source = Design" an. Kannst auch hier nachlesen: What Is Software Design? By Jack W. Reeves
Wenn ich was falsch verstanden habe kannst du mich gerne darauf aufmerksam machen.
-
Ich glaube die wenigsten Programmierer hier hätten wirklich Lust Software so zu entwickeln, wie es Ingenieure tun. Gerade hier schätzen viele Leute doch den kreativen Freiraum und eher das mathematische am programmieren. Allein die Leute auf Misra-C/Misra-C++ zu setzen, würde bei vielen wohl einen Schock auslösen. Marc++us hat imho recht, dass das Codieren vergleichbar ist mit dem eigentlichen Bau der Brücke. Und genauso wie man erwartet, dass die Arbeiter genau das tun, was man ihnen sagt und nicht sonderlich kreativ sind, so wird das bei vielen Projekten von den Programmierern erwartet. Aus dem Grund mögen einige Projektleiter sicher bestimmte "Coder Monkey"-Sprachen, die ohnehin wenig Freiraum für Kreativität lassen.
Das Web hat das ganze für reine Softwarefirmen sicher verändert, weil man jetzt einfach laufend am System basteln kann und "kreatives Chaos" auch zu kreativen Produkten führt. Beispiel ist Google, wo fast jedes Produkt "Beta" ist und der Arbeitsablauf etc. angeblich so super und "Freidenker" fördernd ist. Ob sie das natürlich aufrecht erhalten können... Zumindest die Ausschnitte die ich von Google I/O gesehen habe, wirkten sehr steif, weniger kreativ und das Buzzwordbingo war kaum auszuhalten. Also eher wie IBM und nicht wie ein ewig junges Startup.
-
Marc++us hat imho recht, dass das Codieren vergleichbar ist mit dem eigentlichen Bau der Brücke.
Nein hat er nicht
Wenn du die Brücke schon anfängst zu bauen, sind alle Designphasen abgeschlossen. Du kannst ja nicht mitten im Bau sagen, wir haben Xxx vergessen, oder wir hätten da ein viel besseres Design, lasst uns das anstelle des alten machen. Wenn du einen Fehler findest und die Brücke wurde schon angefangen zu bauen, ist es nur unter enormen Kosten möglich das Design zu verändern.Aber vielleicht ist Marc++us ein Fan des Wasserfallmodells, wo man alles Planung im Vorfeld abwickelt und danach erst Programmiert. Aber auch dann ist die Programmierung noch das Design und das Produkt das lauffähige Programm. Vielleicht liefert Marc++us ja auch nur den Source Code aus, nach dem Motto, hier ist der Code, meine Arbeit ist beendet, wo ist das Geld.
-
DEvent schrieb:
Nein hat er nicht
Was du aufzeigst sind doch nur die Grenzen der Analogie. Ja Brücken kann man nicht so wie Software entwerfen. Aus dem Grund ist der Entwurf bei einer Brücke viel aufwendiger und teurer und durchläuft Genehmigungsverfahren und ausführliche Verifikation gegenüber Gesetzen und Normen. Ähnliches gibt es in der Softwareentwicklung ja nur in Spezialfällen. Eben bei sehr Ingenieursmäßigen Entwicklungen z.B. Software von Herzschrittmachern oder zivilen Flugzeugen. Was wieder mein eigentlicher Punkt ist, dass man als Programmierer so eigentlich keine Software entwickeln will. (Wobei dies natürlich viele Gründe hat und nicht nur die fehlende Kreativität. zB muss man bei Software ja oft erst einmal rausfinden, was der Auftraggeber nun genau haben will und ob man überhaupt die gleiche Sprache spricht. Das ist beim Bau einer Brücke natürlich nicht so.)
-
Kommen wir doch auf das Bugfixen zurück!
Punkt 1: Bugs kann man durch sorgfältiges Design in der Anzahl einschränken, ganz ausschliessen nicht.
Punkt 2: Software ist keine statische Angelegenheit - entworfen - realisert - ausgeliefert - fertig.
Punkt 3: Zu einer 'Guten Software' gehört auch die leichte Wartbarkeit, sowohl für das Auffinden von Bugs als auch für Erweiterungen.
Punkt 4: Eine einfach konstruierte Brücke besteht aus einen oder mehreren Baumstämmen, die man über einen Graben legt.
-
rüdiger schrieb:
Was du aufzeigst sind doch nur die Grenzen der Analogie.
Achso, "nur"? IMO ist das ein ganz zentraler Punkt. Es geht um den Stellenwert des Schreibens von Code. Setzt man die Bauausführung damit gleich, dann handelt es sich nur um das Umsetzen eines vorgegebenen Designs. Setzt man die Bauausführung aber mit dem Compilieren gleich, dann ist das Codeschreiben selbst ein kreativer Entwurfsprozess.
-
Es ist schwer für die Softwareentwicklung Analogien zu finden da mir nichts Analoges dazu in der Welt einfällt. In welcher Produktion kann man jederzeit wieder alles ändern? Das ist ja auch ein Grund warum sich die Anforderungen der Kunden so schnell ändern, sie wissen das Software was extrem Dynamisches ist. Für mich ist Software ein Screenshot vieler Ideen der aber auch schnell wieder durch einen Neuen ausgetauscht werden kann.
Meine Antwort zu diesem Thema ist: Die meisten Programmieren sind deswegen schlechte Bugfixer weil jeder Mensch nunmal ähnlich aber doch anders denkt. Für gute Fehlersuche an fremden Produkten fehlt es einfach an Standards die streng von Jedem eingehalten werden. Wo Jeder Alles machen kann blickt Keiner mehr durch.
G hibbes
-
hibbes schrieb:
In welcher Produktion kann man jederzeit wieder alles ändern?
Das kann man auch in der Software-Entwicklung nicht.
Klar kann man so programmieren dass Refactoring stark vereinfacht wird, aber zu glauben man könne ein Software-Design jederzeit ändern ist etwas blauäugig.
-
Naja, Software wie Windows, Office, Photoshop, 3DSMax etc. da bin ich mir nicht sicher ob da nicht schon mal bei vielen Teilen von Null angefangen wurde, aber gut war vielleicht etwas zu übertrieben beschrieben.
