Ist es in der Stellenbeschreibung eines Entwicklers angemessen, "fehlerfrei" als Schlüsselausgabe zu haben? [geschlossen]


10

Im Rahmen einer Überprüfung aller Stellenbeschreibungen hat mein Unternehmen beschlossen, Folgendes als Schlüsselergebnis aufzunehmen:

Die Entwicklung der Website wurde pünktlich, innerhalb der Spezifikation und fehlerfrei abgeschlossen

Angesichts der Tatsache, dass sich die Spezifikationen regelmäßig ändern, gibt es keinen formalen Änderungskontrollprozess und die Umgebungen sind, sagen wir, ein wenig unvorhersehbar. Wie realistisch und vernünftig ist dieser KPI?


20
Völlig unrealistisch. Das wurde wahrscheinlich von jemandem geschrieben, der mit einem zu vielen schlechten Entwicklern zusammengearbeitet hat. Es könnte aber auch die Schuld eines schlechten Managements sein. Nicht genügend Informationen bereitgestellt.
Mark Canlas

11
Der Entwickler, der in seinem Lebenslauf "schreibt fehlerfreien Code" eingibt, ist lächerlich genug, um der Position zu entsprechen.
P.Brian.Mackey

12
Der einzige Code, von dem nachgewiesen werden kann, dass er keine Fehler aufweist und sein Ziel erreicht, ist eine leere Codebasis, die behauptet, nichts zu tun.
Unholysampler

8
pfft ... sieht aus wie eine Sündenbockklausel, um Menschen leicht zu können. "Entschuldigung, Sie haben Ihren Arbeitsvertrag nicht eingehalten ... wir werden Sie ohne Vorankündigung oder zusätzlichen Grund entlassen. Tootles."
Steven Evers

5
Natürlich ist es fehlerfrei. Der Compiler sagt: 0 Fehler, 0 Warnungen. Das erfüllt die Jobanforderungen vollständig :-)
Ferruccio

Antworten:


21

"Fehlerfrei" ist viel zu subjektiv . Die "Unerfüllte Funktionsanforderung" eines Mannes ist der "Fehler" eines anderen Mannes. Etwas wie "Sollte im Wesentlichen den Designspezifikationen entsprechen" wäre angemessener. Ich habe noch nie gesehen, was Sie in einer Stellenbeschreibung beschreiben. Ich habe es für Auftragsarbeiten gesehen , aber nicht für Mitarbeiter.


9

Ich werde mich den meisten Antworten widersetzen und sagen, dass dies absolut vernünftig und realistisch ist.

Wird die gesamte Entwicklung pünktlich abgeschlossen sein? Natürlich nicht, nicht immer.

Wird die gesamte Entwicklung innerhalb der Spezifikation abgeschlossen sein? Sie möchten es hoffen, aber manchmal ist dies einfach nicht möglich und Sie müssen eine Abweichung von einer unmöglichen oder widersprüchlichen Spezifikation anzeigen.

Und wird jede Entwicklung fehlerfrei sein? Niemals .

Aber dafür ist ein KPI gedacht. Es ist etwas, das gemessen werden kann und anhand dessen Sie Leistung und Fortschritt verfolgen können.

Wenn sich die Spezifikationen regelmäßig ändern, es keinen formalen Änderungskontrollprozess gibt und die Umgebungen nicht vorhersehbar sind, ist es eine Herausforderung, diese Zahl nahezu "fehlerfrei" zu halten. Aber diese Herausforderung ist Ihre Aufgabe , und Sie werden sie hoffentlich ganz gut erledigen - und im nächsten Jahr sogar noch besser, wenn Sie mehr Übung darin haben, mit dem besonderen Chaos Ihres Unternehmens umzugehen.

Gegenfrage: Welche KPIs würden Sie einem Programmierer vorschlagen? Es ist eine schwierige Frage. Vieles, was wir tun, ist schwer zu messen.


4
Es ist praktisch unmöglich, eine Codebasis von signifikanter Größe als "fehlerfrei" zu garantieren, da möglicherweise ein Fehler vorliegt, den Sie einfach nicht gefunden haben. Was ist ein Fehler? Ein Käfer? Wie wird das gemessen?
Philosodad

1
@philosodad - das ist irgendwie mein Punkt. Es wird nicht fehlerfrei sein . Wenn in diesem Jahr x Fehler in dem von Ihnen geschriebenen Code gefunden werden und in diesem Jahr x-4 , haben Sie Ihren KPI verbessert. Was ein Fehler ist, ist wirklich eine Angelegenheit für Ihr Unternehmen und zweifellos eine, die einige Argumente bezüglich "Fehler" vs. "undokumentierte Anforderung" vs. "geänderte Anforderung" vs. "Meinungsverschiedenheit" hervorruft.
Carson63000

3
@ Carson63000: aber das ist mein Punkt! Ein KPI, der garantiert mehrere Argumente hervorruft, zu unvermeidlichen Meinungsverschiedenheiten zwischen den Parteien führt und eine Schlüsselmetrik vage definiert, ist zumindest problematisch. Um Ihr Beispiel zu nennen: Wenn ein "Fehler" ein subjektives Maß ist, ist es vorhersehbar, dass Manager Fehler so definieren, dass sie besser aussehen, sodass jeder eine reduzierte Fehlerrate bei genau derselben Leistung hat. Ein neuer Manager kann es jedoch nach oben und nach unten definieren, um zu zeigen, wie er genau die gleiche Ausgabe "verbessert" hat.
Philosodad

3
Es wäre vorzuziehen, ein Ziel ohne kritische Fehler zu haben (kritisch definieren). Oder um eine sich verbessernde Fehlerrate zu haben. Und noch besser, dieses Zeug sollte ein Ziel für die jährliche Leistungsbeurteilung sein und nicht Teil einer Stellenbeschreibung.
schnell_now

3
KPIs beinhalten ein Ziel, das nicht nur nicht ganz erreicht, sondern auch übertroffen werden kann. Sie verwenden es, um zu messen, ob Sie schlechter oder besser als das KPI-Ziel abschneiden. Ich sehe nicht, wie "fehlerfrei" überschritten werden kann. Selbst wenn dies als KPI gedacht ist, ist es daher fehlerhaft. Ein besserer KPI wäre, die Anzahl der Fehler, Testberichte zu messen, die anhand des von Ihnen geschriebenen Codes eingereicht wurden, der zu tatsächlichen Codeänderungen usw. führte.
Marjan Venema

4

Wenn es sich um eine Jobbeschreibung handelt, würde ich mir darüber keine Sorgen machen, da die Arbeit an fehlerfreiem Code Teil des Jobs eines typischen Programmierers ist (auch wenn wir ihn niemals erreichen können).

Als KPI ist es jedoch zu weitreichend, aber beschuldigen Sie nicht die Person, die es vorgeschlagen hat, wenn sie keine Programmierer sind. Erklären Sie einfach, dass diese Aussage ein Ziel festlegt, das für die Organisation möglicherweise unerwünscht ist. Das heißt, "fehlerfrei" ist ein extrem hoher Standard für Software, deren Lieferung ein Vermögen kosten würde. Erklären Sie, dass für ein gut ausgeführtes Softwareprojekt entschieden werden muss, ob es sich lohnt, für jeden Fehler wertvolle Entwicklerzeit aufzuwenden.

Hier ist ein Beispiel, das den Punkt gut macht.
Ein Programmierer stellt fest, dass unsere Software einen "Jahr 3000" -Fehler aufweist und nach dem 31. Dezember 1999 nicht mehr funktioniert. Es dauert 6-8 Monate, um das Problem zu beheben. Basierend auf dem KPI wird empfohlen, dieses Projekt zu übernehmen, obwohl es keinen wirklichen Wert für das Unternehmen hat.

Okay, dieses Beispiel ist ein wenig extrem, aber in jedem Softwareprojekt werden buchstäblich Dutzende kleiner Fehler entdeckt, die ebenfalls nicht den ROI generieren, der zur Behebung dieser Fehler erforderlich ist. Wenn der KPI stattdessen implizieren sollte, dass der Programmierer den Fehler überhaupt nicht einführt, erscheint es für JEDEN Mitarbeiter vernünftig, sich an den Standard zu halten, niemals einen Fehler bei der Ausführung seiner Arbeit zu machen?


Es ist unwahrscheinlich, dass Sie einen KPI haben, der "das Beheben von Fehlern abdeckt, die vom Management als kein Problem eingestuft wurden und nicht behoben werden müssen".
Carson63000

@Carson - nicht in einigen großen Unternehmen, die ich kenne. Dumme Ziele sind Teil ihrer Art, Geschäfte zu machen.
schnell_now

3

Nein

Es ist nicht nur nicht angemessen, es ist lächerlich

Tests können nur das Vorhandensein von Fehlern nachweisen, nicht deren Fehlen. Daher müsste jedes Programm, das im Rahmen dieser Verpflichtung geschrieben wird, einen strengen Korrektheitsnachweis enthalten ... und eine 100% ige Testabdeckung

"Hüten Sie sich vor Fehlern im obigen Code. Ich habe es nur als richtig erwiesen, nicht ausprobiert." - D. Knuth

KPIs sind ein Maß für Erfolg und Fortschritt in Richtung eines Ziels. Sie sind kein binärer Umschalter "Fehlerfreier Code = Erfolg, ein einziger Fehler = Fehler, Sie sind gefeuert!"
Carson63000

@Carson: "fehlerfrei" ist kein KPI, sondern eine Fantasie.
Steven A. Lowe

1
Klingt für mich nach einer Naht. Geben Sie etwas Dummes in die JD ein, und wenn eine Entschuldigung benötigt wird, kann die Person entlassen werden, weil sie nicht die Leistung erbringt, die die JD erfordert.
schnell_now

3

Natürlich ist es die Aufgabe und Verantwortung jedes Programmierers, fehlerfreien Code zu schreiben. Das ist eine durchaus vernünftige Erwartung. Wie können Sie ein professioneller Programmierer sein, wenn Sie Code veröffentlichen, der nicht funktioniert? Wie können Sie sich als professioneller Programmierer betrachten, wenn Sie Code veröffentlichen, von dem Sie nicht wissen, dass er funktioniert?

Wenn Sie einen Maler einstellen, erwarten Sie, dass er seine Arbeit gut macht. Sie erwarten, dass das Ergebnis seiner Arbeit fehlerfrei ist. Wenn es Fehler gibt, erwarten Sie, dass er die Verantwortung für diese Fehler übernimmt und sie kostenlos behebt. Was mehr ist, wenn die Fehler Sie Geld kosten, erwarten Sie, dass er Sie erstattet. Warum haben Sie diese Erwartungen? Weil der Maler ein Profi ist.

Programmierer lieben es, alle anderen für ihre Fehler verantwortlich zu machen. "Mein Programm hat Fehler aufgrund der Anforderungen oder des Zeitplans oder weil der Mond im 8. Haus ist." Aber es gibt wirklich niemanden, dem man die Schuld geben kann. Wenn Ihr Programm Fehler enthält, legen Sie diese dort ab.

Unser Beruf wird nie sein ein Beruf bis Programmierer erkennt , dass der Bock mit ihnen hält. Dass sie für die Qualität ihrer Programme verantwortlich sind.

Wissen Sie, warum Unternehmen Software-QS-Abteilungen eingerichtet haben? Weil Programmierer ihre Arbeit nicht machten! Programmierer haben so viel Mist veröffentlicht, dass Unternehmen ganz neue Abteilungen bilden mussten, um sie zu überprüfen.

Wie lang ist die Fehlerliste? Es ist professionell, Tausende von Fehlern in der Fehlerdatenbank zu haben? Ganz klar ist es nicht. Es ist ein Spiegelbild von schlechtem Benehmen, schlechter Disziplin und ehrlich gesagt Schande.

Wir werden niemals ein Beruf sein, bis wir erkennen, dass es unsere Aufgabe ist, dafür zu sorgen, dass die Qualitätssicherung nichts findet.


+1, aber ich möchte fehlerfrei eher als persönliches Ziel als als Realität betrachten. Wir sollten uns alle dafür entscheiden, aber wenn wir nicht endlose Ressourcen haben, werden wir nicht dorthin gelangen, zumindest nicht, wie wir jetzt Software entwickeln.
rjnilsson

Ich könnte Onkel Bobs Ansichten nicht stärker zustimmen. Es ist sehr viel eine Frage der Professionalität.
Johnsyweb

1
Diese Position wird leicht durch die Tatsache erschwert, dass meinem Management absolut klar ist, dass ich es vorziehen würde, ihnen jetzt fehlerhafte Software zu geben, anstatt sie später zu korrigieren. Ich glaube nicht, dass ich in dieser Situation allein bin.
Tom Anderson

3

Leider klingt dies nur nach einer Möglichkeit für sie, "alle Grundlagen abzudecken", und wird eindeutig nicht empfohlen und führt wahrscheinlich nur zu Desillusionierung bei den Entwicklern.

Dies ist jedoch erst dann von Bedeutung, wenn Sie sehen, was sie mit diesem Text während des Überprüfungszeitraums tun. Überreagieren Sie also nicht zu schnell - am Ende des Tunnels kann es immer noch zu Vernunft kommen.


Angesichts meiner aktuellen Arbeitsumgebung wäre ich sehr misstrauisch, wie sie diesen Wortlaut anwenden würden.
Phil.Wheeler

2

"Fehlerfrei" wie in "perfekt?" Wie in "geschrieben von Gott und den Engeln, nicht von Menschen?" (Wir sprechen hier von Programmlogik- und möglicherweise Hardwarelogikfehlern)

Ich kann nicht einmal über eine einzelne Codezeile ehrlich sagen, dass sie fehlerfrei ist. Das liegt daran, dass wir Menschen keine negativen Hypothesen beweisen können!

Das Beste, was ich sagen kann, ist, dass die Wahrscheinlichkeit eines Fehlers eine Zahl zwischen 0 und 1 ist. Ich erreiche diese Zahl durch gut oder schlecht definierte und gut oder schlecht verstandene Prinzipien für Softwareentwicklung und -tests. durch eine Zählung der fraglichen Quellensoftwarezeilen; durch das Verständnis, wie gut oder schlecht ich Kandidat, armer Köter, diese Prinzipien bei der Erstellung dieser Codezeilen anwende; und mehr.

Und ich kann dieses Verständnis nur als Wahrscheinlichkeit ausdrücken . Der Begriff "logikfehlerfrei" bedeutet also so gut wie nichts.

Wenn ich eine Anzeige für einen Softwareentwickler sehen würde, der "fehlerfreien" Code erstellt, würde ich ihn entweder sofort anwenden oder sofort ausführen: Das Unternehmen hat nicht viel darüber nachgedacht, wie es seine Software entwickelt, testet und liefert . Es wird also entweder eine großartige Gelegenheit oder ein endloser Albtraum sein.

Von jeder Software kann und muss ich jedoch leicht sagen, dass ich Code erwarte, der keine Fehler enthält, die außerhalb dieses blöden, trüben, logischen Materials liegen: Code, der ohne Fehler oder Warnungen kompiliert und verknüpft wird; das ist "gültiges HTML" oder "gültiges CSS"; JavaScript (sagen wir), das keine unerklärlichen Fehlermeldungen oder Browserfehler generiert. Diesen Teil kann ich einfach messen und in einem Diagramm in Schwarzweiß markieren.

Dieser Teil ist kinderleicht. Jeder kann tun , dass .

Hey, viel Glück bei deiner Suche :-)


1

Bin ich dumm oder bedeutet "Fehler" nicht "schwerwiegende Compiler-Nachricht in Höhe von nicht kompilierbarem Code"?

Nach dieser Definition ist es eine sehr vernünftige Anforderung ...


1
Wahr. Ein falsch ausgerichteter Text in einer Seitenfußzeile kann ein Fehler sein, gehört jedoch sicherlich nicht zur selben Fehlerklasse wie etwas, das verhindert, dass eine Seite nicht geladen werden kann, und gibt Laufzeitfehler an den Benutzer zurück.
FrustratedWithFormsDesigner

In der Webentwicklung kann "Fehler" viele Dinge bedeuten. Das Anzeigen der falschen Preise für alle Ihre Produkte kann als schwerwiegender Fehler angesehen werden, verhindert jedoch nicht unbedingt die Ausführung von Daten und meldet möglicherweise keine Probleme in den Serverprotokollen.
Simon B

In den vier Jahren seit dem Schreiben dieses Kommentars habe ich verdammt viel mehr Webentwicklung betrieben und bin völlig einverstanden - ungewöhnlich werde ich jedoch zu meiner Antwort von vor 4 Jahren stehen und sagen, dass der Punkt, den ich versucht habe make ist , dass die Definition von „Fehlern“ ist willkürlich und für (sehr) wählen Definitionen es ist eine vernünftige Forderung.
Chris Browne
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.