Re: Perfekte Software

Written on December 04, 2008

Serious_Discussion, Dhaka University, Dhaka, B...

Image via Wikipedia

Schön, dass die Diskussion um perfektes Design, perfekte Entwickler und jetzt auch perfekte Software langsam an Fahrt gewinnt (wird das zuletzt noch die perfekte Diskussion?) ;-)

Sven schreibt:

Wenn ich jemanden frage, der vor 20 Jahren Entwickler war, und in C/Cobol/Fortran oder was auch immer eine Auswertung über Geschäftsvorfälle schreiben sollte, so ist meine Hypothese, dass die veranschlagte Zeit gegenüber heute nicht großartig anders ist.
Und das, obwohl wir ach so viele Vorgehensweisen, Tools und was auch immer einsetzen, um unsere Arbeit besser zu machen.
Unser prä-IDE Entwickler wird aber sicherlich sagen, dass er eine durchaus robuste und nachhaltige Lösung geschrieben hat. Vielleicht wird sie sogar noch immer auf irgendeinem Mainframe verwendet.
Der Unterschied zu heute ist, dass es heute eine bunte Ausgabe mit Charts und variablen Parametern ist. Die Wertschöpfung allerdings wird sich nicht grundlegend unterscheiden...

Ein Argument, das in ähnlicher Form auch Ken Schwaber in seinem Buch Agiles Projektmanagement mit Scrum anführt. Allerdings ist genau dieses für ihn ein Grund, weshalb agile Prozesse -- eben z.B. Scrum -- notwending sind, um wieder Herr Lage, sprich Komplexität, zu werden. Die Prozesse müssen mit den Anforderungen wachsen bzw. ihnen generell angepasst werden.

Sven weiter:

Ich kann nur perfekte Lösungen liefern, wenn ich entweder über alles Bescheid weiß und genügend Erfahrung sammeln konnte, oder eben meine Grenzen kenne und innerhalb derer agiere oder auch Handlungen vermeide. Schließlich gibt es immer jemanden, der etwas besser kann, als man selbst.

Ich weiß nicht, ob DDD und TDD Projekt-Erfahrung voraussetzen. Das wäre für mich so, als müßte ich Verkehrsregeln erst nach 3 Jahren Praxis kennen.

Allerdings gebe ich Dir recht, dass evtl. der Nutzen von TDD und DDD (später noch BDD?) erst nach mehreren Jahren Projekt-Erfahrung inkl. Fehlschlägen erkannt werden kann. Nur sollten hier die Community, die Unternehmen und Schulungszentren den Neuling frühzeitig auf den richtigen Pfad führen und nicht mit Pseudo-Beispielen um des Verkaufens (von neuen Features in IDEs) willen zeigen, wie man es nicht macht.

Ich persönlich wäre froh, ich hätte beim Umstieg auf .NET die Möglichkeiten von TDD und DDD bereits damals gekannt.

Weiter im Text:

Perfektion kostet Geld. Perfektion kostet Zeit. Perfektion kostet Manpower.
Eine Applikation ist durchschnittlich (!) wohl 2-5 Jahre im Einsatz. Je nach Einsatzort und -zweck. Während dieser Zeit durchlebt sie diverse Versionen und Updates.

Gerade dies ist für mich DER Grund pro TDD und DDD.

Ich will in Version 3.1.2.x.y noch immer das Feature A aus Version 1.0.0.0.0 in der gleichen Funktionalität wie damals und nicht beschnitten durch irgendwelche ungetesteten Seiteneffekte der aktuellen Version, in der Feature XYZ eingeführt wurde.

Abschließend:

Perfektion kann nur im Rahmen der aktuellen Gegebenheiten (Wissen, Zeit, Geld) erreicht werden, was vollkommen ausreichend ist

Da stimme ich vollständig zu. Gerade dies ist imho aber auch ein Grundgedanke von DDD und ALT.NET: YAGNI - _You Ain't Gonna Need It -- _Implementiere nur das, was wirklich benötigt wird und "bastle" nicht vorneweg ein Design für den Fall der Fälle der in 3 Jahren bei Version 2.x auftreten könnte.