Auf mich hört ja keiner ...

[Alexander (HH)]

Moin Moin!

Vor ungefähr drei Jahren hab ich einen neuen Arbeitgeber gefunden. Mein neuer Job sollte Pflege und Weiterentwicklung eines alten Systems sein, nichts weltbewegendes. Kleiner Haken an der Sache war, dass ich die Laufzeitumgebung bisher nicht kannte. Aber alles kein großes Ding, "yet another C derivate", ein paar Mausschubser-Tools, eine bekannte relationale Datenbank dahinter, und viel Sourcecode von $VORGÄNGER.

$VORGÄNGER war noch etwa einen Monat parallel zu mir beschäftigt, eigentlich als Zeit für die Übergabe geplant. Nur leider hat sich $VORGÄNGER dermaßen in völlig unrealistische Terminzusagen verstrickt, dass er den ganzen Monat lang von früh morgens bis spät in die Nacht gecodet hat, um irgendeinen Termin zu halten. Eine "eingearbeiteter" $KOLLEGE sollte mir das System erklären. Schade nur, dass $KOLLEGE davon noch weniger Ahnung hatte. De facto gab es keine brauchbare Übergabe.

Der Monat war weg, $VORGÄNGER auch, $KOLLEGE hat keinen Plan, aber die Terminzusagen blieben. Glücklicherweise hab ich schon beim Vorstellungsgespräch oft und deutlich genug gesagt, dass es etwas dauern kann, sich in ein altes System einzuarbeiten. Termine wurden verschoben, ich hab mit kleinen Dingen angefangen und feststellen müssen, dass $VORGÄNGER von Software-Entwicklung exakt NULL Plan hat. Modularität, Kapselung, Funktionen, Schleifen, Fehlerprüfungen - alles Fremdworte für $VORGÄNGER. Ebenso wie Quelltextverwaltung, Issue-Tracking. Von Pflichtenheften oder gar Spezifikationen hat $VORGÄNGER auch noch nie etwas gehört. Aber von Copy&Paste. Man kann tatsächlich riesige Programme mit unglaublich vielen Funktionen fast ausschließlich durch Copy&Paste aus einer riesigen, gescheiterten Projektruine bauen. Nicht schmerzfrei, definitiv nicht schön, aber $VORGÄNGER war in der Hinsicht komplett schmerzbefreit und bar jeglicher Esthetik.

Es kam wie es kommen mußte, man konnte am System fast nichts ändern, ohne dass die Änderungen sich wie ein Tsunami auf ein Kartenhaus auswirkten. Termine waren völlig unhaltbar, die Code-Basis konnte man eigentlich nur in ein Stahlfass einschweißen, mit Beton auffüllen und möglichst tief verbuddeln. $KOLLEGE war keine Hilfe, eher die kleinere Version von $VORGÄNGER. Das führte irgendwann zu Diskussionen in immer hochrangiger besetzten Meetings, bei denen von mir immer wieder die selbe Aussage kam: "Aufwand schätzen unmöglich, Code von $VORGÄNGER ist unbrauchbar und unwartbar, eigentlich müßte man das komplett neu schreiben". Das wollte keiner hören, ich sei "zu akademisch".

Irgendwann nahm das Mutterunternehmen uns das Projekt weg, suchte und verschliss einen externen Dienstleister, wandte sich dann in ziemlicher Verzweiflung an den Hersteller der Laufzeitumgebung, und werkelte mit dem über zwei Jahre an dem Projekt. Neulich wurde uns der aktuelle Zwischenstand präsentiert. Wenig optische Änderungen, ein paar neue Funktionen, hinter den Kulissen offensichtlich ein wenig aufgeräumt. Und folgende wunderschöne Aussage, die ganz stolz von den hochrangigen Leuten gemacht wurde:

"Das ist fast alles neu geschrieben worden, da ist kein Code mehr von $VORGÄNGER drin."

Ach, war das schön! Das "ich hab's doch gleich gesagt" kam mir nicht über die Lipppen, aber die Kollegen aus den früheren Diskussionsrunden wußten ganz genau, was mir in dem Moment durch den Kopf ging. Das lag vielleicht auch am extrem breiten Grinsen. ;-)

Alexander

[suit]

Ach, war das schön! Das "ich hab's doch gleich gesagt" kam mir nicht über die Lipppen, aber die Kollegen aus den früheren Diskussionsrunden wußten ganz genau, was mir in dem Moment durch den Kopf ging. Das lag vielleicht auch am extrem breiten Grinsen. ;-)

Kenn ich - ich sollte eine Stichliste führen, das passiert hier öfter :)

Nur dass bei mir $VORGAENGER eine variable Variable (zum Array hats nicht gereicht) ist :D

[Der Martin]

Hallo,

Ach, war das schön! Das "ich hab's doch gleich gesagt" kam mir nicht über die Lipppen, aber die Kollegen aus den früheren Diskussionsrunden wußten ganz genau, was mir in dem Moment durch den Kopf ging. Das lag vielleicht auch am extrem breiten Grinsen. ;-)

geht mir zwar seltener so, aber ich kenne die Situation im Grunde auch.

Kenn ich - ich sollte eine Stichliste führen, das passiert hier öfter :)
Nur dass bei mir $VORGAENGER eine variable Variable (zum Array hats nicht gereicht) ist :D

Heißt das, bei dir gibt's einen Ex-Kollegen, der einen kennt, der sich damit auskennt? :-)

Ciao,
 Martin

[suit]

Kenn ich - ich sollte eine Stichliste führen, das passiert hier öfter :)
Nur dass bei mir $VORGAENGER eine variable Variable (zum Array hats nicht gereicht) ist :D

Heißt das, bei dir gibt's einen Ex-Kollegen, der einen kennt, der sich damit auskennt? :-)

Ich sagte nicht "Mehrdimensionales Array" :)

Ich meinte damit eher mehrere Vorgänger die gemeinsam wirre dinge gemacht haben :D

[Der Martin]

Hi,

Kenn ich - ich sollte eine Stichliste führen, das passiert hier öfter :)
Nur dass bei mir $VORGAENGER eine variable Variable (zum Array hats nicht gereicht) ist :D
Heißt das, bei dir gibt's einen Ex-Kollegen, der einen kennt, der sich damit auskennt? :-)
Ich sagte nicht "Mehrdimensionales Array" :)

nein, das wären ja mehrere Vorgänger im gleichen Zeitraum, von denen jeder wieder mehrere Vorgänger hatte.

Ich meinte damit eher mehrere Vorgänger die gemeinsam wirre dinge gemacht haben :D

Hm. Also entweder $VORGAENGER[] oder doch eher $VORGAENGER->vorgaenger->vorgaenger.

Ciao,
 Martin

[Schuer]

dass $VORGÄNGER von Software-Entwicklung exakt NULL Plan hat.

Was für eine NULL.

Viele Grüße
_Dirk

[Steel]

Moinsen!

:) Das kommt mir teilweise echt bekannt vor. Schoen, dass Du mal ordentlich grinsen durftest.

[T-Rex]

Du erzählst gerade meine Geschichte, nur durfte ich den Code selbst neu schreiben :).
Wobei man bei "gutem" Code natürlich streiten kann. Ich denke jedes System hat seinen Pferdefuss.

Gruß
Der Codecleaner
T-Rex

[Alexander (HH)]

Moin Moin!

Du erzählst gerade meine Geschichte, nur durfte ich den Code selbst neu schreiben :).
Wobei man bei "gutem" Code natürlich streiten kann.

Natürlich. Man kann sich ja schon bei "Hello World" wunderbar über Code-Style und fehlende Fehlerprüfungen streiten. (Ja, puts() / printf() / write() KANN fehlschlagen, und ein typisches helloworld.c ignoriert das in aller Regel.)

Ich denke jedes System hat seinen Pferdefuss.

Richtig. Mal mehr, mal weniger, aber ganz ohne Macken ist ein System größer als "Hello World" eigentlich nie.

Wenn der Code aber aus mehreren 100.000 Zeilen verteilt über hunderte bis tausende Dateien und einige Pseudo-Datenbanken besteht, keinerlei Dokumentation vorhanden ist, und jedes einzelne Stück Code nur aus Pferdefüssen besteht, dann kann man dem System nur noch den Gnadenschuß geben oder eben mit sehr viel Geduld und Aufwand intensives Refactoring betreiben und so den kaputten Code nach und nach austreiben.

Angesichts diverser "Besonderheiten" der Laufzeitumgebung war mein Favorit ganz klar die zweite Variante; die hätte nämlich den Charme gehabt, dass man sich nicht mehr mit der Laufzeitumgebung herumärgern müßte.

Ein paar meiner persönlichen Highlights:

* Datei öffnen kann fehlschlagen. Man erfährt daber nur, dass das Öffnen nicht funktioniert hat, nicht aber, warum. Ob Platte voll, falscher Name, oder zu wenig Rechte, alles was das System meldet ist "funzt nicht™". Analoges gilt für sehr, sehr viele andere Funktionen. Man stelle sich C ohne errno vor.

* Editor, Compiler und Dokumentation sind sich nicht darüber einig, wo Kommentare anfangen und wo sie aufhören. Nur weil der Editor ein Stückchen Code als auskommentiert ansieht, muß der Compiler den augenscheinlich auskommentierten Code noch lange nicht ignorieren.

* Der SQL-(Pre-)Parser, der SQL-Statements für die Datenbank aufbereiten (vor allem Parameter / Variablen identifizieren) soll, paßt weder zur Datenbank noch zur Dokumentation und sorgt regelmäßig für völlig wirre Fehlermeldungen und Abstürze.

* Das DB-Interface ignoriert unter bestimmten Umständen SQL-Kommandos komplett, ohne Fehlermeldung, ohne Warnung. Das SQL-Kommando scheint für das Programm erfolgreich ausgeführt worden zu sein.

* Mindestens zwei inkompatible Typensysteme: Eines für Variablen, eines für Funktionsparameter. Und nein, das denke ich mir NICHT aus.

* Scripting mit "zu einfachem" C. Strings auf einen C-artigen Interpreter aufzusetzen ist eine gute Idee, dann aber fast alles andere wegzustreichen, was C kann (Funktionen als Funktionsparameter, beliebig dimensionierte Arrays, Funktionen mit einer variablen Anzahl Parameter, ...), ist extrem behindernd.

* Die Fehler dann mit Tonnen von halb fertig gedachten Runtime-Library-Funktionen ausbügeln zu wollen bringt's auch nicht.

* In einer Umgebung, in der fast alles als Objekt zu sehen ist, keinerlei OOP im Scripting vorzusehen, ist auch alles andere als genial.

* Im Datenbank-Umfeld keine assoziativen Arrays im Scripting zu haben macht auch keinen Spaß. Man schreibt alles in Arrays und rennt ständig mit for-Schleifen über die Arrays, um Werte nach Namen zu finden. Performance ist dann natürlich gruselig. Und um Hashes selbst zu programmieren, ist das C zu abgemagert.

Insgesamt erinnert die Laufzeitumgebung sehr an die wunderschöne Toolbox-Analogie aus PHP: a fractal of bad design:

Imagine you have a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

Ich vergaß zu erwähnen, dass $VORGÄNGER vorher für den Hersteller der Laufzeitumgebung arbeitete. Nicht unbedingt als Core-Programmierer, aber als "Verkäufer", der die Laufzeitungebung, eines der verschiedenen Grundsysteme und kundenspezifische Anpassungen verkaufte und letztere auch "programmierte".

Ich hab bei einer günstigen Gelegenheit einen kleinen Einblick in die interne Arbeitsweise beim Hersteller der Laufzeitumgebung bekommen. Man werkelt mit hunderten verschiedener ZIPs auf diversen Rechnern, CVS ist ein Write-Only-Memory, dass nur ein einziger im Haus benutzen darf, und auch nur schreibend, nicht lesend. Man schult neue Mitarbeiter und Kunden (für viel Geld) hauptsächlich darin, Workarounds für die Macken der Laufzeitumgebung zu kennen bzw. zu erfinden.

Alexander

[niklaskamenisch]

hi,

bisher hab ichs so zum glück nicht erleben müssen.
Hatte immer Glück der jenige zu sein, der V2.0 machen darf.
Also wirklich mal neu Anfangen kann.
Doch aus Erfahrung bin ich der Meinung: Die anderen sind nicht unbedingt eine NULL sondern machen es nur einfach anders. Ich kann mit dem Auto nach Rom, ich kann aber auch den Zug nehmen.

Oft kommt so "müll" auch davon, das das Ziel nicht gut genug beschrieben werden konnte. Da mag der Entwickler schuld sein, vllt. aber auch der Auftraggeber, der nach 20 mal nachfragen immer noch nicht richtig definieren konnte. Wenn die Aufgabe hieß, fahr nach Rom, dann reicht der Zug aus. Wenn mir dann aber einer sagt, nim noch 3 Leute mit, dann buch ich eben 3 Plätze dazu und gut ist. Muss ich aber noch meine Ausrüstung mit nehmen, dann brauch ich schon das ganz große Auto. Ich denk ihr versteht schon ;)

Das schöne an der Geschichte ist aber häufig. Dass auch eine Version 2 irgendwann den Platz von V1.0 bekommen wird und man lieber noch mal von vorne beginnt. Wenn ich überlege, wieviele CMS-Systeme ich gesehen habe und wieviele ich richtig gut kenne. Ich würde trotzdem sagen, das system das ich grade schreibe, sollte ich in einem Jahr noch mal von vorne beginnen. Dann hats noch weniger Ecken als das jetztige (auch wenn ich bisher nur wenige kleine kanten sehe). Große Software ist schwer zu überblicken.

Aber im Grund gib ich dir Recht, es ist schon ein nettes Gefühl, wenn man zu 100% sagen kann. "Das hab ich euch so vor 2 Jahren gesagt". Wenn Kollegen daneben hocken und dann sagen können "Ja das hat er". Dann ist das doch Gefühlt, wie 2 Beförderungen xD

Gruß Niklas

[Matthias Apsel]

Om nah hoo pez nyeetz, niklaskamenisch!

CMS-Systeme

LCD-Displays, ABS-Systeme, ESP-Programme scnr

Matthias

[niklaskamenisch]

hi,

asche auf mein Haupt ...

LCD-Displays, ABS-Systeme, ESP-Programme scnr

HIV-Virus, ABM-Maßnahme, PIN-Nummer, TAN-Nummer

und jetzt ganz fies: die deutsche DIN-Norm

nennt sich nach dem Wiki: „RAS-Syndrom“ (Redundantes-Akronym-Syndrom-Syndrom)

Gruß Niklas

[Der Martin]

Hallo,

HIV-Virus, ABM-Maßnahme, PIN-Nummer, TAN-Nummer

die hatte ich auch noch im Sinn (okay, die TAN hätte ich jetzt weggelassen).

und jetzt ganz fies: die deutsche DIN-Norm

Das ist doch gar nicht so fies. Schließlich steht DIN als Abkürzung für "Deutsches Institut für Normung". Eine DIN-Norm ist also eine vom DIN herausgegebene Norm. Klingt ein bissl holprig, ist aber sprachlich völlig in Ordnung.

nennt sich nach dem Wiki: „RAS-Syndrom“ (Redundantes-Akronym-Syndrom-Syndrom)

*Das* kannte ich jetzt auch noch nicht, danke!

Ciao,
 Martin

[niklaskamenisch]

hi,

Hallo,

HIV-Virus, ABM-Maßnahme, PIN-Nummer, TAN-Nummer

die hatte ich auch noch im Sinn (okay, die TAN hätte ich jetzt weggelassen).

Ob wohl zentraler CPU zählen würde?

und jetzt ganz fies: die deutsche DIN-Norm

Das ist doch gar nicht so fies. Schließlich steht DIN als Abkürzung für "Deutsches Institut für Normung". Eine DIN-Norm ist also eine vom DIN herausgegebene Norm. Klingt ein bissl holprig, ist aber sprachlich völlig in Ordnung.

selbst bei dir würde das dann "deutsche Deutsches Institu für Normungs Norm". Dachte eig das DIN für Deutsche Industrie Norm steht ... Zumindest in der Schule früher immer so gelernt.

nennt sich nach dem Wiki: „RAS-Syndrom“ (Redundantes-Akronym-Syndrom-Syndrom)

*Das* kannte ich jetzt auch noch nicht, danke!

Ciao,
Martin

Gruß Niklas

[Der Martin]

Hallo,

Schließlich steht DIN als Abkürzung für "Deutsches Institut für Normung".
[...] Dachte eig das DIN für Deutsche Industrie Norm steht ...

das ist ebenso ein Aberglaube wie die Volksmeinung, DIN bedeute einfach "Das Ist Norm".

Zumindest in der Schule früher immer so gelernt.

Ja, die Auffassung war früher weit verbreitet.

Ciao,
 Martin

[Christian Kruse]

Moin Martin,

Schließlich steht DIN als Abkürzung für "Deutsches Institut für Normung".
[...] Dachte eig das DIN für Deutsche Industrie Norm steht ...

das ist ebenso ein Aberglaube wie die Volksmeinung, DIN bedeute einfach "Das Ist Norm".

Naja, es ist überholt. Aber es stand mal dafür, genau wie auch „Deutsche Industrie-Norm“ mal richtig war. Siehe auch Wikipedia über DIN-Norm.

LG,
 CK

[suit]

Oft kommt so "müll" auch davon, das das Ziel nicht gut genug beschrieben werden konnte.

Meiner Erfahrung nach kommt Müll hauptsächlich durch zwei Dinge zu Stande:

1. der Entwickler hat keine Ahnung davon was er eigentlich tut

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

In beiden Fällen sieht man, ob der Entwickler wenigstens gute Ideen gehabt hat, die man weiterverfolgen kann.

Ob der Entwickler tatsächlich eine Null ist oder eben nur unvollständig gearbeitet hat erkennt man daran, dass die grundlegenden Teile sauber ausgearbeitet sind, der Rest aber dreckig drangebaut wurde.

Da mag der Entwickler schuld sein, vllt. aber auch der Auftraggeber, der nach 20 mal nachfragen immer noch nicht richtig definieren konnte.

Das ist auch ein großes Problem: es wird eine Anforderung definiert, daran wird dann 3 Monate programmiert und danach kommt der Auftraggeber drauf, dass er doch alles ganz anders braucht - das erschüttert die Struktur der Software in ihren Grundfesten und ohne alles neu zu schreiben kommt man einfach nicht drum rum, dass man "schnell schnell" in 2 Tagen die Arbeit von 2 Monaten erledigt.

Wenn die Aufgabe hieß, fahr nach Rom, dann reicht der Zug aus.

Und dann baut der Entwickler Schienen, zwei schöne Bahnhöfe und ein paar Tunnels.

Wenn mir dann aber einer sagt, nim noch 3 Leute mit, dann buch ich eben 3 Plätze dazu und gut ist. Muss ich aber noch meine Ausrüstung mit nehmen, dann brauch ich schon das ganz große Auto. Ich denk ihr versteht schon ;)

In diesen Fall baut man dann vielleicht noch einen Gepäckwagon hinzu - aber spätestens wenn der Auftraggeber dann auf einmal nach London will, wirds mit dem Zug schwierig - einfach mal schnell den Eurotunnel dazugebaut ist nicht - und wenn dann noch der Wunsch kommt, dass man jetzt auch noch nach New York will, braucht man ein Flugzeug - das baut der Entwickler dann, aber das hat dann Stromabnehmer und einen Gepäckwagon. Das sieht für einen Außenstehenden nach Mist aus, liegt aber daran, dass ein System auf etwas umgebaut wurde, was es eigentlich nicht können hätte sollen.

Das schöne an der Geschichte ist aber häufig. Dass auch eine Version 2 irgendwann den Platz von V1.0 bekommen wird und man lieber noch mal von vorne beginnt.

Große Software ist schwer zu überblicken.

Ja - und besonders schwierig ist es im Projektgeschäft, dann ein Feature auszubauen, welches er haben wollte und jetzt nicht mehr braucht, weil du einen drauf lassen kannst, dass er es drei Wochen später doch wieder braucht. Du stehst also vor einem Dilemma: bereinigst du den Code, wird er das Feature wieder haben wollen und darfst es wieder dazubauen - belässt du es im Code, wird er es nie wieder haben wollen und dein Nachfolger wird sich über den "Trottel der den Code nicht aufräumt" wundern :)

Aber im Grund gib ich dir Recht, es ist schon ein nettes Gefühl, wenn man zu 100% sagen kann. "Das hab ich euch so vor 2 Jahren gesagt". Wenn Kollegen daneben hocken und dann sagen können "Ja das hat er". Dann ist das doch Gefühlt, wie 2 Beförderungen xD

So ist es - nur leider kommt das selten vor.

[niklaskamenisch]

hi,

phu, am anfang dachte ich, gleich wird alles wiederlegt ...
aber ich sehe ... leidensgenossen finden sich hier xD

Gruß Niklas

[Sven Rautenberg]

Moin!

Meiner Erfahrung nach kommt Müll hauptsächlich durch zwei Dinge zu Stande:

1. der Entwickler hat keine Ahnung davon was er eigentlich tut

Das geht ja auch auf mehreren Ebenen: Entweder die Anforderungen sind unklar, oder der Entwickler ist der Aufgabe nicht gewachsen, weil ihm Erfahrung, Wissen und/oder Können fehlen.

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Insbesondere muss er NEIN sagen, NEIN meinen, und dann diese Aussage auch durchhalten. Wenn er NEIN sagt, es dann aber dennoch versucht, und dann scheitert, ist er der Doofe. Wenn er NEIN sagt, trotz hohem Drucks, und sein Chef glaubt ihm nicht, dann ist der Chef der Doofe, weil er trotz gegenteiliger Aussage nach außen kommuniziert hat, es ginge doch.

Und der Chef hat in diesem Fall auch die Chance verspielt, die wahren Interessen hinter dem Termindruck zu ermitteln und zu erforschen, was zu dem Termin tatsächlich geliefert werden soll - und warum.

In beiden Fällen sieht man, ob der Entwickler wenigstens gute Ideen gehabt hat, die man weiterverfolgen kann.

Wenn ein Entwickler unter Zeitdruck, weil er nicht NEIN sagen konnte, irgendwas zusammengecodet hat, dürfte die beste initiale Struktur durch diese Aktion recht untrennbar zu einem unansehnlichen Codemüll zusammengebacken worden sein. Das wieder sauber aufzutrennen ist eine sehr schwierige und aufwendige Aufgabe.

Ob der Entwickler tatsächlich eine Null ist oder eben nur unvollständig gearbeitet hat erkennt man daran, dass die grundlegenden Teile sauber ausgearbeitet sind, der Rest aber dreckig drangebaut wurde.

Da mag der Entwickler schuld sein, vllt. aber auch der Auftraggeber, der nach 20 mal nachfragen immer noch nicht richtig definieren konnte.

Das ist auch ein großes Problem: es wird eine Anforderung definiert, daran wird dann 3 Monate programmiert und danach kommt der Auftraggeber drauf, dass er doch alles ganz anders braucht - das erschüttert die Struktur der Software in ihren Grundfesten und ohne alles neu zu schreiben kommt man einfach nicht drum rum, dass man "schnell schnell" in 2 Tagen die Arbeit von 2 Monaten erledigt.

Wenn es die Struktur der Software in ihren Grundfesten erschüttern kann, weil ein Feature nicht so wie anfänglich geplant umgesetzt werden soll, war vermutlich mit der Struktur was falsch.

Und wenn die neue Anforderung nicht problemlos in den Code hineingetan werden kann, war vielleicht auch mit der Software-Entwicklungs-Methodik was falsch.

Ja - und besonders schwierig ist es im Projektgeschäft, dann ein Feature auszubauen, welches er haben wollte und jetzt nicht mehr braucht, weil du einen drauf lassen kannst, dass er es drei Wochen später doch wieder braucht. Du stehst also vor einem Dilemma: bereinigst du den Code, wird er das Feature wieder haben wollen und darfst es wieder dazubauen - belässt du es im Code, wird er es nie wieder haben wollen und dein Nachfolger wird sich über den "Trottel der den Code nicht aufräumt" wundern :)

Und wenn ein nicht mehr benötigtes Feature nicht ohne Angst, dass man zuviel entfernt und deshalb Dinge kaputt macht, wieder herausgenommen werden kann, dann hat man vielleicht keine funktionierenden Tests.

Aber im Grund gib ich dir Recht, es ist schon ein nettes Gefühl, wenn man zu 100% sagen kann. "Das hab ich euch so vor 2 Jahren gesagt". Wenn Kollegen daneben hocken und dann sagen können "Ja das hat er". Dann ist das doch Gefühlt, wie 2 Beförderungen xD

So ist es - nur leider kommt das selten vor.

Und was bringt das dann genau? Ok, kommt natürlich auf die Situation an, aber in der Regel ist es doch so:

Entwickler hat eine gut begründete Position, wie eine Anforderung in Software umzusetzen ist.

Chef hat die Argumente gehört und sich anders entschieden.

Und der Lauf der Dinge hat bewiesen, dass der Entwickler richtig lag und der Chef falsch.

Und jetzt kommentiert der Entwickler die damalige Chef-Entscheidung mit "Hab ich gleich gesagt, dass das ein Fehler war.", und alle Fachkollegen stimmen ihm zu.

In welcher Situation ist jetzt der Chef? Und inwiefern hilft das dem Team bei der nächsten Entscheidung dieser Art? Warum wird vom Entwickler mit dem Finger auf den Chef gezeigt und gemeint: "Du da hast den Fehler gemacht. Du bist Schuld!"

Wenn solch ein Verhalten zur Unternehmenskultur gehört, dann bedeutet das umgekehrt auch, dass der Chef bei der nächsten Situation, bei der es genau umgekehrt läuft, dann mit dem Finger auf den Entwickler zeigt und sagt: "Du hast die Software scheiße programmiert. Du bist Schuld!"

Und weil er Chef ist und vermutlich die Macht dazu hat, kann er den Entwickler bei ausreichender Anzahl solcher Vorfälle dann auch mal rauswerfen. Oder zumindest sanktionieren.

Ich möchte nicht in einem Umfeld als Entwickler arbeiten, in dem Fingerpointing und Schuldzuweisungen an der Tagesordnung sind und man am besten lebt, wenn man keine Fehlentscheidungen trifft, weil man am besten gar keine Entscheidungen trifft.

Software zu entwickeln ist Teamwork. Das bedeutet: Das Team als Gesamtheit ist verantwortlich für die geleistete Arbeit und die abgelieferte Qualität. Niemand kann alleine Schuld sein, denn wenn das Team in Ordnung findet, dass Mitarbeiter A die Aufgabe B erledigt, und niemand hinterher kontrolliert, ob das nach dem gemeinsamen Qualitätsempfinden vernünftig gebaut wurde, muss das Team damit leben, wenn sich hinterher rausstellt, dass das eben doch nicht so war. Das fortwährende Versagen des Teams bei der Definition und Kontrolle eigener Qualitätsstandards führt dazu, dass jeder nur so für sich codet, irgendeine beliebige Qualität abliefert, und damit möglicherweise zu genau diesem Exemplar von $VORGAENGER wird, dessen Code niemand mehr anfassen will.

Vermutlich sind in solchem Umfeld die Entwickler auch lieber Einzelkämpfer und Herrscher über "ihren" Code, den niemand anderes anfassen darf - was auch kein Teamwork ist, sondern Wissensmachtkampf, entweder motiviert durch die Gewissheit, "die können micht nicht rauswerfen, ohne selbst unterzugehen", oder aus Angst, dass die eigenen Unzulänglichkeiten ruchbar werden. Den Schaden hat in allen Fällen das Team insgesamt und der Auftraggeber, denn im ersten Fall wird die Chance verpasst, Spezialwissen breiter zu streuen, um in die Lage zu kommen, eben genau nicht von einer einzelnen Person abhängig zu sein (selbst wenn man denjenigen nie rauswerfen wollte, gibts immer unbeeinflussbare Faktoren wie Unfälle, Krankheiten oder Urlaub, oder unerwarteten erhöhten Arbeitsanfall). Im zweiten Fall wird die Chance verpasst, sich selbst durch Feedback der Kollegen weiterzuentwickeln.

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

- Sven Rautenberg

[Alexander (HH)]

Moin Moin!

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Insbesondere muss er NEIN sagen, NEIN meinen, und dann diese Aussage auch durchhalten. Wenn er NEIN sagt, es dann aber dennoch versucht, und dann scheitert, ist er der Doofe. Wenn er NEIN sagt, trotz hohem Drucks, und sein Chef glaubt ihm nicht, dann ist der Chef der Doofe, weil er trotz gegenteiliger Aussage nach außen kommuniziert hat, es ginge doch.

Und der Chef hat in diesem Fall auch die Chance verspielt, die wahren Interessen hinter dem Termindruck zu ermitteln und zu erforschen, was zu dem Termin tatsächlich geliefert werden soll - und warum.

Aktuelle Situation bei meinem aktuellen Projekt. Chef hat überhaupt nicht verstanden, wie umfangreich das Projekt werden muß. Also sagte er mit hemmungslosem Optimismus und ohne Rückfragen einen völlig unrealistischen Termin zu, und muß das jetzt ausbaden.

Ob der Entwickler tatsächlich eine Null ist oder eben nur unvollständig gearbeitet hat erkennt man daran, dass die grundlegenden Teile sauber ausgearbeitet sind, der Rest aber dreckig drangebaut wurde.

Nach dem Kriterium war $VORGÄNGER eine Null.

[...]

Und was bringt das dann genau? Ok, kommt natürlich auf die Situation an, aber in der Regel ist es doch so:

Entwickler hat eine gut begründete Position, wie eine Anforderung in Software umzusetzen ist.

Chef hat die Argumente gehört und sich anders entschieden.

Und der Lauf der Dinge hat bewiesen, dass der Entwickler richtig lag und der Chef falsch.

Und jetzt kommentiert der Entwickler die damalige Chef-Entscheidung mit "Hab ich gleich gesagt, dass das ein Fehler war.", und alle Fachkollegen stimmen ihm zu.

In welcher Situation ist jetzt der Chef? Und inwiefern hilft das dem Team bei der nächsten Entscheidung dieser Art? Warum wird vom Entwickler mit dem Finger auf den Chef gezeigt und gemeint: "Du da hast den Fehler gemacht. Du bist Schuld!"

Wenn solch ein Verhalten zur Unternehmenskultur gehört, dann bedeutet das umgekehrt auch, dass der Chef bei der nächsten Situation, bei der es genau umgekehrt läuft, dann mit dem Finger auf den Entwickler zeigt und sagt: "Du hast die Software scheiße programmiert. Du bist Schuld!"

Und weil er Chef ist und vermutlich die Macht dazu hat, kann er den Entwickler bei ausreichender Anzahl solcher Vorfälle dann auch mal rauswerfen. Oder zumindest sanktionieren.

Ich möchte nicht in einem Umfeld als Entwickler arbeiten, in dem Fingerpointing und Schuldzuweisungen an der Tagesordnung sind und man am besten lebt, wenn man keine Fehlentscheidungen trifft, weil man am besten gar keine Entscheidungen trifft.

So ist die Situation bei uns zum Glück nicht.

Software zu entwickeln ist Teamwork. Das bedeutet: Das Team als Gesamtheit ist verantwortlich für die geleistete Arbeit und die abgelieferte Qualität. Niemand kann alleine Schuld sein, denn wenn das Team in Ordnung findet, dass Mitarbeiter A die Aufgabe B erledigt, und niemand hinterher kontrolliert, ob das nach dem gemeinsamen Qualitätsempfinden vernünftig gebaut wurde, muss das Team damit leben, wenn sich hinterher rausstellt, dass das eben doch nicht so war. Das fortwährende Versagen des Teams bei der Definition und Kontrolle eigener Qualitätsstandards führt dazu, dass jeder nur so für sich codet, irgendeine beliebige Qualität abliefert, und damit möglicherweise zu genau diesem Exemplar von $VORGAENGER wird, dessen Code niemand mehr anfassen will.

Bei $VORGÄNGER war die Situation so, dass der Chef von der Geschäftsführung an seiner Arbeit gehindert wurde, $VORGÄNGER hatte dank eines Geschäftsführers nahezu Narrenfreiheit. Damit waren auch alle Ansätze des Qualitätsmanagements ausgehebelt.

Was Teamwork und Team-Management angeht: Das würde einen Chef voraussetzen, der etwas von Team-Management und Projektmanagement versteht, der seine Leute entsprechend ihren Fähigkeiten einsetzt und der gegenüber der Geschäftsführung auch mal deutlich sagt, das 150% Dauerlast nicht gut sind und das Leute fehlen, statt immer nur "alles gut, alles schön" zu verbreiten.

Es ist etwas böse, aber die EDV funktioniert am Besten, wenn der Chef krank oder im Urlaub oder bei irgendeinem Meeting ist. Es ist bezeichnend, dass kritische Meetings gerade von der Geschäftsführung und anderen Abteilungsleitern gerne so gelegt werden, dass der Chef "zufällig" gerade nicht dabei sein kann. Rückblickend das Sahnehäubchen: Der Chef war der letzte, der erfuhr, dass die Geschäftsleitung mich eingestellt hat.

Alexander

[suit]

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Du kannst nein sagen so oft du willst - da kommen dann von den vorgesetzten Meldungen wie "du siehst immer nur Probleme, ich will Lösungen" - wenn du dann die Lösung "wir brauchen mehr Zeit und müssen mehr Geld dafür verlangen oder wir müssen die Features reduzieren" kommt, hast du eine Endlosschleife (oft genug erlebt).

Insbesondere muss er NEIN sagen, NEIN meinen, und dann diese Aussage auch durchhalten. Wenn er NEIN sagt, es dann aber dennoch versucht, und dann scheitert, ist er der Doofe.

Das funktioniert in der Praxis nicht - du kannst nicht "NEIN" sagen und dich zurücklehnen und nichts mehr tun, weil du ja nein gesagt hast - da brauchst du schon einen sehr gutmütigen Chef der das Mitmacht.

Wenn er NEIN sagt, trotz hohem Drucks, und sein Chef glaubt ihm nicht, dann ist der Chef der Doofe, weil er trotz gegenteiliger Aussage nach außen kommuniziert hat, es ginge doch.

Auch wenn sich der Chef die Schläge beim Kunden abholt, das wird immer nach unten durchgereicht.

Und der Chef hat in diesem Fall auch die Chance verspielt, die wahren Interessen hinter dem Termindruck zu ermitteln und zu erforschen, was zu dem Termin tatsächlich geliefert werden soll - und warum.

Ich stimme dir voll und ganz zu - aber du bist hier einfach realitätsfremd.

Wenn ein Entwickler unter Zeitdruck, weil er nicht NEIN sagen konnte, irgendwas zusammengecodet hat, dürfte die beste initiale Struktur durch diese Aktion recht untrennbar zu einem unansehnlichen Codemüll zusammengebacken worden sein. Das wieder sauber aufzutrennen ist eine sehr schwierige und aufwendige Aufgabe.

Ja - darum ist in vielen Fällen ja nicht der $Vorgänger ein Trottel der nicht programmieren kann, sondern der unter Zeitdruck Mist gebaut hat und dann gagangen wurde, weil er zu oft NEIN gesagt hat - auch schon oft genug erlebt.

Wenn es die Struktur der Software in ihren Grundfesten erschüttern kann, weil ein Feature nicht so wie anfänglich geplant umgesetzt werden soll, war vermutlich mit der Struktur was falsch.

Nein - du lebst in einer idealen Welt in der es genug Zeit und Geld gibt immer alle möglichen Erweiterungen vorzusehen und entsprechende Erweiterungsmöglichkeiten zu schaffen. In der Geiz-ist-Geil-Welt sieht das aber leider anders aus - und es kommt nicht selten vor.

Ein einfaches Beispiel: Kunde will eine Youtube-API-Anbindung - programmierst du da jetzt gleich einen Abstraktionsschicht um später mal andere Video-Dienstleister-APIs verwenden zu können oder eben doch direkt?

Finanziell wird sich die "wir sehen mal in die Zukunft vor" idR. nicht spielen.

Und wenn die neue Anforderung nicht problemlos in den Code hineingetan werden kann, war vielleicht auch mit der Software-Entwicklungs-Methodik was falsch.

Die Methodik leidet fast immer unter Zeitdruck - meistens gibts nichtmal Zeit eine Software ordentlich zu dokumentieren Geschweige denn zu testen. Ich hab' auch schon erlebt, dass ein komplexe Software ohne Pflichtenheft zu einem völlig irren, auch nach Daumen-Mal-Pi-Schätzung, Preis verkauft wurde. Bauchgefühlschätzung war "irgendwo 2 Monate" und verkauft wurde es um gute 2 Wochen - das hat dann zu unbezahlen Extraschichten über Weihnachten und Neujahr geführt - weil der Online-Termin auf kurz vor Weihnachten zugesagt wurde.

Und wenn ein nicht mehr benötigtes Feature nicht ohne Angst, dass man zuviel entfernt und deshalb Dinge kaputt macht, wieder herausgenommen werden kann, dann hat man vielleicht keine funktionierenden Tests.

Nein, nicht "kaputt machen" sondern ein Feature risikofrei für den Rest entfernen, aber mit dem Risiko, dass der Kunde genau dieses Feature gleich mal wieder zurückhaben möchte.

Ja, sowas lässt sich mit einem Repository gut Regeln - aber es ist trotzdem keine Geschichte die man dann "mal schnell eben" zurückbaut.

[...] aber in der Regel ist es doch so:

Entwickler hat eine gut begründete Position, wie eine Anforderung in Software umzusetzen ist.

Chef hat die Argumente gehört und sich anders entschieden.

Und der Lauf der Dinge hat bewiesen, dass der Entwickler richtig lag und der Chef falsch.

Ja, das ist die Regel - trotzdem wird dem Entwickler dann ständig vorgehalten, dass er ja prinzipiell "immer dagegen" ist. Dass später mal eingestanden wird, dass es tatsächlich war, kommt selten vor - und wenn doch, sind es nur Worthülsen, die 3 Tage später wieder vergessen sind.

Und weil er Chef ist und vermutlich die Macht dazu hat, kann er den Entwickler bei ausreichender Anzahl solcher Vorfälle dann auch mal rauswerfen. Oder zumindest sanktionieren.

Und genau aus dem Grund wird idR. gekuscht und einfach mal an unhaltbaren Terminen gearbeitet - das ist leider üblich.

Software zu entwickeln ist Teamwork.

Die Kluft besteht idR. auch eher zwischen "Management" und "Technik" oder "Design" und "Technik" - wenn die Techniker untereinander schon nicht richtig zusammenarbeiten ist sowieso Hopfen und Malz verloren

Vermutlich sind in solchem Umfeld die Entwickler auch lieber Einzelkämpfer und Herrscher über "ihren" Code, den niemand anderes anfassen darf

Sowas ist ganz besonders Traurig - aber das kommt denke ich im Projektgeschäft weniger vor.

"die können micht nicht rauswerfen, ohne selbst unterzugehen",

Was aber letzlich dazu führt, dass derjenige so schnell wie möglich bei bester Gelegenheit abgesägt wird

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

Du hast ja keine Ahnung wie weit man das noch unterbieten kann - ich hab noch viel schlimmeres gesehen.

[Christian Kruse]

Moin suit, moin Sven,

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Du kannst nein sagen so oft du willst […]

Halte ich auch für extremst unrealistisch, ja. Hat bei mir auch noch nie wirklich geklappt. Zumal der Chef dir gegenüber ja weisungsbefugt ist, wenn du also „NEIN sagst und dann dabei bleibst,“ dann ist das ein Grund für eine Kündigung – und das auch mit Recht. Dem Chef deutlich zu verstehen zu geben, dass die Vorstellung unrealistisch ist und der Termin nicht haltbar ist, es aber dennoch zu versuchen ist der Weg, den man einschlagen muss.

Ein einfaches Beispiel: Kunde will eine Youtube-API-Anbindung - programmierst du da jetzt gleich einen Abstraktionsschicht um später mal andere Video-Dienstleister-APIs verwenden zu können oder eben doch direkt?

Finanziell wird sich die "wir sehen mal in die Zukunft vor" idR. nicht spielen.

Das sehe ich anders. Es  lohnt sich fast immer, die Abstraktionsschicht einzubauen, zumal sie oft nichtmal wirklich mehr Arbeit kostet. Dazu kommt, dass das einfache auch eine Frage der Software-Qualität ist.

das hat dann zu unbezahlen Extraschichten über Weihnachten und Neujahr geführt

Naja, wenn du das mit dir machen lässt, bist du selber schuld. Weiss ja nicht, wieviel Berufserfahrung du hast, aber sowas würde ich nicht mehr mitmachen. Wenn ich Überstunden mache, werden die vergütet. Zumal sich Software-Entwickler nun wirklich nicht in einer Marktposition befinden, in der sie sich zu etwas zwingen lassen müssen.

[...] aber in der Regel ist es doch so:

Entwickler hat eine gut begründete Position, wie eine Anforderung in Software umzusetzen ist.

Chef hat die Argumente gehört und sich anders entschieden.

Und der Lauf der Dinge hat bewiesen, dass der Entwickler richtig lag und der Chef falsch.

Ja, das ist die Regel - trotzdem wird dem Entwickler dann ständig vorgehalten, dass er ja prinzipiell "immer dagegen" ist.

Naja, dann solltest du vielleicht nicht immer dagegen sein. Deine Rolle als Entwickler ist nicht, deinen Chef zu überzeugen, sondern in einem sachlichen Gespräch deine Argumente darzulegen, warum du das nicht für sinnvoll erachtest, aber auch nicht chronisch bei jeder Gelegenheit deinem Chef vorzuhalten, dass das Unsinn ist. Einmal reicht, danach wird jeder durchschnittliche Mensch verstanden haben, dass du das anders siehst.

In dieser Hinsicht stimme ich Sven voll und ganz zu. Mit dem Finger auf andere zu zeigen zeugt nicht nur von schlechter Erziehung, sondern ist auch kontraproduktiv und erzeugt eine Arbeitsathmosphäre basierend auf Angst, die man nicht haben möchte.

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

Du hast ja keine Ahnung wie weit man das noch unterbieten kann - ich hab noch viel schlimmeres gesehen.

Ich auch. Das heisst aber nicht, dass die oben beschriebenen Verhaltensweisen professionell sind :-)

LG,
 CK

[suit]

Das sehe ich anders. Es  lohnt sich fast immer, die Abstraktionsschicht einzubauen, zumal sie oft nichtmal wirklich mehr Arbeit kostet. Dazu kommt, dass das einfache auch eine Frage der Software-Qualität ist.

Wenn es möglich ist, sehe ich künftige Erweiterungen und ähnlich vor ja - aber es gibt einfach Fälle wo die API so mächtig ist, dass man nicht jedes Stückerl davon gleich mal implementieren kann. Ein gutes Beispiel ist Verwaltungssoftware für Tourismusgebiete - da gibts Unterkünfte, Events, News, POIs usw. Wenn da die Aufgabe ist, Unterkünfte anzuzeigen, kannst du nicht anfagen dass du beim modellieren der Datenbank gleich mal die 60 Tabellen für Events und POIs auch anlegst, weil der Kunde die ja später mal brauchen könnte.

das hat dann zu unbezahlen Extraschichten über Weihnachten und Neujahr geführt

Naja, wenn du das mit dir machen lässt, bist du selber schuld.

Hab' ich auch nicht - ich arbeite nicht unbezahlt. Und wenn dann nur für Freunde in äußerst begrenztem Ausmaß (sprich, selbst einfache Dinge wie "Setz du mit meinen Rechner neu auf" ist etwas das ich nicht kostenlos machen würde")

Weiss ja nicht, wieviel Berufserfahrung du hast, aber sowas würde ich nicht mehr mitmachen.

Tu ich auch nicht - aber im genannten Fall haben das ein paar "junge Hupfer" micht sich machen lassen die teilweise 40 Stunden kostenlos gearbeitet haben.

Wenn ich Überstunden mache, werden die vergütet.

Selbstverständlich - ich hab' auch kein Problem damit über Weihnachten oder an Feiertagen zu arbeiten, meinetwegen auch mitten in der Nacht - nur bezahlt muss es werden.

Zumal sich Software-Entwickler nun wirklich nicht in einer Marktposition befinden, in der sie sich zu etwas zwingen lassen müssen.

Kommt auf die Größe des Unternehmens an.

Naja, dann solltest du vielleicht nicht immer dagegen sein.

Das hat was mit selektiver Wahrnehmung zu tun - wenn du 1 x in 20 Fälle dagegen bist, dann bist du "immer" dagegen.

Du hast ja keine Ahnung wie weit man das noch unterbieten kann - ich hab noch viel schlimmeres gesehen.

Ich auch. Das heisst aber nicht, dass die oben beschriebenen Verhaltensweisen professionell sind :-)

Das kommt darauf an was man als "professionell" ansieht: im Sinn von "Gewerblich damit hantieren" ist leider viel Schrott professionell ;)

[Sven Rautenberg]

Moin!

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Du kannst nein sagen so oft du willst […]

Halte ich auch für extremst unrealistisch, ja. Hat bei mir auch noch nie wirklich geklappt. Zumal der Chef dir gegenüber ja weisungsbefugt ist, wenn du also „NEIN sagst und dann dabei bleibst,“ dann ist das ein Grund für eine Kündigung – und das auch mit Recht. Dem Chef deutlich zu verstehen zu geben, dass die Vorstellung unrealistisch ist und der Termin nicht haltbar ist, es aber dennoch zu versuchen ist der Weg, den man einschlagen muss.

"Do, or do not. There is no try." (Yoda)

Dem Chef rückzumelden, dass der notwendige Arbeitsaufwand für die Features in der vorgesehenen Zeit nicht realisiert werden können, ist das "NEIN".

Das bedeutet ja nicht, dass man nicht verhandlungsbereit ist. Weniger Features würden in der vorgesehenen Zeit funktionieren, oder alle Features in mehr Zeit.

Aber nach dem "NEIN" ein "Aber ich versuchs." hinterherzuschieben bedeutet "JA". Und zwar ein "JA, ich liefere zum vorgesehenen Termin alle Features, Chef." Und man weiß, dass das vermutlich nicht klappen wird.

Kein Chef kann einen anweisen, Features in der vorgesehenen Zeit fertigzustellen. Er hat lediglich die Macht, die Features zu bestimmen. Und er kann nach Ablauf der vorgesehenen Zeit das bis dahin erzielte Resultat kriegen. Das wird dann vermutlich unvollständig sein.

Zwei Möglichkeiten:
Entweder hat der Entwickler gesagt, dass es nicht funktionieren wird. Und hat angefangen, ist aber wie kommuniziert nicht fertig. Chef: "Warum ist das noch nicht fertig?" Prog: "Weil ich gesagt habe, dass es zwei Wochen länger dauert, und ich jetzt wie zu erwarten war erst halb fertig bin." Chef: "..." (weiß, dass er das Problem ignoriert hat)

Oder der Entwickler hat gesagt, es würde nicht funktionieren, er würde es aber versuchen. Chef: "Warum ist das noch nicht fertig?" Prog: "Ich habs versucht, aber es dauert halt länger. Hatte ich ja gesagt." Chef: "Dann arbeite mehr dran, dann klappt's auch."

Ein einfaches Beispiel: Kunde will eine Youtube-API-Anbindung - programmierst du da jetzt gleich einen Abstraktionsschicht um später mal andere Video-Dienstleister-APIs verwenden zu können oder eben doch direkt?

Finanziell wird sich die "wir sehen mal in die Zukunft vor" idR. nicht spielen.

Das sehe ich anders. Es  lohnt sich fast immer, die Abstraktionsschicht einzubauen, zumal sie oft nichtmal wirklich mehr Arbeit kostet. Dazu kommt, dass das einfache auch eine Frage der Software-Qualität ist.

YAGNI! :)

Das gilt in der Tat aber nur für Features. Abstraktion ist eine Frage der Architektur.

Ja, das ist die Regel - trotzdem wird dem Entwickler dann ständig vorgehalten, dass er ja prinzipiell "immer dagegen" ist.

Naja, dann solltest du vielleicht nicht immer dagegen sein. Deine Rolle als Entwickler ist nicht, deinen Chef zu überzeugen, sondern in einem sachlichen Gespräch deine Argumente darzulegen, warum du das nicht für sinnvoll erachtest, aber auch nicht chronisch bei jeder Gelegenheit deinem Chef vorzuhalten, dass das Unsinn ist. Einmal reicht, danach wird jeder durchschnittliche Mensch verstanden haben, dass du das anders siehst.

Es kommt halt auch darauf an, wie man sein NEIN verpackt. Und das NEIN richtet sich ja nicht gegen die Aufgabe, sondern gegen den Zeitplan.

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

Du hast ja keine Ahnung wie weit man das noch unterbieten kann - ich hab noch viel schlimmeres gesehen.

Ich auch. Das heisst aber nicht, dass die oben beschriebenen Verhaltensweisen professionell sind :-)

Klar, schlimmer geht immer. Profis sind - auch beim Führungspersonal - nicht so häufig, und es ist eine Kunst, ein gutes Team zusammen zu führen und dann gut zu führen.

- Sven Rautenberg

[Der Martin]

Hallo,

Dem Chef deutlich zu verstehen zu geben, dass die Vorstellung unrealistisch ist und der Termin nicht haltbar ist, es aber dennoch zu versuchen ist der Weg, den man einschlagen muss.
"Do, or do not. There is no try." (Yoda)

;-)

Dem Chef rückzumelden, dass der notwendige Arbeitsaufwand für die Features in der vorgesehenen Zeit nicht realisiert werden können, ist das "NEIN".

Das bedeutet ja nicht, dass man nicht verhandlungsbereit ist. Weniger Features würden in der vorgesehenen Zeit funktionieren, oder alle Features in mehr Zeit.

Ja, und genau diese qualifizierte Aussage bekommt er schriftlich (per e-Mail oder Aktennotiz), damit der AN später nicht der Dumme ist. Das hat nichts mit Schuldzuweisung oder in-die-Pfanne-Hauen zu tun, es ist eine reine Schutzmaßnahme.
Denn ich habe auch schon Chefs erlebt, die sich die Einwände und Argumente anhören, verständnisvoll nicken, und die Unterhaltung dann sinngemäß mit "Na gut, aber geben Sie sich Mühe" beenden. Und wenn dann der Stichtag näher rückt, gibt's großes Geschrei: "Wieso ist das noch nicht fertig?!" Genau dann *muss* ich die Mitteilung von "damals" rausholen können und den Chef damit erinnern: "Ich hatte Sie darauf hingewiesen."

Aber nach dem "NEIN" ein "Aber ich versuchs." hinterherzuschieben bedeutet "JA". Und zwar ein "JA, ich liefere zum vorgesehenen Termin alle Features, Chef." Und man weiß, dass das vermutlich nicht klappen wird.

Ganz genau.

Kein Chef kann einen anweisen, Features in der vorgesehenen Zeit fertigzustellen. Er hat lediglich die Macht, die Features zu bestimmen. Und er kann nach Ablauf der vorgesehenen Zeit das bis dahin erzielte Resultat kriegen. Das wird dann vermutlich unvollständig sein.

Richtig.

Zwei Möglichkeiten:
Entweder hat der Entwickler gesagt, dass es nicht funktionieren wird. Und hat angefangen, ist aber wie kommuniziert nicht fertig. Chef: "Warum ist das noch nicht fertig?" Prog: "Weil ich gesagt habe, dass es zwei Wochen länger dauert, und ich jetzt wie zu erwarten war erst halb fertig bin." Chef: "..." (weiß, dass er das Problem ignoriert hat)

Das wäre der Fall, den ich auch gerade skizziert habe. Nur möchte ich nicht das Opfer einer plötzlichen Gedächtnisschwäche meines Chefs sein.

Oder der Entwickler hat gesagt, es würde nicht funktionieren, er würde es aber versuchen. Chef: "Warum ist das noch nicht fertig?" Prog: "Ich habs versucht, aber es dauert halt länger. Hatte ich ja gesagt." Chef: "Dann arbeite mehr dran, dann klappt's auch."

Dritte Möglichkeit: Wenn der Chef sich wirklich für seine Leute und deren Aufgabe (also letztlich auch *seine* Aufgabe) interessiert, lässt er sich auch während der geplanten Projektlaufzeit immer mal wieder über den aktuellen Stand informieren, und gleicht den Istwert mit der Planung ab. Dabei kann man schon Trends ablesen - zum Beispiel, dass der Programmierer mit seiner Prognose richtig lag und die Zeit wirklich nicht reichen wird (wir wollen ihm mal nicht unterstellen, dass er mit Absicht trödelt). Dann kann man auf halber Strecke immer noch korrigierend eingreifen, z.B. den Programmierer von sonstigen Aufgaben abziehen, oder die Prioritäten der Einzelschritte ändern und weniger Wichtiges aufschieben, oder dem Kunden kommunizieren, dass unerwartete Schwierigkeiten aufgetreten seien und er zum vereinbarten Termin nur eine Rohfassung bekommen kann, die noch nicht alle Features enthält. Üblicherweise ist sowas noch verhandelbar.

Es kommt halt auch darauf an, wie man sein NEIN verpackt. Und das NEIN richtet sich ja nicht gegen die Aufgabe, sondern gegen den Zeitplan.

Eben. Sonst könnte es ein Eigentor werden.

Klar, schlimmer geht immer. Profis sind - auch beim Führungspersonal - nicht so häufig, und es ist eine Kunst, ein gutes Team zusammen zu führen und dann gut zu führen.

Ich kriege immer plötzlich Zahnschmerzen, wenn die Begriffe "Team" und "führen" in einem Atemzug genannt werden. Denn IMHO ist ein wesentliches Merkmal eines Teams das Fehlen von Hierarchie und der damit verbundenen Weisungsbefugnis. Kennzeichnend für ein Team ist, dass alle Mitglieder die gleichen Rechte und Befugnisse haben. Es mag eine Art Führung im Hintergrund geben, aber dann ist dieser Anführer nach meinem Verständnis ausdrücklich *nicht* Mitglied des Teams, sondern dem Team übergeordnet.

So long,
 Martin

[Christian Kruse]

Moin Sven,

Halte ich auch für extremst unrealistisch, ja. Hat bei mir auch noch nie wirklich geklappt. Zumal der Chef dir gegenüber ja weisungsbefugt ist, wenn du also „NEIN sagst und dann dabei bleibst,“ dann ist das ein Grund für eine Kündigung – und das auch mit Recht. Dem Chef deutlich zu verstehen zu geben, dass die Vorstellung unrealistisch ist und der Termin nicht haltbar ist, es aber dennoch zu versuchen ist der Weg, den man einschlagen muss.

"Do, or do not. There is no try." (Yoda)

Naja, die Binsenweisheiten vom guten alten Yoda sind halt auch nur bedingt sinnvoll.

Dem Chef rückzumelden, dass der notwendige Arbeitsaufwand für die Features in der vorgesehenen Zeit nicht realisiert werden können, ist das "NEIN".

Dann hast du dich unklar ausgedrückt: NEIN zu sagen bedeutet in meinem Verständnis, dass man sich mit verschränkten Armen hinstellt und „Nein, mach ich nicht, klappt doch eh nicht“ sagt. So ein Verhalten ist halt nicht hinnehmbar für den Chef.

So wie du es definiert hast, stimme ich dir zu.

Das sehe ich anders. Es  lohnt sich fast immer, die Abstraktionsschicht einzubauen, zumal sie oft nichtmal wirklich mehr Arbeit kostet. Dazu kommt, dass das einfache auch eine Frage der Software-Qualität ist.

YAGNI! :)

Und dann braucht mans EINMAL doch und dann fängt das Refactoring an :-)

Es kommt halt auch darauf an, wie man sein NEIN verpackt.

Genau.

LG,
 CK

[suit]

Dann hast du dich unklar ausgedrückt: NEIN zu sagen bedeutet in meinem Verständnis, dass man sich mit verschränkten Armen hinstellt und „Nein, mach ich nicht, klappt doch eh nicht“ sagt. So ein Verhalten ist halt nicht hinnehmbar für den Chef.

So wie du es definiert hast, stimme ich dir zu.

Ja, da bin ich auch dabei :)

YAGNI! :)

Und dann braucht mans EINMAL doch und dann fängt das Refactoring an :-)

Geht auch nicht anders - man kann nicht alles vorsehen was der Kunde vielleicht mal gerne hätte aber grade nicht bezahlt.

Man kann natürlicht vor Beginn der Arbeiten darauf hinweisen und sagen "wenn ihr jetzt X mehr investiert, sind spätere Erweiterungen einfacher einzubauen" - aber einfach mal so gratis arbeiten ist unwirtschaftlich.

[Christian Kruse]

Moin suit,

YAGNI! :)

Und dann braucht mans EINMAL doch und dann fängt das Refactoring an :-)

Geht auch nicht anders - man kann nicht alles vorsehen was der Kunde vielleicht mal gerne hätte aber grade nicht bezahlt.

Naja, bei einer entsprechend offenen Software-Struktur hält sich das Refactoring stark in Grenzen.

LG,
 CK

[Alexander (HH)]

Moin Moin!

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Du kannst nein sagen so oft du willst - da kommen dann von den vorgesetzten Meldungen wie "du siehst immer nur Probleme, ich will Lösungen" - wenn du dann die Lösung "wir brauchen mehr Zeit und müssen mehr Geld dafür verlangen oder wir müssen die Features reduzieren" kommt, hast du eine Endlosschleife (oft genug erlebt).

Ich bin da mittlerweie völlig schmerzfrei. Ich frage stumpf nach Prioritäten, und arbeite dann nach Prioritäten ab.

Insbesondere muss er NEIN sagen, NEIN meinen, und dann diese Aussage auch durchhalten. Wenn er NEIN sagt, es dann aber dennoch versucht, und dann scheitert, ist er der Doofe.

Das funktioniert in der Praxis nicht - du kannst nicht "NEIN" sagen und dich zurücklehnen und nichts mehr tun, weil du ja nein gesagt hast - da brauchst du schon einen sehr gutmütigen Chef der das Mitmacht.

Wer redet den von zurücklehnen? Ich sage "der Termin ist nicht zu halten, such Dir aus, welche 3 der 120 Punkte Du bis dahin fertig haben willst", und arbeite an den Punkten natürlich weiter!

Wenn er NEIN sagt, trotz hohem Drucks, und sein Chef glaubt ihm nicht, dann ist der Chef der Doofe, weil er trotz gegenteiliger Aussage nach außen kommuniziert hat, es ginge doch.

Wenn der Chef seinen Leuten nicht glaubt, ist es Zeit, den Job zu wechseln.

Auch wenn sich der Chef die Schläge beim Kunden abholt, das wird immer nach unten durchgereicht.

Nein, wird es nicht. Oft vielleicht, aber nicht immer. Mein erster Chef war da absolut genial, quasi das perfekte Interface zwischen Technik-Freaks und Management-Schlipsträgern.

Die Methodik leidet fast immer unter Zeitdruck - meistens gibts nichtmal Zeit eine Software ordentlich zu dokumentieren Geschweige denn zu testen. Ich hab' auch schon erlebt, dass ein komplexe Software ohne Pflichtenheft zu einem völlig irren, auch nach Daumen-Mal-Pi-Schätzung, Preis verkauft wurde. Bauchgefühlschätzung war "irgendwo 2 Monate" und verkauft wurde es um gute 2 Wochen - das hat dann zu unbezahlen Extraschichten über Weihnachten und Neujahr geführt - weil der Online-Termin auf kurz vor Weihnachten zugesagt wurde.

Überstunden wegen Fehlplanungen gibt's mit mir nicht. Ich hab's einmal gemacht, weil ich meinen ersten Chef nicht hängen lassen wollte, und das Ergebnis war ein Design-Albtraum, der mich und den Rest des Teams die nächsten Jahre verfolgt hat. Was ich in den paar Überstunden fabriziert habe, mußte über Jahre nach und nach gerade gebogen werden.

Mein Fazit: Überstunden kloppen lohnt sich einfach nicht, weil die Fehlerquote mit der Müdigkeit astronomisch hoch geht und man hinterher noch viel mehr Zeit braucht, die Fehler wieder zu beseitigen.

Software zu entwickeln ist Teamwork.

Die Kluft besteht idR. auch eher zwischen "Management" und "Technik" oder "Design" und "Technik" - wenn die Techniker untereinander schon nicht richtig zusammenarbeiten ist sowieso Hopfen und Malz verloren

Richtig. Entweder mögen sich die Technik-Leute, dann klappt alles wunderbar, oder man zickt sich ständig nur an und steht sich gegenseitig im Weg. Das hängt meiner Meinung nach sehr am Chef / Teamleiter ("Managing programmers is like herding cats"), aber natürlich auch an den Leuten. Ich denke, wenn die Fähigkeiten zu weit auseinander gehen, kann ein Team nicht funktionieren. Gerade nicht, wenn ein oder zwei Dumpfbacken sich komplett lern- und beratungsresistent zeigen.

Alexander

[suit]

Ich bin da mittlerweie völlig schmerzfrei. Ich frage stumpf nach Prioritäten, und arbeite dann nach Prioritäten ab.

Same here.

Wer redet den von zurücklehnen? Ich sage "der Termin ist nicht zu halten, such Dir aus, welche 3 der 120 Punkte Du bis dahin fertig haben willst", und arbeite an den Punkten natürlich weiter!

Ja - eins nach dem anderen, anders gehts eh nicht.

Auch wenn sich der Chef die Schläge beim Kunden abholt, das wird immer nach unten durchgereicht.

Nein, wird es nicht. Oft vielleicht, aber nicht immer. Mein erster Chef war da absolut genial, quasi das perfekte Interface zwischen Technik-Freaks und Management-Schlipsträgern.

Mein aktueller Chef tut das glücklicherweise auch nicht.

Mein Fazit: Überstunden kloppen lohnt sich einfach nicht, weil die Fehlerquote mit der Müdigkeit astronomisch hoch geht und man hinterher noch viel mehr Zeit braucht, die Fehler wieder zu beseitigen.

Mal eine Woche täglich eine Stunde dranhängen ist kein Problem, aber eine 60-Stunden-Woche schieben ist irre (aber auch das gabs bei meinen früheren Arbeitgebern schon - das führte dazu, dass einer der Kollegen mit Burn-Out endet und ich ein Projekt in die Hand bekam dass in derselben Zeit ohne Überstunden wesentlich weiter fortgeschritten hätte sein sollen. Der Mann hat einfach nur in den Code gestarrt und "nichts mehr getan" - zwar ist er die Woche 20 Stunden mehr im Büro gesessen, geleistet hat er aber nur etwas das, was die Zentralheizung auch macht).

Gerade nicht, wenn ein oder zwei Dumpfbacken sich komplett lern- und beratungsresistent zeigen.

Das hat dann oft zur folge, dass einer der "Nicht-Dumpfbacken" ständig bei den anderen sitzt und deren Arbeit macht und selbst zu nichts kommt - hatte ich auch alles schon :D

[niklaskamenisch]

Vermutlich sind in solchem Umfeld die Entwickler auch lieber Einzelkämpfer und Herrscher über "ihren" Code, den niemand anderes anfassen darf - was auch kein Teamwork ist, sondern Wissensmachtkampf, entweder motiviert durch die Gewissheit, "die können micht nicht rauswerfen, ohne selbst unterzugehen", oder aus Angst, dass die eigenen Unzulänglichkeiten ruchbar werden. Den Schaden hat in allen Fällen das Team insgesamt und der Auftraggeber, denn im ersten Fall wird die Chance verpasst, Spezialwissen breiter zu streuen, um in die Lage zu kommen, eben genau nicht von einer einzelnen Person abhängig zu sein (selbst wenn man denjenigen nie rauswerfen wollte, gibts immer unbeeinflussbare Faktoren wie Unfälle, Krankheiten oder Urlaub, oder unerwarteten erhöhten Arbeitsanfall). Im zweiten Fall wird die Chance verpasst, sich selbst durch Feedback der Kollegen weiterzuentwickeln.

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

Ich hab hier Grundsätzlich die Meinung, dass man nicht lange genug seine Meinung geäußert hat bzw sie nicht gut genug erklären konnte, wenn man in der Situation ist, sagen zu müssen "ich habs gleich gesagt". Ich merke es oft an mir selber, dass ich echt erst überzeugt werden muss, warum dieser und jener weg besser sein soll. Seit ich mich daran halte, sind diese "es wurde dir ja gesagt"-Fälle fast komplett ausgeblieben.

Ob man es ausspricht oder nicht, ist im Team natürlich eine wichtige sache. Aber kann sich jemand hier davon los sagen, dass er nicht im Kopf für sich dann denkt: "ich habs immer gesagt, das geht schief". Die Schuld suchen ist, erst recht wenn der Kunde es mitbekommt, nicht so toll. In der Zeit wo die Schuld gesucht wird, hätte man schon wieder 2 Lösungen finden können!

Das schwere ist oft, dass man nicht irgendwann hochnäßig wird, nur weil der andere öfters in die Fehler gelaufen ist, "die ich ihm vorrausgesagt habe". Irgendwann fühlt man sich dann "besser" und dann ist der Streit vorprogrammiert. Wenn einer Anfängt mit dem Finger zu deuten, dann wird es, wie Sven so schön umschrieben hat, ein Wettkampf, wer mehr fehler beim anderen findet ;)

Gruß Niklas

[unknown]

Meiner Erfahrung nach kommt Müll hauptsächlich durch zwei Dinge zu Stande:

1. der Entwickler hat keine Ahnung davon was er eigentlich tut

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

3. der Entwickler  macht sich unentbehrlich, er ist der einzige der seinen Müll überhaupt noch pflegen kann.

Meist wird auf solche dann auch noch große Stücke gehalten, weil sie mit den unweigerlich folgenden Fehlerbehebungen der resultierenden Fehler ständig present sind.
"Hey, der hat schon wieder ein Problem behoben!"
Das die Probleme selbst verschuldet sind und mit der einen Behebung zwei neue Probleme auftauchen ist Nebensache.

[Alexander (HH)]

Moin Moin!

3. der Entwickler  macht sich unentbehrlich, er ist der einzige der seinen Müll überhaupt noch pflegen kann.

Meist wird auf solche dann auch noch große Stücke gehalten, weil sie mit den unweigerlich folgenden Fehlerbehebungen der resultierenden Fehler ständig present sind.
"Hey, der hat schon wieder ein Problem behoben!"
Das die Probleme selbst verschuldet sind und mit der einen Behebung zwei neue Probleme auftauchen ist Nebensache.

Ja, auch den Effekt gab es bei $VORGÄNGER, mit ein Grund, warum er beim einen Geschäftsführer Narrenfreiheit hatte. Das neue Fehler quasi alle fünf Minuten aufpoppten, Whac-A-Mole-Style, kam beim GF offenbar nicht an.

Alexander

[niklaskamenisch]

hi,

Meiner Erfahrung nach kommt Müll hauptsächlich durch zwei Dinge zu Stande:

1. der Entwickler hat keine Ahnung davon was er eigentlich tut

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

3. der Entwickler  macht sich unentbehrlich, er ist der einzige der seinen Müll überhaupt noch pflegen kann.

4. der Programmcode soll kaputt gehen. Man muss ja irgendwann die Leute zu einer neuen Version zwingen (oder warum gibt es z.b. bei Windows die Arbeitsspeicher beschränkungen ;) )

Gruß Niklas