Lesenswerter Artikel, den man vielleicht mal dem Chef unter die Nase halten kann:
Codequalität: "Funktioniert" ist nicht genug
Codequalität: "Funktioniert" ist nicht genug
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
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
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.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 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:
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.
Amazon 7 EUR als E-Book@Bernd Hohmann
Danke für die Buchinfo
Werde ich dann doch wohl kaufen & lesen müssen.
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.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
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"
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.
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.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.
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.
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.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".
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.