Warum sind die meisten Programmierer schlechte Bugfixer?
-
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.
-
hibbes schrieb:
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.
also das kann ich mir nicht vorstellen, man denke nur an die kosten und afaik war da ja auch idr. der gleiche chief software architekt am werk, der wird ja kaum gestern programmiertes/designtes für schlecht befinden...
lg lolo
-
noobLolo schrieb:
hibbes schrieb:
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.
also das kann ich mir nicht vorstellen, man denke nur an die kosten und afaik war da ja auch idr. der gleiche chief software architekt am werk, der wird ja kaum gestern programmiertes/designtes für schlecht befinden...
Warum nicht? Nur wer Fehler macht lernt auch.
G hibbes
-
hibbes schrieb:
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 ein wesentliches Kennzeichen einer Produktion, daß sich ständig Abläufe ändern.
Nur mal ein Beispiel:
Die Automobilfirmen schreiben ihren Zulieferern vor, daß ihre Preise jedes Jahr z.B. 5% sinken MÜSSEN. D.h. als Hersteller muß man alle 12 Monate irgendwie 5% billiger geworden sein - die Produktion ist also einem ständigen Umbau unterworfen.
Auf allen Märkten mit Kostendruck ist das Normalität, bereits während des Aufbaus einer Fertigung wird das Verfahren weiter optimiert und was am Tag X steht, ist bereits anders als das, was zu Beginn der Planung bestellt wurde.
Oder auch gerade der Bau ist ein schönes Beispiel (ich kann dazu inzwischen ein bißchen philosophieren, da ich in einigen "fächerübergreifenden" Projekten unterwegs war): die ganze Abwicklungsprozedur zu Änderungen im Bauverlauf ist dort extrem formalisiert und standardisiert, aber dieses ganze Claim- und Changemanagement dort kommt eben gerade daher, weil selbst während eines Bauprojekts ständig und fortwährend geändert wird. Es ist sogar so ausgeprägt, daß es dafür einen ganzen Regelkatalog gibt, wie man Änderungen einbringt, was Merkmale sind, etc.
Diesbezüglich unterschätzen die Softwareleute oftmals ihr diesbezügliches Alleinstellungsmerkmal:
Ein Projektstart bedeutet ganz neutral, daß dies der Zeitpunkt ist, ab dem der Kunde Änderungswünsche einstreut, die er vorher noch nie angesprochen hat.
[Um bei der berühmten Brücke zu bleiben: ihm fällt also während des Projekts ein, daß er doch gerne auf jeder Seite noch einen Fahrradstreifen zusätzlich haben möchte.]
Einschub: das ist ja auch der Grund, warum sich viele (Bau-)projekte so verteuern - oder woher glaubt Ihr kommen diese zusätzlichen Kosten? Das sind Änderungen am ursprünglichen Liefervertrag (also der SPEZIFIKATION), die sich in Mehrkosten äußern.
Auch daß Änderungen erst später vorkommen, weil der Kunde zu Projektbeginn nicht weiß was er will ist völlig normal. Auf dem Plan kam ihm eben das mit einem Dachfenster ganz ok vor, aber sobald er im Zimmer steht merkt er, daß es zu dunkel ist. Die Vorstellungskraft des Kunden basierend auf dem Plan oder Design ist eben nicht so weitreichend, daß er Vorschläge des Lieferanten wirklich zu 100% versteht. Sobald er dann schrittweise bemerkt was er bekommen wird, entstehen seine Änderungswünsche.
-
Danke für den sehr interessanten Einblick. Trotz der Probleme im Projektmanagement, das sich um das Abfangen der Risiken durch Änderungen kümmern muss, müssen in der Softwareentwicklung mehr Standards her.
In der Industrie wird auch viel nach DIN gearbeitet, und in der Softwareentwicklung kommen zu den Risiken der Spezifikationsänderungen noch das Fehlen dieser DIN hinzu. Ich will damit sagen, dass sich durch diese fehlenden Standards nicht die Dynamik der Projekte ändern lässt, aber diese Produktionsdynamik wird dadurch leichter abgefangen.
-
hibbes schrieb:
Danke für den sehr interessanten Einblick. Trotz der Probleme im Projektmanagement, das sich um das Abfangen der Risiken durch Änderungen kümmern muss, müssen in der Softwareentwicklung mehr Standards her. ...
Welche Standards willst du mehr, schreibe deinen Code nach MISRA C und MISRA C++ Regeln und dann hast du keine Bugs mehr, wenn doch, dann ist die Hardware dran schuld
-
Das geht doch schon mal in die richtige Richtung wenn es dann noch Frameworks/Libs, OS , IDEs etc. geben würde die alle als Standard gleich nutzen bräuchten sich viele nur noch auf die eigentliche Arbeit konzentrieren und eine gewisse Qualität wurde automatisch immer gewährleistet. Alles was dann neben dieser Industrieschiene läuft kann dann halt auch nicht die Qualität automatisch garantieren.
-
Gibt es eigentlich eine DIN-Norm, wie Mathematiker forschen müssen? Wäre doch eine supi Idee, es gäbe keine falschen Beweise mehr und überhaupt wäre alles viel effektiver.
-
Nein, aber einen absolute weltweit standardisierte gemeinsame Sprache an der es nichts zu rütteln gibt, stell dir mal da vor wenn es da keine Einheit geben würde.
-
hibbes schrieb:
Nein, aber einen absolute weltweit standardisierte gemeinsame Sprache an der es nichts zu rütteln gibt
Leider nicht.
-
Ach nicht? Ich habe leider wenig Ahnung von Mathematik, aber ich dachte immer die Mathematik ist die einzige Sprache die Weltweit einheitlich verstanden wird.
-
hibbes schrieb:
Ach nicht? Ich habe leider wenig Ahnung von Mathematik, aber ich dachte immer die Mathematik ist die einzige Sprache die Weltweit einheitlich verstanden wird.
Die Vokabeln sind frei.
Schon bei N| scheiden sich die Geister, ob die 0 drin ist oder nicht.Und dauernd hat man was wie http://en.wikipedia.org/wiki/Strong_pseudoprime
"It should be noted, however, that Guy uses a definition with only the first condition [1]. Because not all primes pass that condition, this definition of 'strong pseudoprimes' resembles the primes less closely."
Und mich stört es nicht (mehr). Die anständigen Typen machen immer ganz klar, was sie meinen.
-
hibbes schrieb:
Ach nicht? Ich habe leider wenig Ahnung von Mathematik, aber ich dachte immer die Mathematik ist die einzige Sprache die Weltweit einheitlich verstanden wird.
a) gilt das nur für Mathematiker (soviel zum Thema Welt)
b) wirst Du Mathematiker finden, die mit einer bestimmten mathematischen Aussage überfordert sind, weil sie "den falschen Level" haben
c) wird auch ein Mathematiker in China anders an ein Problem rangehen als ein Deutscher, weil Problemlösungsstrategien immer auch kulturellen Strategien unterworfen sind
Ich denke aber auch nicht, daß Fehler das wirkliche Problem der Softwareentwicklung sind - klar, weniger ist besser, aber ich sehe das größte Problem eher in der Intransparenz. Man kann schwer überblicken, was jemand gerade tut, wie er es tut, wie seine Lösung ausformuliert ist, und auch kann man schwer erkennen, wie weit jemand ist. Daher kommen dann am Tag X immer so böse Dinger hoch... und jeder flucht über die gottverdammten Softies... wieder mal geht nix, und fertig ist es auch nicht.
-
hibbes schrieb:
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.
Von Null anfangen kann man bei Brückenbau auch. Bzw. fast überall.
Einfach alles wegbaggern und von vorne anfangen.Kostet aber so viel, dass es selten gemacht wird. Sowohl in der Software-Entwicklung als auch bei Brücken.
-
Es gibt bei der Softwareentwicklung einfach zu viele Wege ein Problem zu lösen, viel mehr als in Branchen die schon länger existieren. Wenn alle es so gerne mit der Baubranche vergleichen denke ich mal das Bambushütten oder irgendwas aus der Jungsteinzeit oder so der richtige Vergleich wäre.
Auf jeden Fall werden wir in ein paar Jahrhunderten uns mit Kopfschütteln an die Zeit von heute erinnern und sagen "Dass die Leute so programmiert haben, würde heute mit einer Freiheitsstrafe nicht unter 10 Jahren bestraft!"
Aber wir reden ja schon mal drüber, dass ist ja ein Anfang...
-
hibbes schrieb:
Auf jeden Fall werden wir in ein paar Jahrhunderten uns mit Kopfschütteln an die Zeit von heute erinnern und sagen "Dass die Leute so programmiert haben, würde heute mit einer Freiheitsstrafe nicht unter 10 Jahren bestraft!"
Wie willst du das machen? Dazu brauchst du erst eine Zeitmaschine oder eine Wunderpille der Pharmaindustrie. Bedenke, die Zeitmaschine von Bernhard Shaw hatte auch einen Bug!Bugs sind bereits in Naturgesetzen implementiert, sonst gäbe es keine Evolution! :p
-
Ja klar gäbe es ohne Fehler uns alle nicht, aber das kann auch nicht die Entschuldigung dafür sein sie nicht minimieren zu wollen und dazu bedarf es auch Veränderungen. Du weißt ja Stillstand ist der Tod
Wir müssen halt irgendwann mal auch dahin komme wo andere Technologien schon jetzt sind.Ich denke ich werde mich hier aus dem Thema auch ausklinken, das ist eine neverending story und ich wollte eigentlich C++ lernen.
Aber nett mal drüber geredet zu haben, da lernt man doch dass viele ganz andere Ziele haben als man selbst, aber das ist ja auch in Ordnung so, das macht uns ja so vielfältig.
P.S.: Hier noch ein Zitat was vielleicht auch dabei hilft mehr Standards, oder wie Stroustrup es nennt Vorschriften, zu etablieren:
HD Haben wir der Architektur einen zu hohen Stellenwert eingeräumt?
BS Nein, jedenfalls nicht in dem Sinne, wie ich Architektur definieren würde. Im Gegenteil, die Architektur hat einen zu geringen Stellenwert, und es gibt zu viel schlechte Programmierung mit zu wenig Kenntnis der strukturellen Prinzipien. Ich vermute, dass ein Hauptproblem bei der Architektur darin besteht, dass viele Programmierer nur eine unklare Vorstellung davon haben, was einen guten Code ausmacht. Es reicht nicht, es zu erkennen, wenn man es sieht. Es reicht nicht, Regeln für das zu haben, was man nicht tun darf. Wir brauchen klare Vorschriften.
-
hibbes schrieb:
Wir müssen halt irgendwann mal auch dahin komme wo andere Technologien schon jetzt sind.
Das geht nicht. Das Enwickeln und Programmieren von Software beruht nicht auf verifizierbaren Naturgesetzen oder sonstigen verbindlichen Grundlagen.
Vielleicht könnte man eine Forschungsrichtung etablieren mit dem Ziel, "Sich selbst korrigierende Programme"? Mit sowas kriegt man dann einen Lehrstuhl in der Informatik!
