Wirtschaftlichkeit: Design, Dynamik versus Hardcodiert, Schnelligkeit

Hallo liebes Forum,

ich hatte gestern eine sehr hitzige Disussion mit einem Kollegen von mir, und diese Diskussion beschäftigt mich immer noch.

Ich würde gerne wissen, ob es öffentlich verfügbare Untersuchungen gibt, was die Wirtschaftlichkeit in Bezug auf Design und Dynamik in der Softwareentwicklung angeht.

Im Raum stand folgende Diskussionsgrundlage:
Mein Kollege behauptet, dass es nicht wirtschaftlich wäre rein Designorientiert zu denken, und sich ALLE möglichen Türen offen zu halten. Im konkreten ging es darum, dass er behauptete, dass es durchaus OK ist, wenn z.B. in der GUI ein TabControl fix 3 Tabs haben soll, wenn abzuschätzen ist, dass es eh nicht erweitert werden wird. Und daruafhin ist es für ihn auch Ok, die "3" hardcodiert in den Source zu schreiben, und das auch an allen Stellen, an der eine Abfrage der Anzahl von Tabs nötig wäre.

Ich habe allerdings behauptet, dass es eventuell einen kleinen Mehraufwand bedeutet, das ganze dynamisch zu gestalten, damit auf Veränderungen reagiert werden kann.

Quintessenz war, dass ich behauptet habe, dass es insgesamt wirtschaftlicher ist, sich gleich um eine solche Problematik zu kümmern, und eventuell in diesem Zusammenhang mehr Arbeit zu haben, als dass ich mich eventuell im Nachhinein dran setzen muss um es zu ändern.

Klar, dass er der Meinung ist, dass eine reine Programmierung von Hardcodierten Dingen nicht funktionieren kann. Er ist aber der Überzeugung, dass es abschätzbar ist, wo und an welchen Stellen Änderungen auftreten können, und wo nicht.

Deshalb nun meine Frage, kennt jemand zufälligerweise Untersuchungen, die belegen können, dass Dynamisches Programmieren in ALLEN Bereichen wirtschaftlicher ist, als TEILWEISE an abgeschätzten Stellen Hardcodiert zu programmieren?

Das wär echt cool.

Gruß
Norman-Timo

Quellen kenne ich leider nicht, aber in der Firma in der ich momentan bin sind dirverse Dinge in der Applikation hardcodiert. Damit laufen wir in diverse Probleme wie Windows 2003 Server Komaptibilität da das Windows Verzeichnis dort nicht mehr WINNT heisst.

Wenn man jetzt anschaut, dass das dynamische programmieren hier Abhilfe geschaffen hätte, würde es nicht so teuer kommen a) die Source Aufgrund des Supports von Windows 2000 eh umgeschrieben werden muss und dann enorm viele Personalerssourcen alloziert werden müssten und b) hätte man nicht hardcoded programmiert wären bei Releasewchseln nicht Fehler aufgetreten die verhindert hätten werden können.

So gesehen ist dass dynamische programmieren eher wirtschaftlicher, da aufgrund der möglichen Folgen einer hardcodeten Programmierung, die finanziellen Aufwendungen sehr hoch werden und somit der Retrurn on Invenst und somit die Wirtschaftlichkeit nicht mehr gewährleistet wären.

Ich hoffe, der Input konnte Dir ein bisschen weiterhelfen, auch ohne Quelle.

Hallo schaedld,

ich bin voll Deiner Meinung, und ich denke sehr viele hier im Forum werden derselben Meinung sein. Mein Kollege allerdings hat sehr lange nichts mehr aktiv Programmiert, und auch eher etwas anderes studiert, daher behauptet er nunmal etwas anderes.

Ich weiß, dass es wirtschaftlicher ist, es geht darum ihm das jetzt irgendwie zu belegen.

"Return of Invest" ist hier ein sehr gutes Stichwort, werd mal googlen...

Danke an Dich.

Gruß
Norman-Timo

Ich lasse mir jeweils vom Kunden 101% versichern dass das gewünschte sich in den nächsten 1000 Jahren nicht verändern wird.... Trotzdem wird nichts hart codiert, da je nach Kunde manchmal 1000 Jahre bereits nach 3 Tagen vorbei sind.

Nichts ist beständiger als der stetige Wechsel.

Hallo Programmierhans,

ich brauch Zahlen, Fakten Hintergründe,

ZAHLEN,

nein im Ernst, wie gesagt, es geht darum seine Aussage zu widerlegen, dass es ok wäre etwas hard zu codieren, solange man eine Abschätzung über die Veränderlichkeit dafür macht, und das im Zusammenhang Wirtschaftlichkeit...

Gruß
Norman-Timo

ROI Return on Invest bezeichnet die Investitionsressourcen die verwendet werden und die Amortisation auf eine Anzahl Jahre.

Als Beispiel: Eine Anwendung zu designen die hardcodiert ist, ist der Kostenfaktor am Anfang vielleicht 5000. Ein eher geringer fianzieller Aufwand. Wenn aber in den nächsten 2 Jahren ein Aufwand von 20000 verwendet wird um die Applikation umzuschreiben hat sich die Investition nicht gelohnt.

Will heissen bei der Programmierung von dynamischen Code ist der Initialaufwand vielleicht 10000, auf 3 Jahre gesehen dann eine Einsparung von eventuell 60000 möglich (dazu werden Administrations, Programmier-, Wartungsaufwand gerechnet). Wenn diese Aufwände in den 3 beschriebenen Jahren nur wenig vorkommen, dann hat sich der ROI auf diesen Zeitraum gelohnt.

Ich hoffe es nicht allzu kompliziert beschrieben zu haben.

Original von norman_timo
Deshalb nun meine Frage, kennt jemand zufälligerweise Untersuchungen, die belegen können, dass Dynamisches Programmieren in ALLEN Bereichen wirtschaftlicher ist, als TEILWEISE an abgeschätzten Stellen Hardcodiert zu programmieren?

hallo norman_timo,

leider nicht, aber aus eigener erfahrung kann ich berichten, dass böses quick & dirty hardcodieren, durchaus wirtschaftlicher sein kann.

ich will hier keine lanze dafür brechen, denn ich bin im grunde auch für dynamisches und durchdesigntes programmieren, aber wie gesagt, manchmal...

-yellow

Man muß das schon abwägen.

Irgendwann verzettelt man sich in sein vollkommen generisches System, wo alles nur dynamisch aufgebaut wird, aber auf der anderen Seite dann auch viele Dinge nur über 3 Umwege und wieder mit richtig dreckigen Methoden erreichbar sind.

Im Grunde genommen gibt es schon einiges, was man in Config und Skripte auslagern kann, aber man muß auch irgendwo Grenzen setzen. Und es gibt definitiv Fälle, wo man absehen kann, inwiefern sich da was ändern könnte. Natürlich gilt das nicht für alle, ist auch klar.

Letztendlich gibt es Dinge, wo es dann fast egal ist, ob man nun in der Config 20 Zeilen ändert oder im Code 50. Vom Ändern her. Es kann aber durchaus sein, daß der Code sowohl vor als auch nach der Änderung viel sauberer, eleganter, und übersichtlicher ist, als wenn man den Code von vorneherein dynamisch gemacht hat.

Also das kommt echt auf den Einzelfall drauf an, einfach so pauschal zu sagen "immer alles generisch machen" ist nicht möglich.

Generischer Code braucht oft MetaDaten... Man muss dann aufpassen, dass der Umfang der Metadatenpflege nicht so gross wird, dass der Code unwartbar wird.

Achtung, Begriffsverwirrung: "Dynamische Programmierung" ist eine Optimierungstechnik.

Ansonsten empfehle ich Literatur zu agilen Prozessen. Der XP-Erfinder Kent Beck hat den Begriff geprägt: "** Do the most simple thing that might possibly work**”. Wohl eine Kopie eines Einstein-Satzes: "As simple as possible, but no simpler."

Ein klares Statement gegen den bisherigen Trend, möglichst vieles ins Design zu prügeln, auch wenn es aktuell noch nicht notwendig ist.

Die Annahme, möglichst viel in ein Design zu stecken sei besser, geht letztlich von dem nicht-agilen Paradigma aus, dass Design-Lücken kaum noch (oder sehr teuer) zu beheben sind. Dass dieses Paradigma nicht mehr universell gilt, haben agile Prozesse wohl bewiesen.

Ungenutzte Features erhöhen die Komplexität und führen u.U. in genau das Wartungsproblem, dem man entkommen wollte. Zudem haben Untersuchungen gezeigt, dass nur 20% der "vorgeplanten" Features tatsächlich so realisiert werden (Zahlen, die ich aus meinen frühen Projekten bestätigen kann). Man arbeitet also zu 80% in die Tonne.

Je agiler ein Prozess ist, desto schlanker sollte ein Design sein. Bei Wasserfallprozessen sieht das sicher anders aus.

Insofern handelt es sich hier tatsächlich um eine Diskussion für oder wieder agile Prozesse. Wer zum Überdesignen neigt, wird auch agile Prozesse ablehnen.

Entscheidend ist, die fachliche Komplexität nicht zu groß werden zu lassen.

Technisch kann man ein paar Grundregeln beachten:

Kopplung reduzieren wo es geht (Interfaces, Factory-Klassen). Vorsicht mit Vererbung, tiefe Vererbungsstrukturen (mehr als 2-3) führen oft in den Wartungstod (Interfaces einsetzen!).

Nicht von vornherein alles als PlugIn auslegen. Aber Factories (statt Konstruktoren) und Interfaces verwenden. Damit kann eine Klasse mit drei Handgriffen nachträglich als PlugIn gebaut werden.

Automatisierte Tests verwenden, sonst wird das Erweitern des Designs zu teuer in der Fehlerbeseitigung.

...bisherigen Trend, möglichst vieles ins Design zu prügeln, auch wenn es aktuell noch nicht notwendig ist.

Jepp, oftmals dauert das auch letztendlich um einiges länger, und wenn man dann, wie Du sagtest, 80% von dem, was man "möglicherweise" implementieren hätte können, verwirft, dann hat man nicht nur viel Code umsonst getippt sondern auch 'ne Menge unnötige Zeit hineingesteckt.

Das kann sogar die Fertigstellung verhindern - wenn man sich alles offen halten will und deswegen ewig lang an was rumprogrammiert, was gar nicht mit der Kernfunktionalität mehr zu tun hat - und man dann hinterher auf einmal keine Lust mehr auf sein Projekt hat (wenn man mal nicht von einem Auftragsprojekt ausgeht, das man abliefern MUSS), und letztendlich aufgibt.

Darum ist eine IST /SOLL Analyse mit Erweiterungspotenzial unerlässlich. Setzt natürlich fähige Projektleiter voraus 😁

Ein sehr gutes Beispiel für beides ist der Sql-Server 2005.

MS hat den erst so geplant wie norman das meint, und hat dadurch die Einführung,
die für 2003 geplant war verpasst.
Alleine das design war so umfangreich, das sich bei der Implementation so verzettelt wurde,
das eine riesige langsame schwer zu wartende Resourcenverschwendung entstand.

MS hat dann in 2004 intern auf SCRUM umgestellt, was auch die Teamedition des
VS.NET schön zeigt.

Mit einem mal wurden die Entwicklungszyklen schneller, die Tests besser, das ganze Projekt gerettet.
So konnte dann die verspätung auf "nur" 2 Jahre gedrückt werden.

Ich persönlich arbeite schon seit Jahren agile, mit TDD ansätzen.
Da TDD dazu anleitet immer gegen Interfaces zu arbeiten ( mal MOCK anschauen )
ist auch die spätere Erweiterung "kein Problem".
Gerade in der Entwicklung von Individual SW ist dieser Ansatz viel einfacher.

Beispiel:
Ein Kunde wollte seine bisherige Access Anwendung ( Lager/Rechnung/Lieferscheine...)
nun als Multiuser version mit rechtevergabe.... haben.

Wir haben uns dann zusammengesetzt und Version 1 bis 5 besprochen.
Version 1 hatte dann nur die unbedingt zum Betrieb notwendigen Funktionen.
Version 4 hatte alles zum Arbeiten, und Version 5 dann die Gadgets 😉

Der Kunde hatte nach 10 Tagen eine Version mit der er arbeiten konnte,
nach 4 Wochen die komplette version.
Die z.T. vom Kunden gemachten Bugreports sind immer in der jeweils nächsten
Version behoben worden.
So hatte der Kunde ein viel schnelleres und besseres gefühl für seine Anwendung,
als wenn er eine "fertige Anwendung" nach 4 Wochen bekommen hätte.

Durch die schnelleren Zyklen kann man auch noch auf dem Weg zum Endprodukt
umsteuern, wenn z.B. gemerkt wird, das irgendetwas eigentlich doch nicht benötigt wird.

Ich musst zwar in der Planung Sachen wie das Rechtemanagment vorsehen,
aber nur die Prinzipien, nicht unbedingt die konkrete Implementierung.
War auch gut so, denn nach Version 2 hat der Kunde dann gemerkt, das es für Ihn
auch ohne geht.
Hätte ich das ganze gleich komplett geplant und eingebaut, wäre es für Ihn
gleich €500 Teurer geworden.

Aber wie schaedld schon anmerkte, das erfordert dann echte Projektleiter,
die wissen was sie tun, aber auch den "Kunden", jemanden der Entscheidungen
treffen kann und will.

Wie ich schonmal in einem andern Thread hier sagte, werden die Agilen Methoden leider noch
nicht auf allen Unis in dem Umfang gelehrt wie nötig.

Original von schaedld
Darum ist eine IST /SOLL Analyse mit Erweiterungspotenzial unerlässlich.

Agile Prozesse sind aus der Erkenntnis enstanden, dass umfangreiche Anforderungsanalysen, Lasten- und Pflichtenhefte die Erfolgsquote von Projekten nicht signifikant erhöhen - eher im Gegenteil. Sie sind ein Versuch, die Schnittstellen zwischen Auftraggeber und Auftragsnehmer zu minimieren mit dem Effekt, dass das notwendige Feedback, das notwendig ist um Fehler und Veränderungen Rechnung zu tragen, unterbleibt. Statt Veränderungen "zu begrüßen" werden sie vermieden - zur Not mit Vertrag und Anwalt. Ein absurde Situation, gerade bei Entwicklungsprojekten, bei denen naturgegeben eine "Planung" überhaupt nicht stattfinden kann, weil neue Anforderungen oder Erkenntnisse zwangsläufig aus der Nutzung der Systeme erwachsen.

Das Ergebnis sind bestenfalls suboptimale SW-Systeme die mit 83% Terminüberschreitung (das ist der Durchschnitt) an den Start gehen.

Agile Prozesse erhöhen dagegen das Feedback und nutzen es, um die Fortentwicklung des Projektes zu steuern. Die Vorteile sind vielfältig. Zudem entfallen große Teile des lästigen Papierkrams.

Ich kann FZelle nur zustimmen. Agile Methoden sollte Lernstoff an den Unis sein.

Hallo zusammen,

ich sehe also, dass ich dem Trend hinterher bin. Allerdings muss man in der agilen Arbeitsweise besonders im Team auf ein strenges Reglement einigen, ansonsten wirds sehr schnell inkompatibel.

Modularität und strenges Arbeiten mit Interfaces, Factories und (auch von mir immer wieder gern gesehenes) Microkernel Prinzip sollten eine solche Arbeitsweise begünstigen. Aber auch hier braucht es ein Grunddesign, zumindest was die Architektur angeht.

Ich befinde mich aber in einem Marktsegment, bei dem zu schnelle Änderungen gar nicht so gut ankommen. Viel ist als Standard definiert, und sogar teilwiese gesetzlich festgeschrieben. Trotzdem könnte ich mich (da ich nicht für die Firma lebe 😉 mit einer agilen Herangehensweise anfreunden.

Gibt es für agile Produktionsprozesse in der Softwareentwicklung Bücher, die eventuell auch mehrere Ansätze beschrieben? Kann mir da jemand etwas empfehlen (svenson, deine Buchempfehlung hab ich registriert 😉

Gruß
Norman-Timo

Ja, die konkreten Gegenbenheiten sind manchmal frustrierend.

Aber wenn man sich mit agilen Prozessen beschäftigt, neigt man dazu ununterbrochen laut zu denken: "Genauso ist es", "wie mein letzter Kunde", usw.! Die Aha-Erlebnisse sind gewaltig und man kommt nicht umhin, die alte Denkweise in Frage zu stellen.

Richtig ist aber, dass agile Entwicklung noch mehr Disziplin erfordert, also "normale". Als Belohnung fällt der Ballast über Bord. Und vor allem das Management muss voll dahinterstehen. Ohne gutes Projektmanagement geht bei agilen Prozessen gar nix. Und mal ehrlich: Wieviel gute Projektleiter habt ihr in eurem Leben gesehen? Ich einen!

Ich kenne auch nur einen, leider Arbeite ich nicht für Ihn 😭

Aber auch auf der Kundenseite muss sich etwas tun.
Denn bei einem grösseren Projekt muss der Kunde jemanden benennen, der
Entscheidungen treffen kann/darf.
Denn wärend der Laufzeit muss bei unstimmigkeiten zeitnah entschieden werden.

Ich habe letztes Jahr mal eine Anfrage von einem grossen Medizintechnik Haus in Hamburg gehabt.
Die benötigten ein Coaching zu XP/TDD.
Bei den Vorbesprechungen habe ich dann angemerkt, das der Leiter des Support,
also derjenige der am ehesten den tatsächlich benötigten Umfang wissen sollte,
"Der Kunde" sein sollte.
Ihr hättet sehen sollen wie der sich gewunden hat, um von der Verantwortung weg
zu kommen 😉

Da MS SCRUM bevorzugt, solltest Du Dich mal damit beschäftigen, denn Erfahrungsgemäss
setzt sich das durch, was MS macht, wobei hier die Entscheidung garnicht schlecht ist.
http://www.ifi.unizh.ch/req/courses/seminar_ws03/07_Schweitzer_Scrum_Ausarbeitung.pdf

Normal ist heute so oder so, dass eine Applikation zu 75% geschrieben wird und die fehlenden Funktionen in späteren Releasen nachgeschoben werden, weil die Zeit nicht reicht (ist zwar ein Trugschluss, aber was solls).

Am idealsten ist es wenn der Entwickler nichts mit dem Kunden zu tun hat, sondern den Arbietsauftrag von seinem Chef bekommt, es programmiert. Dann hat er das gemacht was von ihm verlangt, und dann ist der, der dann das Pflichtenheft und die Voranalyse gemacht hat der A*** wenn was falsches rauskommt.

(Was heisst eigentlich TDD?)

Original von schaedld
(Was heisst eigentlich TDD?)

Test Driven Development, man siehe auch NUnit

@John Doe
THX für die Ausführung 8)

Mal noch ein kleiner Denkansatz:

Ich finde (wobei ich hauptsächlich alleine programmiere, und keine Kunden habe), daß die "Wiederverwertbarkeit von Code" sowieso oft nur unzureichend gegeben ist. Daher ist es oft sinnvoll, jedes Projekt frisch zu starten. Klar, ein paar Klassen kann man immer verwenden / leicht abändern, aber bei manchen Sachen ist man einfach besser dran, das nochmal neu zu schreiben.

Der Effekt ist, daß man mit jedem Mal besser wird und einiges dazulernt. Meist ist es so, daß man am Anfang eines Projekts richtig gut drauf ist, dann während der Entwicklung merkt man "das hätte ich eigentlich besser SO machen sollen", und wenn das Projekt zu Ende ist, freut man sich schon richtig auf das neue, weil man eben die Erfahrungen gemacht hat und weiß, wie man es beim nächsten Mal angehen würde.

Also oftmals ist es wohl tatsächlich gar nicht so schlecht, einfach alles mit seinem momentanen "Wissensstand" fertigzustellen, ohne großartig über extrem komplex modulare Dinge und Wiederverwertbarkeit und generische Ansätze nachzudenken, denn die "beim nächsten Mal mach ich das auf jeden Fall anders"-Gedanken kommen so oder so.

Ich kapsle alles in einem eigenen wiederverwendbaren Framework....

Aber wir haben auch einen unglaublichen Ausstoss an Programmen welche dann allesamt auf demselben Kernel basieren.

Jo, genau, dann kann man es einfach aufteilen.

Dort wo ich arbeite gibt es auch ein großes Framework, das nennt sich "base", dort sind dann alle Steuerelemente drin, alle Komponenten, alle Events, Commands, was weiß ich, und die spezifischen Sachen werden dann separat gecodet, und diese verwenden dann eben Klassen aus dem "base". Also quasi wie wenn man eine DLL oder eine Lib nimmt.

Sowas ist dann schon sinnvoll, vor allem eben wenn man immer wieder ähnliche Dinge erledigen will und zudem auch ein einheitliches Design (sowohl codetechnisch als auch optisch) haben will.

Original von FZelle
Da MS SCRUM bevorzugt, solltest Du Dich mal damit beschäftigen, denn Erfahrungsgemäss
setzt sich das durch, was MS macht, wobei hier die Entscheidung garnicht schlecht ist.

>

SCRUM ist insofern interessant, dass es ja fast ausschließlich den Management- und Kommunikationsaspekt betont. Das reduziert die Zahl der Menschen, die überzeugt werden müssen. 😉

Auf der anderen Seite muss klar sein, dass ein Veränderung, die nur im Management stattfindet vielleicht nach außen agil erscheint, nach innen jedoch u.U. nicht funktioniert (z.B. mangels TDD). XP nimmt die andere Seite ein und sagt weniger über das Management und dafür mehr über das, was die Entwickler tun sollten. Im Prinzip kann man beides auch gut kombinieren.

SCRUM kann man m.E. dann besonders gut einsetzen, wenn schon Ansätze eines SW-Prozesses existieren und fortbestehen sollen. Außerdem gefallen mir die Metaphern gut ("Sprint").

In der Praxis wirst Du keinen finden, der nicht SCRUM und TDD macht.

Am Anfang versuchen es einige noch mit pairs, aber das lässt meist schnell nach,
aber TDD bleibt.

Ich habe zwar keine Wissenschaftlichen Fakten, allerdings fuehre ich genaue Aufzeichnungen der aenderung meiner Programme (Von wem gefordert, warum, wann, etc..)

Fakt:
Ein bestehendes Programm soll ins Web migriert werden. Es soll genaus aussehen wie die Win Version (Aus dem Jahre 96) da sich sonnst die bereits daran gewohnte Anwender nicht auskennen. Die Programmiersprache soll Classic ASP sein.

Version 1, Fehlerfrei, 75h aufwand inkl dutzend im Browserfenster aufpopender Modaler Divs (Halt genau wie diese echtanwendung)

Kunde meint das nicht ganz das ist was er sich vorgestellt hat. Neue Besprechungen, Konzepte fuer das Design folgten (an die 15h)

Version 2, teilw. Fehlerbehaftet, weil Code von V1 trotzdem verwendet werden soll, teile der Oberflaechenlogik ebenfalls. 150h aufwand.

Bis zur jetzigen Version (2.8.142) wurden kleinere und groeszere Anpassungen, von denen anfangs nicht die rede war durchgefuehrt.

Gesamtaufwand: 580h.

Ich habe Module des Programs so generisch wie moeglich programmiert, und konnte mir trotzdem sogar vlt einige Zeit ersparen.

Btw, jetzt soll das Program auf .Net umgeschrieben werden 😜

Damit wir aber trotzdem schnell auf Aenderungen reagieren koennen haben wir uns alle hier (In meinem Unternehmen) Angewohnt mit MVP zu arbeiten, die Oberflaeche striktest vom Code zu trennen (nicht nur Design sondern auch die Logik ist ein eigener teil) was bei Classic ASP leider nicht so einfach ist.
So kann man doch Aenderungen mit minimalen Aufwand durchfuehren (Natuerlich abhaengig von der Aenderung)