Evolutionäre Programmierung - programmiert auch Ihr evolutionär?

[Delphi-Laie]

Zitat von Furtbichler:

Eigentlich ist das aber alles Quark

Das ist die entscheidende Frage: Kreatives Ausprobieren und Verwerfen, Beibehalten teilverbesserter Lösungen usw. ist eine Vorgehensweise, der weder eine gewisse Systematik noch Erfolge abzusprechen sind. Die Welt der Lebewesen machte es vor und brachte auch uns Programmierer hervor, die darob diskutieren können.

Zitat von Furtbichler:

und als Projektleiter kann ich so etwas in keinem Fall gutheißen (nur vorübergehend dulden).

Warum "in keinem Fall gutheißen", dann aber wiederum "nur vorübergehend dulden"? Ist das nicht ein Widerspruch?

Ist die Zeitersparnis nicht doch der tatsächliche oder "gefühlte" Vorteil, der das dulden läßt?

Auch die tendenziell größere Fehlerarmut bei intensiverem Einarbeiten als bei von vornherein größerem Probieren ist diskutabel: Wie oft bekommt man von einem Programm nach der Implementation eines Algorithmus', einer Idee, von diesem Programm einen Denkfehler in seinem Konzept vorgeführt?

[Furtbichler]

Der Unterschied zur Natur ist der, das die Natur nie fertig wird: "Nach dem Verbessern ist vor dem Verbessern".

Wenn Du deine Heuristik (nennen wir sie mal so) nie auf die Menschheit loslässt, ist alles ok und die Vorgehensweise in der Tat nicht zu beanstanden. Nur im Berufsleben wird man das Resultat deiner Optimierungsbemühungen irgendwann einsetzen oder dem Kunden übergeben. Und dann kann man nur eines von dem Ergebnis sagen: "Es ist nicht fertig", denn das ist ja Mutter Natur auch nie.

Zitat von Delphi-Laie:

Warum "in keinem Fall gutheißen", dann aber wiederum "nur vorübergehend dulden"? Ist das nicht ein Widerspruch?

Ich dulde es, wenn sonst die Abnahme in die Hose geht. Das Problem wird jedoch in jedem Fall anschließend richtig gelöst. Meist ist der Kunde jedoch genauso der Ansicht, das die Lösung lieber gleich ordentlich umgesetzt wird. Dann verschiebt sich die Abnahme eben (sofern nicht kostenpflichtig).

Sollte dir mein Beispiel (aus dem echten Berufsleben) nicht Lehre genug sein, um eine Frage wie "Ist die Zeitersparnis nicht doch der tatsächliche oder "gefühlte" Vorteil, der das dulden läßt? nicht mehr zu stellen? Es ist schlicht und ergreifend Faulheit und Schlamperei, wenn ich etwas, was ich ordentlich erledigen könnte, nur so lange hinschludere, "bis es irgendwie hinhaut", oder "der Kunde zufrieden ist", oder "das Teil doch funktioniert" oder oder oder. Glaube mir: Diese Vorgehensweise beschehrt dir viele unnötige Besuche beim Kunden. Oder im schlimmsten Fall: Schadensersatzforderungen. Du bist nämlich verpflichtet, nicht fahrlässig zu arbeiten. Und was ist diese Einstellung denn anderes als "fahrlässig"?

Grenzsituationen, wie "Schnittstelle, ohne Beschreibung" oder "nichtdeterministische Probleme" werden mit dem Kunden abgestimmt. Hier ist nichts anderes als die o.g. experimentelle Vorgehensweise möglich. Wobei ich mich beim ersten Problem (Schnittstelle ohne Spec) meist weigere, dies umzusetzen sondern verlange, das diese verdammte Spec aufzutreiben ist. Na, und wenns eben gar nicht anders geht, dann hilft eben nur Try & Error.

Umgekehrt hebst Du dich von der Masse ab, wenn Du qualitativ hochwertige Arbeit ablieferst, die nachhaltig und robust funktioniert.

Lassen wir mal die Kirche im Dorf: Grau ist alle Theorie und in der Praxis wird natürlich (wie schon erwähnt) auch mal gefrickelt. Dann verlange ich aber, das dies im Code explizit durch dicke fette Kommentare kenntlich gemacht wird. Der Programmierer muss seinen Namen angeben und beschreiben, warum er diese Frickellösung nehmen musste.

Übrigens weigern sich die meisten meiner Jungs, Schrott zu programmieren, nur damit es irgendwie läuft. Weil, im Endeffekt sind sie es, die die Suppe auslöffeln müssen. Also machen sie es gleich richtig.

Zitat:

Auch die tendenziell größere Fehlerarmut bei intensiverem Einarbeiten als bei von vornherein größerem Probieren ist diskutabel: Wie oft bekommt man von einem Programm nach der Implementation eines Algorithmus', einer Idee, von diesem Programm einen Denkfehler in seinem Konzept vorgeführt?

Na ein Grund mehr, Sachen richtig umzusetzen. Oder bist Du mit (unentdeckten) Denkfehlern in deinem Programm zufrieden?

[Coffeecoder]

Man darf nicht alles in einen Topf werfen.
Es gibt Leute die beruflich mit der Programmierung zu tun haben und die in der Freizeit programmieren.

Es wurde ja schon erwähnt:

Zitat von Furtbichler:

Übrigens weigern sich die meisten meiner Jungs, Schrott zu programmieren, nur damit es irgendwie läuft. Weil, im Endeffekt sind sie es, die die Suppe auslöffeln müssen. Also machen sie es gleich richtig.

Man kann sagen,dass die Berufsprogrammierer diese "Hauruck"-Methoden besser sein lassen (sollten) und gleich überlegt an die Sache rangehen.

Die Hobby-Programmierer oder auch Anfänger tendieren eher zu dieser "Methode" zu programmieren.
Doch unabhängig davon ob Programmierung mit Beruf oder Freizeit zu tun hat, sollte man generell immer in irgendeiner Form seine Idee dokumentieren, darstellen und überlegt an sein Programm/ Problem rangehen.

[bernerbaer]

_Ich_ möchte hier doch noch klar differenzieren zwischen rumfrickeln und dem gesagtem im Ausgansgsposting:

Zitat:

Seit längerem implementiere ich Sortieralgorithmen für ein Animationsprogramm, das ihren Verlauf darstellen soll. Ich habe für die meisten der Algorithmen nicht die „intellektuelle Energie“ und die Ausdauer, mich in deren Funktionsweise hineinzudenken (oft fehlen mir auch Grundlagen dazu). Mithin bin ich auf schon vorhandene Quelltexte angwiesen: Pascal (sehr selten), (Visual-)Basic (selten, aber erträglich) oder allermeistens alle möglichen C-Derivate (ein elende Übersetzung). Oft genug funktionieren die Quellcodes auch nicht zur Zufriedenheit.

Und hier habe ich gerade bei mir festgestellt, dass professionelle Programmierer in der Regel öfters auf externe Quellen und Informationen angewiesen sind als Hobbyprogrammierer. Wer als Hobby programmiert, versucht sich nur an Dingen, die ihn auch interessieren und über die er bescheid weiss. Der professionelle Programmierer jedoch muss coden was von ihm verlangt wird. Das kann einmal aus dem Anlagensteuerungsbereich sein, ein anderes mal aus dem Wirtschaftsbereich, ein drittes mal aus der Forschung usw. Gerade deshalb ist es so, dass ein umfassendes Grundwissen nicht immer vorausgesetzt werden kann, ich kann von einem Programmierer nicht erwarten, dass er Informatik, Mathematik, Wirtschaftswissenschaft, Ingenieurstechnik, usw erfolgreich als Studium möglichst noch mit einem Doktortitel abgeschlossen hat. Deshalb ist ein professioneller Informatiker immer wieder auf externes Wissen, allenfalls sogar auf externen Code angewiesen, den er nur so versteht: "Das gebe ich rein - das kommt raus - also muss es korrekt sein". Das hat aber keineswegs etwas mit rumfrickeln zu tun und soll auch klar definiert und im Code angegeben werden: z.B. Code basiert auf dem Algo von XY - Quelle: xy

Dass Delphi dieses Vorgehen zudem deutlich fördert, ist der Komponentenansatz. Kaum jemand macht sich zum Beispiel noch Gedanken zu der RTF- oder der JPG-Spezifikation um nur zwei Beispiele aufzuführen, man verwendet die entsprechenden Units und damit hat es sich (bis der erste Fehler in der Komponente auftaucht).