Kommentare zu: Die Pfadfinderregel

Von: Kleine Schritte sind besser als keine Schritte « Stephan Schmidt

Kleine Schritte sind besser als keine Schritte « Stephan Schmidt — Sat, 06 Feb 2010 06:56:35 +0000

[...] an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den [...]

Von: ragtek

ragtek — Fri, 15 Jan 2010 15:39:07 +0000

Jein, beim Chef ist es auch nicht so ohne.
Hier habe ich eine extrem schlechte Erfahrung gemacht, die dazu geführt hat, das ich gekündigt habe.

Habe das Problem auch hier http://www.php.de/off-topic-diskussionen/62989-kollegen-und-chefprobleme.html gepostet, jedoch ist dort leider niemand auf die Diskussion/Frage eingegangen.
Mein ehemaliger Chef war genau so einer.
Schnelles Profit + never change a running System.
Na hurra, perfekte Arbeitsbedingungen.

Von: Mathias Methner

Mathias Methner — Fri, 15 Jan 2010 09:31:38 +0000

@Christian
Spitzen Buchtipp. WIrd gleich bestellt

@ragtek
Argumente vorm Kunden zu finden ist sicher schwierig, da bin ich bei dir. ‘Never change a running system’, wer kennt den Satz nicht?

Allerdings gibt es auch eine andere Seite, und zwar die Inhouse-Entwicklung. Hier muss man vor dem Chef argumentieren, was ich in aller Regel für etwas einfacher halte.

Von: Nils Langner

Nils Langner — Fri, 15 Jan 2010 07:08:01 +0000

@ragtek: Ideenschmiede wird im neuen Layout anders aussehen. Das Problem, was du mit dem Kunden beschreibst ist glaube ich eine Zwickmühle. Nehmen wir an, du hast eine wirklich miese Methode, da musst du aber nur 3 mal im ganzen Jahr was anfassen. Jetzt setzt du dich hin und refaktorierst sie. Das dauert vll. 1 Tag. Der Kunde wird niemals das Gefühl haben, dass sich dadurch an der Situation was verbessert hat, nehme ich an.
In so einer Situation wüsste ich aber selbst nicht, was ich anordnen würde.

Von: ragtek

ragtek — Fri, 15 Jan 2010 06:54:42 +0000

Ja, ich auch. Wobei ich mir denke, dass es vor allem vom Kunden und vom Projekt/Projektgröße abhängt.

Ich kann mir schon vorstellen, dass bei größeren Projekten und Kunden die eine Ahnung von der IT haben, ab und zu ein “Ja” auf die Frage kommen wird.

Persönlich hatte ich noch nie die Ehre, bei wirklich größeren Projekten mitzuarbeiten.
Bei den kleinen Umsetzungen war es dann aber IMMER ein „wieso?“ Es funktioniert doch bis jetzt auch hervorragend, also wieso soll ich die 10h Mehraufwand investieren?

Auch wenn es nicht wirklich zum Thema passt, ein Beispiel: Das „ärgerlichste“ war eine Firmenseite, die noch auf Frames basierte.
Da konnte man argumentieren was man wollte, die Firma die ihm die Seite erstellt hat, hat wohl erfolgreich Gehirnwäsche betrieben, da er sich einfach nicht umstimmen lies.

Von: David Müller

David Müller — Fri, 15 Jan 2010 06:46:02 +0000

Man könnte es mit dem Argument versuchen, dass zukünftige Änderungen in wesentlich kürzerer Zeit umgesetzt werden können – Ob das allerdings gelten gelassen wird, wage ich zu bezweifeln.

Von: ragtek

ragtek — Fri, 15 Jan 2010 06:39:03 +0000

Mein Standpunkt/Erfahrung ist auch, dass der Kunde für so etwas kaum zahlen wird, da es in der Vergangenheit ja auch funktioniert hat…

Einige haben ja geschrieben, dass man die Methode komplett verstehen sollte, bevor man sie umbaut/neu programmiert.
Sollte man dann nicht eventuell die komplette Klasse verstehen und sich mit jeder einzelnen Methode beschäftigen?
Ab und zu ist es ja so, dass es mehrere Methoden gibt, die im Grunde dasselbe machen. Hier könnte man vorgreifen und gleich 2,3 Methoden “refactoren”(gibt es dafür kein schöneres Wort??)
Nur wer Zahlt das? Der Kunde eher nicht, da es ja in der Vergangenheit ja sowieso funktioniert hat…

PS:
Eventuell sollte man die Ideenschmiede mal aktualisieren, da zB die Pfadfinderregel ja nun rausfliegen sollte.
Eventuell gibt es noch einige Punkte, die schon umgesetzt wurden.