# Codequalität: "Funktioniert" ist nicht genug



## Landei (26. Nov 2012)

Lesenswerter Artikel, den man vielleicht mal dem Chef unter die Nase halten kann:

Codequalität: "Funktioniert" ist nicht genug


----------



## Marco13 (26. Nov 2012)

Ja, da steht vieles drin, was vielen schon klar ist. Allerdings sind die dort kritisierten Strukturen und Ansichten teilweise so verfestigt, dass einiges, was dort als Gegenmaßnahmen gefordert wird, schon fast bemitleidenswert idealistisch wirkt. Spätestens, wenn "die Mehrheit" der Entwickler an einem Projekt in bezug auf bestimmte elementare Grundlagen ein Niveau an den Tag legt, das weit unter dem liegt, was notwendig ist, um _überhaupt_ über das _reden_ zu können, was man unter dem breiten Begriff "Softwarequalität" zusammenfassen kann, gibt es einfach keine Punkte, wo man sich damit "einhaken" kann. Angedeutet wurde das dort auch 


> Sicher gibt es so etwas wie „zu viel“ Qualität. In der Realität bleibt leider zu beobachten, dass ein Qualitätsniveau, das diese Sorge rechtfertigen würde, in den meisten Fällen nicht vorliegt



Zum Glück kann ich mich inzwischen (bildlich als auch wörtlich) von solchen Dingen Distanzieren - d.h. ich habe meine Überzeugungsversuche an manchen Stellen aufgegeben, und antizipiert, dass manche Leute bei der Entwicklung nur 2 Dinge berücksichtigen:
- Es muss funktionieren
- Es muss schnell fertig sein
Dass man die Karre damit immer weiter in den Dreck fährt, ist ab einem bestimmten Punkt egal - spätestens, wenn ein Projekt "Überschuldet" ist, was hier mal bedeuten soll, dass ein quasi-komplettes _Neuschreiben_ weniger Zeit erfordern würde, als zu versuchen, an der bestehenden Codebasis noch etwas geradezubiegen.


----------



## Sym (26. Nov 2012)

Die technische Schuld ist aber nicht immer nur dem "Chef" nicht bewusst, sondern auch einigen Entwicklern. Ich erlebe häufig Leute, die "mal eben schnell" was fertig kriegen wollen oder das Schreiben von Unit-Tests (oder allgemein Tests) als obsolet empfinden.

Ich habe meine Überzeugungsversuche auch an manchen Stellen aufgegeben.


----------



## Bernd Hohmann (25. Dez 2012)

Marco13 hat gesagt.:


> d.h. ich habe meine Überzeugungsversuche an manchen Stellen aufgegeben, und antizipiert, dass manche Leute bei der Entwicklung nur 2 Dinge berücksichtigen:
> - Es muss funktionieren
> - Es muss schnell fertig sein



Es gibt noch einen dritten Punkt: immer hinten anflicken um die bestehende Codebasis am Laufen zu halten. Refactoring, Modularisierung etc.. könnte ja neue Fehler bringen weil existierender Code überarbeitet werden muss.

Bernd


----------



## Marco13 (26. Dez 2012)

Ja, wie auch im anderen Thread ist hier wohl die Rede von dem, was gelegentlich als Lava flow (programming) - Wikipedia, the free encyclopedia bezeichnet wird.


----------



## Landei (26. Dez 2012)

Ich habe inzwischen in Inspired von Marty Cagan die Empfehlung gelesen, regulär 20% (im Notfall bis zu 50%) der Zeit für die "Sauberkeit" der Codebasis zu investieren. Er schildert Beispiele, wo Featuritis und Vernachlässigung von "Aufräumarbeiten" Firmen wie eBay an den Rand des Ruins gebracht hat.


----------



## bygones (26. Dez 2012)

Landei hat gesagt.:


> Ich habe inzwischen in Inspired von Marty Cagan die Empfehlung gelesen, regulär 20% (im Notfall bis zu 50%) der Zeit für die "Sauberkeit" der Codebasis zu investieren. Er schildert Beispiele, wo Featuritis und Vernachlässigung von "Aufräumarbeiten" Firmen wie eBay an den Rand des Ruins gebracht hat.


die 20% sind an sich schon aelter. Google hat es mal eingefuehrt um seinen Mitarbeitern Freiraum zu geben sich waehrend der Arbeit fortzubilden bzw sich zu verbessern.


----------



## maki (26. Dez 2012)

Landei hat gesagt.:


> Ich habe inzwischen in Inspired von Marty Cagan die Empfehlung gelesen, regulär 20% (im Notfall bis zu 50%) der Zeit für die "Sauberkeit" der Codebasis zu investieren. Er schildert Beispiele, wo Featuritis und Vernachlässigung von "Aufräumarbeiten" Firmen wie eBay an den Rand des Ruins gebracht hat.


Gibt es diese Beispiele auch im Netz?

Ich kenne diese Situation des "Architekturverfalls" auch aus Erfahrung, wie jeder Entwickler der nicht nur ein Projekt schreibt sondern danach auch bleibt um es zu warten/weiterzuentwickeln. 

In meiner neuen Firma ist es auch wieder so, die Entwickler haben das Problem schon erkannt, aber was fehlt (wie immer) sind Argumentationen die man auch im Management versteht.
Für eine best. Zeit gar keine neuen Features bzw. weniger zu liefern aber dafür 3 dutzend Entwickler arbeiten zu lassen während der Markt immer nach weiteren Features schreit muss man besser formulieren könnnen als ich das gerade gemacht habe.. :bloed:


----------



## Bernd Hohmann (26. Dez 2012)

maki hat gesagt.:


> Gibt es diese Beispiele auch im Netz?



Eher nicht, denn so gross war das Problem nicht (es gab schon schlimmere Softwarekatastrophen wie zb. Sainsbury 2003, Toll Collect, Bundesagentur für Arbeit...) 

eBay (1995 gegründet) hatte 1999 genau 2 Probleme: sie kauften das gerade erst gegründete deutsche Auktionshaus Alando um Fuß in Europa zu fassen und der Umsatz stieg im gleichen Zeitraum von 85mio USD auf 225mio USD. Es sollten Features von Alando integriert und zum anderen die Skalierbarkeit des Systems verbessert werden. Man bräuchte mehr erfahrene Entwickler, die aber aus Zeitmangel nicht eingewiesen werden können. Cagan war damals in der richtigen Position, hatte das richtige Praxiswissen und vor allem das Vertrauen des Managements so dass er durchsetzen konnte dass das gesamte Team mit anfangs nur 60%, später 80% an Neuentwicklung ausgelastet wird und den Rest mit Refactoring und Pflege verbringt.



maki hat gesagt.:


> Ich kenne diese Situation des "Architekturverfalls" auch aus Erfahrung, wie jeder Entwickler der nicht nur ein Projekt schreibt sondern danach auch bleibt um es zu warten/weiterzuentwickeln.



Wenn Du ein Projekt permanent weiterentwickelst und wartest, sollte eigentlich immer Zeit für bisserl Putzarbeit sein. Früher hat man sich dazu konspirativ in der Raucherecke getroffen (die Nichtraucher gesellten sich solidarisch dazu), heute stellt man fest dass die 1:1 Umsetzung auf die weniger gesundheitschädliche Kaffeebar einfach nicht funktionieren will.



maki hat gesagt.:


> In meiner neuen Firma ist es auch wieder so, die Entwickler haben das Problem schon erkannt, aber was fehlt (wie immer) sind Argumentationen die man auch im Management versteht.
> Für eine best. Zeit gar keine neuen Features bzw. weniger zu liefern aber dafür 3 dutzend Entwickler arbeiten zu lassen während der Markt immer nach weiteren Features schreit muss man besser formulieren könnnen als ich das gerade gemacht habe.. :bloed:



Wenn die Hierarchie über den Entwicklern nicht selber mal Software produziert hat, kann man die reine Notwendigkeit für solche Arbeiten kaum nach oben vermitteln. Auf der anderen Seite muss es sich auch für die GL rechnen und in Zahlen ausdrücken lassen. Da von einem Entwickler kein kaufmännisches Denken erwartet wird hat man ein Mexican Standoff: wer zuerst schiesst, hat verloren.

Hilfe bringen hier Unternehmensberater. Die sagen zwar kaum was anderes als Du, können das aber auf Augenhöhe vermitteln und noch bisserl mehr dazu sagen. Zb. dass man diese Zeitreserve von 20% als gleitende Rückstellungen gewinnmindernd ansetzen kann. Oder alternativ als "Forschung und Entwicklung" auf der Aktivseite verbucht und damit den Bilanzwert erhöht. Sollte Deine Firma in Ettlingen sitzen, sehe ich da eher keine Chance 

Bernd


----------



## Landei (27. Dez 2012)

bygones hat gesagt.:


> die 20% sind an sich schon aelter. Google hat es mal eingefuehrt um seinen Mitarbeitern Freiraum zu geben sich waehrend der Arbeit fortzubilden bzw sich zu verbessern.



Das ist etwas anderes. Für solche Sachen sollte wenn möglich auch Zeit eingeräumt werden, die aber nicht für die genannten Aufräumarbeiten draufgehen sollte.


----------



## maki (29. Dez 2012)

@Bernd Hohmann
Danke für die Buchinfo 
Werde ich dann doch wohl kaufen & lesen müssen.

Ein "Unternehmensberater" würde uns nicht helfen (haben die das jemals?). 
Persönlich habe ich die Einstellung, wenn die Geschäftsführung bzw. "das Management" dem Chefentwickler nicht vertraut bzw. nicht auf Augenhöhe kommunizieren kann, hilft da auch kein Consultant, dann hilft nur die Firma wechseln. Zum Glück ist das heutzutage sehr einfach 

Das ist aber gar nicht die Situation hier.
Es geht mehr darum, "Argumentationshilfen" etc. dem Chefentwickler zur Verfügung zu stellen.

Bilanzwerte etc. sind in einem gerade aufgekauften Startup auch IMHO nicht so relevant (vor allem weil es um eine  heissumkämpfte Branche geht), Marktanteile bzw. ein vergrößerter Kundenstamm haben da höhere Priorität -> "Featuritis"
Kann mich natürlich irren.
Die Geschichte mit "Alando einbinden" hat btw. sehr große parallelen.

Dadurch, dass die Entwickler nicht alle an einem Standort sind, fällt es schwer einen "gemeinsamen Sinn für Qualität" zu etablieren, für manche Entwickler scheint es ein Sport zu sein möglichst viele Bugs/Issues/Requests abzuarbeiten, egal wie der Code bzw. das ganze System danach aussehen.


----------



## Bernd Hohmann (29. Dez 2012)

maki hat gesagt.:


> @Bernd Hohmann
> Danke für die Buchinfo
> Werde ich dann doch wohl kaufen & lesen müssen.


Amazon 7 EUR als E-Book



maki hat gesagt.:


> Ein "Unternehmensberater" würde uns nicht helfen (haben die das jemals?).


Kommt drauf an. Kleinere Berater die selber aus der Branche kommen sind ganz gut dafür geeignet, zwischen Entwicklern und GL zu vermitteln. Grosse Beratungshäuser kauft man nicht wegen ihrer Qualität sondern ihrer Connections.



maki hat gesagt.:


> Persönlich habe ich die Einstellung, wenn die Geschäftsführung bzw. "das Management" dem Chefentwickler nicht vertraut bzw. nicht auf Augenhöhe kommunizieren kann, hilft da auch kein Consultant, dann hilft nur die Firma wechseln. Zum Glück ist das heutzutage sehr einfach



Das ist eben das Problem der Branche: die Mitarbeiter wechseln so schnell, dass die og. 20% Luft für Codequalität in der Einarbeitung der neuen Programmierer verbraucht werden. Und denen ist nach paar Wochen unter Druck die Lust vergangen ordentlich zu Arbeiten. Da wird nicht mehr gefragt "haben wir dafür schon was im Code?" sondern es wird die dritte obskure Library zum Thema eingebunden.



maki hat gesagt.:


> Bilanzwerte etc. sind in einem gerade aufgekauften Startup auch IMHO nicht so relevant (vor allem weil es um eine  heissumkämpfte Branche geht), Marktanteile bzw. ein vergrößerter Kundenstamm haben da höhere Priorität -> "Featuritis"



Featuritis hat selten für den Erfolg einer Sache beigetragen. Man muss den USP herausarbeiten und nur den massiv promoten.



maki hat gesagt.:


> für manche Entwickler scheint es ein Sport zu sein möglichst viele Bugs/Issues/Requests abzuarbeiten, egal wie der Code bzw. das ganze System danach aussehen.



Findet man oft bei Freelancern - Codequalität steht da nur selten im Vertrag 

Bernd


----------



## KuhTee (31. Dez 2012)

Bernd Hohmann hat gesagt.:


> Wenn Du ein Projekt permanent weiterentwickelst und wartest, sollte eigentlich immer Zeit für bisserl Putzarbeit sein. Früher hat man sich dazu konspirativ in der Raucherecke getroffen (die Nichtraucher gesellten sich solidarisch dazu), heute stellt man fest dass die 1:1 Umsetzung auf die weniger gesundheitschädliche Kaffeebar einfach nicht funktionieren will.


Ein Knackpunkt ist da doch weniger die Raucherecke/Kaffeebar, sondern der personelle Werdegang des Projekts. Wir haben hier Projekte im Unternehmen, die haben teilweise mehrfachen Austauch des kompletten Entwicklerteams hinter sich, die sind da nur noch am "Hauptsache es läuft noch irgendwie". Und jedes neue Feature bringt die Gefahr eines kompletten Zusammenbruchs mit sich.
Auf der anderen Seite bin ich selbst seit 5 Jahren bei einem Projekt dabei, anfangs als "Kern"-Entwickler, inzwischen als Teamleiter. Mir fällt es eigentlich nicht schwer, immer wieder Zeit für Refactoring frei zu machen, und unser Unternehmen ist da das totale Gegenteil von solch eher positiven Beispielen wie zB Google. Und 90% unserer Entwickler haben selbst die Einstellung "Hauptsache es läuft".
Es braucht mMn also vor allem einen "Mastermind", der das Projekt im Überblick hat. Dieser hat es dann in der Regel auch wesentlich einfacher, entsprechend Zeit für Codepflege bereitzustellen. Wenn aber die Projektleitung und wichtige Entwickler alle 2 oder 3 Jahre wechseln und auch das Wissen in ein anderes Unternehmen wechselt, dann kann der Code noch so gut und noch so umfangreich dokumentiert sein, die Qualität leidet darunter. Und zwei, drei mal oder sogar noch öfter einen "Mastermind" zu finden, der die Projektvision genau so fortführt klappt in den meisten Fällen sowieso nicht. Und schon gehts bergab.


----------



## deetee (31. Dez 2012)

@KuhTee
Ich stimme dir in den meisten Ausführungen absolut zu, z.B. denke ich auch, dass ein "Mastermind" einem Projekt und der Firma auf gewisse Zeit gut tut, manchmal auch als "Master Ressource" bezeichnet in Projektmanagementmethoden. Es gibt dann oft das Risiko, dass die Master Ressource extrem überlastet ist, was immer ein Zeichen von Abhängigkeit ist. Wahrscheinlich ist der Software-Architekt die richtige Berufsbezeichnung für die Rolle "Mastermind".

Aus der Sicht der Firma ist eine solche zentrale Abhängigkeit natürlich weniger erfreulich, denn Mitarbeiterfluktuation ist immer ein Hauptrisiko in Projekten.

Ich sehe das letztlich so, je flexibler die gesamte Entwicklung aufgestellt ist, d.h. je weniger die Performanz und Qualität im Projekt sinkt, wenn Mitarbeiter neu hinzukommen oder vorhandene gehen, desto mehr spricht das für ein gutes Management (Infrastruktur, QA, Technologie-Mgmt, Wissensmanagement, Release-Mgmt, Entwicklungsprozess, etc.) in der Entwicklung.

Ich persönlich definiere z.B. meine Arbeitsqualität so: Je schneller andere Entwickler mit meiner Arbeit zurechtkommen, desto besser habe ich sie gemacht.

Es ist für mich nicht befriedigend, wenn ich der einzige bin, der in akzeptabler Zeit das Projekt weiter bearbeiten kann. Manchen Entwicklern reicht das jedoch aus, und man muss dann oft in erstaunte Gesichter von Vorgesetzten blicken, wenn man als neuer verantwortlicher Entwickler seine Aufwandschätzungen abgibt. Es wird nur selten ausgesprochen, aber man merkt dann, dass der Chef durchaus denkt: "Der Herr X hat das aber immer viel schneller hinbekommen, war wohl doch ein guter Mann."
Dabei sollte in den meisten Fällen der Chef froh sein, so einen "guten" Mann verloren zu haben, der keinen Wert auf Standardisierung, Automatisierung, Architektur und Code Qualität gelegt hat.

Ich habe schon den Hinweis von Kollegen aus anderen Bereichen gehört, dass man sich so leicht ersetzbar macht. Das ist auch richtig, denn das ist das Ziel! 
Allerdings nicht hinsichtlich einer Kündigung, sondern zwecks Flexibilität in der Ressourcenverteilung bei vielen Projekten, Urlaubszeiten und Rollenverteilung im Unternehmen.
Wer nach diesem Ziel strebt - sich ersetzbar zu machen - der sichert damit eher seinen Arbeitsplatz, meiner Meinung nach.


----------



## Phash (7. Jan 2013)

Bei uns ist es auch immer das gleiche:
Hauptsache es laeuft irgendwie, hauptsache es hat "erstmal" keine groeberen Fehler und kann released werden.
Dann wird halt Bugfixing betrieben...

Im letzten Projekt haben wir in einem kleinen Team komplett auf CleanCode gesetzt, haben uns Zeit fuer Reviews genommen, Tests geschrieben und 2 von 3 Leuten kamen erst von der Uni und hatte null praxiserfahrung.

Das Projekt hat statt 4-6 Monate knapp 10 Monate gedauert  - was aber auch (natuerlich ) der Fachabteilung anzulasten ist, die dauernd ihre Ideen gewechselt hat, worauf wir, dank unseres guten Designs, immer schnell reagieren konnten.

Da wir aber laenger gebraucht haben, als geplant, war mein Chef sauer und will diesen Kram nicht, ihm reicht, wenn es laeuft.

Im grossen Projekt in unserer Abteilung sind nur alte Hasen, hauptsache es laeuft Menschen. Kein CleanCode, wenig Refactoring, nur fixing und implementierung- ab und zu mit grossen Umbauten, die echt erschreckend wirken (Klassen mit 1-5k Zeilen Code sind keine Seltenheit, Methoden mit 3-5 Bildschirmseiten auch nicht)

Die machen aber einen guten Job, aus Sicht meines Chefs - obwohl die auch schon 10% hinter dem Zeitplan haengen und noch nicht im Test sind - das Produkt aber spaetestens im Sommer laufen muss


----------



## Bernd Hohmann (7. Jan 2013)

KuhTee hat gesagt.:


> Es braucht mMn also vor allem einen "Mastermind", der das Projekt im Überblick hat. Dieser hat es dann in der Regel auch wesentlich einfacher, entsprechend Zeit für Codepflege bereitzustellen. Wenn aber die Projektleitung und wichtige Entwickler alle 2 oder 3 Jahre wechseln und auch das Wissen in ein anderes Unternehmen wechselt, dann kann der Code noch so gut und noch so umfangreich dokumentiert sein, die Qualität leidet darunter. Und zwei, drei mal oder sogar noch öfter einen "Mastermind" zu finden, der die Projektvision genau so fortführt klappt in den meisten Fällen sowieso nicht. Und schon gehts bergab.



An dieser Stelle sollte man sich selber fragen, ob die "Projektvision" so klar in Code gegossen wurde dass auch ohne Mastermind eine sinnvolle Weiterentwicklung- und Pflege möglich ist.

Böse gesagt kann man alle die ganzen Ratgeber für ordentliches Programmieren incl. der meissten höher abstrahierten Patterns zum Altpapier geben weil sie nichts darüber aussagen wie man eine "wirkliche" Applikation schreibt. Das ist so ähnlich wie Fahrradfahren über ein Lehrbuch der Mechanik und Metallbearbeitung zu erlernen.

Bernd


----------



## KuhTee (7. Jan 2013)

Bernd Hohmann hat gesagt.:


> An dieser Stelle sollte man sich selber fragen, ob die "Projektvision" so klar in Code gegossen wurde dass auch ohne Mastermind eine sinnvolle Weiterentwicklung- und Pflege möglich ist.


Natürlich ist sie das. Wenn ein kompetenter Mastermind das Projekt vorangebracht hat, dann ohne Frage. Die Frage die sich da vielmehr stellt: Wie lange? Keine Ahnung in welchen glücklichen Beschäftigungsverhältnissen du bisher standes, aber nach meiner Erfahrung arbeiten deutlich mehr als 50% der Entwickler nach der Devise "Funktioniert ist genug". Wenn du also ein gutes >500k Zeilen Programm in die Hände von zB 7 oder 8 Leuten ohne Mastermind gibst, dann hast du entweder ein Team von guten Leuten die sich selbst organisieren können oder nach 6 Monaten ein ziemliches Chaos im Code.


----------



## Bernd Hohmann (8. Jan 2013)

KuhTee hat gesagt.:


> Natürlich ist sie das. Wenn ein kompetenter Mastermind das Projekt vorangebracht hat, dann ohne Frage. Die Frage die sich da vielmehr stellt: Wie lange?



Wie ich es formuliert hatte: wenn das Mastermind das vorher ordentlich festgezurrt hat sind Erweiterungen im Sinne des "Masters" völlig stringent und ohne irgendwelches Chaos im Source zu verbreiten möglich.

Dass das noch niemand geschafft hat ist lediglich ein Beweis für die Untauglichkeit der ganzen teuren Fachbücher und der Zeit, die man mit dem Studium irgendwelcher Patterns verbracht hat.



KuhTee hat gesagt.:


> Keine Ahnung in welchen glücklichen Beschäftigungsverhältnissen du bisher standes, aber nach meiner Erfahrung arbeiten deutlich mehr als 50% der Entwickler nach der Devise "Funktioniert ist genug".



Halte ich für wirtschaftlich.

Der Punkt ist einfach der, dass der Kunde günstig Funktionalität möchte die ihm wirtschaftlichen Erfolg gibt. Ich habe Kunden, die auch mal 20.000 EUR in Refactoring investieren damit es später besser fluppt. Das ist aber eher Interessant in Umgebungen, wo man mit 64k für die Linkersegmente CODE und DATA auskommen muss - da tut eine Überarbeitung not.

Beim Rest  - da bin ich ehrlich zu mir selber - ist vorsichtiges Anflicken für den Kunden auch langfristig effizienter weil es im "bitte code nur hier einfügen" und damit höchstmöglicher Disziplin führt.

Bernd


----------



## deetee (8. Jan 2013)

Letztlich ist es faktisch so, dass beide Philosophien und Ideologien ("Funktioniert ist genug" vs. "Funktioniert ist nicht genug") sich durchaus in der Praxis bewiesen haben und ich würde sogar sagen, beide haben ihre Einsatzzweck. Ein Projekt welches nach einem Jahr wieder weg vom Markt sein soll (Bsp. Ereignisgebundene Projekte, Marketing Projekte, etc.) muss nicht den höchsten Ansprüchen von sagen wir mal Clean Code genügen.

Auf der anderen Seite würde ich es als fahrlässiges Verhalten ansehen, wenn man diese Einstellung auch für lanfristige Projekte vertritt. Es ist Normalität, dass Software mit der Zeit von vielen unterschiedlichen Personen angefasst werden muss, und das Risiko von Patch-Work Software ist dann sehr hoch. Nach 3 Jahren und 20 Entwicklern ist das Projekt aus technischer Sicht an die Wand gefahren! Dann fangen die Probleme, die man in der Vergangenheit brav selbst gesäht hat, sich auch wirtschaftlich auszuwirken. Fehleranfälligkeit und Erweiterbarkeit leiden in erster Linie unter schlechtem Code. Die indirekt wirtschafltichen Folgen sind sinkende Motivation der Mitarbeiter bis hin zum Image- oder sogar Kundenverlust. Egal welchen Verlauf so ein Projekt nimmt, es wird immer schwierig bis unmöglich sein zu beweisen, dass eine saubere Code Basis zu einem besseren Stand nach 3 Jahren geführt hätte.

Der technische Laie hat für Code keinen Blick, er sieht nur, dass die Software auch nach 3 Jahren noch läuft. Ein Laie wird niemals einen höheren Anspruch an Software haben, das ist auch in anderen Bereichen so. Es fehlt das Wissen wie es besser sein könnte, und der Bedarf wird nicht gesehen, weil der Blick dafür ebenfalls fehlt.
Diese Eigenschaften von Software werden im Artikel als "perfide Eigenschaften" betitelt, weil "Software nicht anfängt zu stinken, nicht klappert, nicht schimmelt, etc."

Wirtschaftlichkeit ist das Nummer 1 Argument von der Fraktion "Funktioniert ist genug". Ich denke dieses Argument ist richtig für die erwähnten "Kurzprojekte" oder Prototypen. Sobald das Projekt einige Jahre oder Jahrzehnte überleben soll zahlt man spätestens ab dem 5. Jahr den ersten Euro mehr, den man durch eine qualitätsbewusste Code Basis wahrscheinlich erst in weiteren 5 Jahren bezahlt hätte.

Das Problem ist, dass man mit so einem Argument "Chef, in 3-5 Jahren wird man wahrscheinlich anfangen drauf zu zahlen" nur ein stilles Nicken bekommt, und es dann wieder vergessen ist. Schließlich kann keiner in die Zukunft blicken.
Meine Hoffnung ist allerdings, dass diese qualitätsbewusste Mentalität sich in 5 -8 Jahren auch in den oberen Hierarchieebenen gefestigt hat, da in diesen Positionen dann die heutigen Entwicklern sitzen werden...


----------



## Landei (8. Jan 2013)

Phash hat gesagt.:


> Das Projekt hat statt 4-6 Monate knapp 10 Monate gedauert  - was aber auch (natuerlich ) der Fachabteilung anzulasten ist, die dauernd ihre Ideen gewechselt hat, worauf wir, dank unseres guten Designs, immer schnell reagieren konnten.



Wenn man schon die Wünschdirwas-Runden der Fachabteilung nicht stoppen kann, ist es immer noch gut, den jeweiligen Stand einzufrieren und auch "auszuliefern". Dann hat man eben nach 4 Monaten eine "Version 1", und sieht deutlich, was zwischendurch und danach dazugekommen ist. Dauert dann insgesamt vielleicht 12 Monate, ist aber dem Chef wesentlich besser zu verkaufen - der dann eben klarer sieht, wo der Aufwand wirklich herkommt. Und man hat die Chance, dass es im nächsten Projekt besser läuft.


----------



## Phash (12. Jan 2013)

Naja war ein MigrationsProjekt, und ein Parallelbetrieb sollte vermieden werden...

dafür ist es momentan so ziemlich die einzige Anwendung in unserem Aufgabenbereich, das problemlos läuft, bisher bugfrei ist (nichts gemeldet wurde, und die FA hat eigentlich immer schnell gemeldet) und lediglich noch ein paar Ründchen wünschdirwas gebrauchen könnte...


----------



## Altairograph (14. Sep 2013)

Ist sowas nicht auch sehr vom Kunden abhängig? Wenn der Kunde einem nicht genug Zeit gibt kann man so sehr den Code gut machen wollen wie man will, aber wenn die Zeit dazu im Arbeitsplan nicht vorgesehen ist wie soll dass dann gehen? Ich finde man sollte prinzipiell beide Arbeitsweisen beherrschen weil man sich wohl darauf einstellen muss beide in der Praxis anwenden zu müssen.


----------



## deetee (15. Sep 2013)

Das ist richtig, Deadlines oder Budget wirken sich auf die Qualität der Software aus. Man muss Abstriche machen.

Der Umfang der Abstriche ist aber abhängig von der Erfahrung und Routine, die man selbst und das Team mitbringt. In einem eingespielten Team von erfahrenen Entwicklern, kann man die Qualität natürlich trotz Zeitdruck recht hochhalten.

Ich würde aber behaupten dazu braucht es schon mind. 5 Jahre Berufserfahrung und eine professionelle/leidenschaftliche Einstellung zur Softwareentwicklung. Und diese Spezies an Entwicklern ist selten. Wer in einem solchen Team arbeitet kann sich glücklich schätzen. Das ist ungefähr die Formel-1 der Softwareentwicklung.


----------

