Laden...

Was Chefs entscheiden dürfen und was nicht?

Erstellt von ralfw vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.839 Views
Hinweis von herbivore vor 13 Jahren

Abgeteilt von Tatsächlicher Nutzen von Unit-Tests

ralfw Themenstarter:in
71 Beiträge seit 2010
vor 13 Jahren

Also das mit den Chefs ist so eine Sache der Argumentation. Niemend möchte Zeit und Geld in Tests investieren, sondern für fertige Software. Fehlerfreiheit wird da schnell als Selbstverständlichkeit abgetan.

Ich halte die Chefs als Hindernisse für Unit Tests für ein hausgemachtes Problem der Entwickler. Wenn ein Chef mir reinreden würde und sagte, ich solle mal die Klassen so und so schneiden, würd ich ihm da folgen? Wenn ein Chef mir reinreden würde und sagte, ich solle mal besser EF statt NHibernate benutzen, würd ich ihm da folgen?

In beiden fällen lautet die Antwort nein. Chefs haben das nicht zu entscheiden. Das entscheidet entweder ein Team oder ich selbst. Aber nicht Chefs. Selbst dem Entwicklungschef würde ich das nicht einfach so abnehmen.

Dasselbe gilt, wenn ein Chef mir sagte, ich solle das mal mit diesen Unit Tests sein lassen. Das ist ganz einfach none of his business.

Und wer jetzt sagt, ich würde es halt nicht verstehen, wie das so ist, wenn man angestellt ist, der pinselt sich schlicht - sorry to say - in eine Opferrolle. Das ist natürlich eine legitime Haltung, um durchs Leben zu kommen. Aber ich muss sie nicht teilen. Und ich halte sie für ganz schädlich für die Branche und auch für die Kunden.

Unit Tests oder nicht ist insofern auch nur eine oberflächliche Diskussion. Sie redet um den heißen Brei herum. Das Wurzelproblem liegt beim Thema Vertrauen und beim Thema Qualitätsbewusstsein und beim Thema Macht und beim Thema Sicherheitsempfinden (aka "den eigenen Arsch retten").

-Ralf

Gelöschter Account
vor 13 Jahren

Ich halte die Chefs als Hindernisse für Unit Tests für ein hausgemachtes Problem der Entwickler. Wenn ein Chef mir reinreden würde und sagte, ich solle mal die Klassen so und so schneiden, würd ich ihm da folgen? Wenn ein Chef mir reinreden würde und sagte, ich solle mal besser EF statt NHibernate benutzen, würd ich ihm da folgen?

es geht dabei nicht, sich den passenden fürsten auszuwählen....

In beiden fällen lautet die Antwort nein. Chefs haben das nicht zu entscheiden.

in jedem fall entscheidet derjenige, der meinen gehaltsscheck unterschreibt, das was ich tue und zur not wie ich es tue.

Dasselbe gilt, wenn ein Chef mir sagte, ich solle das mal mit diesen Unit Tests sein lassen. Das ist ganz einfach none of his business.

das selbe gilt für ganz viele bereiche aber das hält die meisten chefs nicht davon ab, sich da einzumischen. warum? weil sie allein die verantwortung tragen müssen.... daher ist das ein ganz normaler drang, da mitmischen zu wollen.

Und wer jetzt sagt, ich würde es halt nicht verstehen, wie das so ist, wenn man angestellt ist, der pinselt sich schlicht - sorry to say - in eine Opferrolle.

das verstehst du scheinbar wirklich nciht (mehr).
gewissen spielraum hat man immer, wenn man einigermaßen standhaft ist aber alles kann man nie durchsetzen und dann muss man abwägen, was wichtig ist und was nciht wichtig ist (ja, ich denke das unittests nicht das wichtigste auf der welt sind...).

man muss auch bedenken, das es nciht leicht ist einem BWL menschen die vorteile von unmittelbarer mehrarbeit zu vermitteln (unabhängig davon wieviel man später spart) und das ganz besonders dann, wenn der kunde auch nur BWL versteht und intensiver mit eingebunden ist (+ ein wenig zeitknappheit).
da magst du jetzt argumentieren, das ich evtl schon aufgegeben habe oder lieber opfer spiele oder das ich mich nicht durchsetzen kann doch ich muss dir sagen, das das mit all dem ncihts zu tun hat. das ist pure diplomatie und politik, die darüber entscheidet ob unittest gemacht werden oder nicht. und in diesem gebiet erreicht man nie alles was man will.

M
164 Beiträge seit 2009
vor 13 Jahren

"... und wenn jemand eine andere Meinung hat als ich, dann setzen wir uns zusammen und diskutieren so lange, bis alle meiner Meinung sind!"

Situation: 2 Frameworks stehen zur Auswahl. Es muss bestimmt werden, welches Framework gewählt wird.
Die Entwickler stellen zu jedem Framework Pros und Contras auf. Dann wird zusammengesessen und diskutiert, bis auch die Vorgesetzten die Meinung der Entwickler sind.

Schlussendlich muss der Chef sagen, welches Framework genommen wird. Er muss jedoch das selbe Framework wie die Entwickler wählen, oder sonst muss noch länger diskutiert werden.

Ein guter Chef zeichnet sich auch dadurch aus, dass er die Meinungen und Wünsche der Entwickler respektiert und gegen aussen diese auch so vertritt.

(:::

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Ralf,

Wenn ein Chef mir reinreden würde und sagte, ich solle mal die Klassen so und so schneiden, würd ich ihm da folgen? Wenn ein Chef mir reinreden würde und sagte, ich solle mal besser EF statt NHibernate benutzen, würd ich ihm da folgen?

wenn du persönlich diese Fragen - grundsätzlich, so klingt es für mich - mit nein, beantwortest, dann scheinst du mir einer der wenigen zu sein. Obwohl ich mich für jemanden halte, der bei weitem nicht jede Entscheidung einfach hinnimmt, kann ich mir in beiden Fällen, viele Gründe vorstellen, warum ich der Entscheidung des Chefs folgen würde. Wenn z.B. die Interoperabilität zwischen mehreren Projekten hergestellt werden soll oder auch nur Lizenzkosten gespart werden sollen, sind das gute Gründe für die Entscheidung für ein bestimmtes, einheitliches Framework. Auch würde ich den Sinn, wenn firmenweit einheitliche Coding-Konventionen vorgegeben werden, die die Art, wie ich Klassen schreibe, beeinflussen, nicht grundsätzlich und pauschal in Abrede stellen.

Die Macht der Chefs ist durch ihr Amt und ihre Funktion gegeben und nicht durch Versäumnisse von Entwicklern. Entwickler können die Macht des Chefs allenfalls einschränken. Und auch das nur in Punkten, in denen sie gute Argumente haben. Gut bedeutet dabei, dass sie nicht nur ihnen einleuchten, sondern auch dem Chef.

Wenn ich dem Chef sage, ohne Unit-Test sinkt die Qualität und er sagt, ja, das ist klar, aber wenn die Klassen nicht bis zum Stichtag implementiert sind, müssen wir eine so hohe Vertragsstrafe zahlen, dass die Firma insolvenzgefährdet ist, dann ist das ein gewichtiger Grund.

Für mich klingen deine Aussagen so, als wären die Kriterien der Entwickler das einzige was zählt. Es gibt aber noch viele andere Umstände, die berücksichtigt werden müssen.

Worin wir uns einige sind: Jeder Entwickler sollte seinen Standpunkt vertreten und nicht davor zurückschrecken, dass der Chef der Chef ist. Zum einen ist der auch nur ein Mensch und zum anderen steckt er in meinem Tätigkeitsfeld zwangsläufig weniger tief drin als ich selbst. Ich kann also Entscheidungskriterien auf der reinen Arbeitsebene sicher besser finden und bewerten. Deshalb sollte man den Chef an dieser Expertise auch teilhaben lassen. Genauso muss man aber auch akzeptieren, dass dies nicht die einzigen Gründe sind, die die Entscheidung beeinflussen.

Sieh es doch mal anders herum: Was wäre denn, wenn der Chef vorschreibt, dass Unit-Tests durchgeführt werden müssen (weil er irgendwo gelesen hat, wie toll die sind) und ein Entwickler den Nutzen nicht sieht (die Umfange in dem anderen Thread, zeigt ja, dass es auch solche gibt)?. Wenn der Entwickler dem Grundsatz, den ich eben beschrieben habe, folgt, dann würde er auf seinen Chef einwirken und versuchen, seine Entscheidung abzuwenden. Wäre es gut, wenn er damit Erfolg hätte? Die Entscheidungen eines Chefs müssen nicht schlecht sein, nur weil er Chef ist. Auch ich hatte das schon, dass ich Entscheidungen meines Chefs (ja, auch ich habe mal angestellt gearbeitet) schlecht fand und sich nachher herausgestellt hat, dass er richtig lag und ich falsch.

Das alles mal davon ganz abgesehen, dass es autoritäre Chefs gibt, die nicht mit sich reden lassen, egal was man vorbringt.

Was du vorschlägt, ist ja letztlich, dass man dem Chef bei bestimmten Fragen, die Entscheidungskompetenz abspricht und selber entscheidet. Das geht mir eindeutig zu weit. Wenn du dann noch Entwickler, die das nicht tun, als "schädlich für die Branche und auch für die Kunden" hinstellst und von einer Opferrolle sprichst, in die sich sich begeben, empfinde ich das als unangemessene Beschimpfung vom Hohen Ross herab.

Ich werde dir in dem von dir propagierten Sinne entgegentreten und dir sagen, dass es nicht deine Sache ist, in dieser Weise über die vielen Entwickler da draußen, die einen guten Job machen, zu urteilen.

Mir ist manchmal wirklich nicht klar, was von dir eine gezielt eingesetzte Provokation ist, um die Leute aufzurütteln und was eine herablassende, herabwürdigende Polemik.

herbivore

M
153 Beiträge seit 2010
vor 13 Jahren

Ich glaube nich dass es Einzelentscheidungen geben sollte pro oder contra Unit-Tests. Das ist eine Sache der Entwicklungsphilosophie des Hauses, der verwendeten Werkzeuge und - ja auch - eine Sache der Projektplanung.

Man stelle sich einmal vor: Jeder Entwickler muss ständig gegen Windmühlen ankämpfen und immer wieder den Nutzen argumentieren. Die benötigte Zeit für Unittests muss sich irgendwo in der Projektplanung wiederfinden. Und das Team selbst sollte über die verwendeten Werkzeuge dafür entscheiden. Ist diese einmalig getroffen, warum nicht auch mit dem Chef zusammen?, dann kann sich die Diskussion nur noch auf Zeitpunkt und Umfang konzentrieren. Und da wird ein wenig Kompromissbereitschaft notwendig sein.

Was natürlich nicht geht ist, dass jeder Entwickler seine eigenen Werkzeuge und seine eigene Systematik in den Entwicklungsprozess einbringt und dann zur Wahrheit erhebt. Vielleicht gibt es noch einen zweiten Entwickler der, sagen wir mal EF bevorzugt und sich ebenfalls nicht "dreinreden" lässt? Sollen dann beide Technologien verwendet werden - und wer entscheidet in einem solchen Konfliktfall? Das ist Sache des Entwicklungsleiters. Er muss vereinheitlichen ohne gleichzumachen und Kompromisse finden ohne allzusehr einzuschränken.

Und wenn ein Entwickler wichtige Dinge nicht umsetzen kann, beispielsweise Unit-Tests, dann muss er irgendwann entscheiden - bleiben und akzeptieren oder den nächsten Schritt machen und ein Unternehmen suchen, für das Unit-Tests selbstverständlich sind.

742 Beiträge seit 2005
vor 13 Jahren

Ich denke es ist klar, dass man Chefs nicht einfach so pauschalisieren kann. Je nach Position im Unternehmen ist der direkte Vorgesetzte noch ein Mitglied der Entwicklungsabteilung oder des Teams und ich habe in den drei Firmen in denen ich bisher war noch nie erlebt, dass diese Leute Entscheidungen einfach durchdrücken sonderen Themen mit allen diskutiert werden.

Wenn aber von weiter oben solche Entscheidungen getroffen werden, halte ich es fast schon für unverantwortlich einfach nachzugeben. Neben dem meist deutlich besseren Gehalt und der Verantwortung wechselt nämlich auch die Perspektive auf dem Weg ins obere Management. Während man in den unteren Ebenen meist mit operativen Entscheidungen ausgelastet ist, ist es die Aufgabe des mittleren und höheren Managements taktische und sogar strategische Entscheidungen zu treffen. Mischt sich so jemand dann noch in Kleinigkeiten wie Unit Tests oder Framework Auswahl ein, so bedeutet dass doch fast schon, er kann sich seinen richtigen Aufgaben nicht mehr voll widmen.
Diese Erfahrung habe ich schon mehrmals gemacht. Fehlende Weitsicht und Konzentration auf kleine Belanglosigkeiten (Chef möchte anderes Icon, Menüstruktur gefällt dem Chef nicht) kann für die ganze Firma oder Abteilung Folgen haben. Zudem müsste der Chef ja auch ein Übermensch sein, wenn er Entwicklerentscheidungen richtig treffen kann und seine Aufgaben bewältigen kann.

Leider ist der Absolutismus noch nicht ausgestorben und ich kann es durchaus verstehen, wenn man nicht immer gegen Windmühlen kämpfen will. Zum einen ist es extrem anstrengend und zum anderen hat man ja auch noch andere Verantwortungen (Familie etc.).

Da ich nur Student bin, keine Familie habe und man zZ die Entwicklerjobs in Karlsruhe hinterhergeschmissen bekommt, kann ich es mir Gott sei Dank erlauben meine Job immer dann zu wechseln, wenn mir die Entscheidungsstrukturen nicht gefallen.

EDIT: Ich denke die Aufgabe der Chefs ist es, Rahmenbedingungen zu setzen. Das könnnen wichtige Termine sein, Bedingungen an Qualität, Kosten, die Aufgabe des Entwicklers ist es aus diesen Rahmenbedingungen mit den von ihm gewählten Werkzeugen das Maximum herauszuholen, wenn das aber durch Kontraproduktive Entscheidungen gefährdet wird, sehe ich schwarz.

J
1.114 Beiträge seit 2007
vor 13 Jahren

Ich halte die Chefs als Hindernisse für Unit Tests für ein hausgemachtes Problem der Entwickler. Wenn ein Chef mir reinreden würde und sagte, ich solle mal die Klassen so und so schneiden, würd ich ihm da folgen? Wenn ein Chef mir reinreden würde und sagte, ich solle mal besser EF statt NHibernate benutzen, würd ich ihm da folgen?

In beiden fällen lautet die Antwort nein. Chefs haben das nicht zu entscheiden.

Falsch, denn dafür sind Chefs da: um Entscheidungen zu fällen.

Wenn einem das nicht passt, dann hat man entweder im Vorstellungsgespräch nicht herausgefunden, dass die Firmenpolitik vielleicht nicht gerade zu einem passt, oder man hat im Nachhinein die Möglichkeit, den Arbeitsplatz zu wechseln und sich einen anderen Chef zu wählen.

Aber nur über das Managment zu lamentieren is unsinnig.

742 Beiträge seit 2005
vor 13 Jahren

Falsch, denn dafür sind Chefs da: um Entscheidungen zu fällen.

Sehe ich nicht so. Chefs sind dafür da, Entscheidungen in ihrem "Abstraktionslevel" zu fällen.

J
537 Beiträge seit 2007
vor 13 Jahren

Falsch, denn dafür sind Chefs da: um Entscheidungen zu fällen. Aber nur Entscheidungen die das WAS betreffen (Grundanforderungen). Entscheidungen über das WIE liegen im Groben beim Team und im Feinen beim Entwickler.

TDD ist ein WIE und kein WAS 😉

OR-Mapper sind auch eine Frage des WIE, die das Team zu entscheiden hat.

Sollte der Chef da mitentscheiden wollen, vertraut er den Entwicklern nicht, bzw. vertraut er den Fachleuten nicht, die er speziell dafür eingestellt hat.

Ich weis, das der Alltag anders aussieht, aber teilweise auch deswegen, weil die Entwickler auch ihren eigenen Fähigkeiten nicht trauen oder einfach nur aus Bequemlichkeit. Man muss dem Chef auch mitteilen, das man der Spezialist ist, den man beim Bewerbungsgespräch verkauft hat und als der man eingestellt worden ist.

Gelöschter Account
vor 13 Jahren
S
469 Beiträge seit 2007
vor 13 Jahren

Als Chef zu viele Freiheiten zu gewähren halte ich für falsch.
Da programmiert der eine nach diesen Richtlinien und der andere nach jenen, einer verwendet diese Entwicklungsumgebung der andere mag die nicht und nimmt ne andere,...also bitte das ist doch Chaos pur, so kann man privat oder in ner kleinen Bastelbude entwickeln. Aber als Kunde würde ich, wenn ich wüsste dass eine Firma so agiert, dieser Firma nicht vertrauen.
Chefs sollten bei elementaren Fragen sehrwohl entscheiden wo's langgeht, ABER ein guter Chef wird für seine Entscheidung die überzeugenden Argumente seiner verlässlichen Mitarbeiter abwägen. Und wenn der Grund dafür, einen bestimmten Weg einzuschlagen, nicht Bequemlichkeit oder persönliche Vorliebe ist, dann lassen sich auch immer gute Gründe dafür finden und so verpacken, dass auch ein materie-fremder Chef sie versteht. Wobei es in einer guten und einigermaßen großen Firma nicht nur einen materie-fremden Chef und die Programmierschaben gibt, sondern bessere Abstufungen in den einzelnen Abstraktionsleveln, die dann jeweils für unterschiedliche Entscheidungsfragen zuständig sind (und für diese Stufe auch ausreichend bewandert sind).

gruß
sth_Weird

++++++++++++++++++++~+
Fluchen ist die einzige Sprache, die jeder Programmierer perfekt beherrscht


Linux is for free...if your time is worth nothing
++++++++++++++++++++~+