Ich mache 4-5x mehr Story-Punkte als der Durchschnitt, aber produziere Fehler mit der halben Rate. Die Grafiken sagen, es sind 2x mehr Fehler, wie soll man damit umgehen?

43

Es ist daher allgemein anerkannt, dass erstklassige Programmierer einen um eine Größenordnung höheren / besseren Code produzieren können als ihre durchschnittlicheren Kollegen.

Es ist auch allgemein anerkannt, dass die Fehlerrate im Code für Programmierer relativ konstant ist .

Stattdessen wird es häufig von den Prozessen beeinflusst, die beim Schreiben des Codes und nach dem Schreiben des Codes verwendet werden . (So ​​wie ich es verstehe) Menschen neigen dazu, Fehler mit einer ziemlich konstanten Rate zu machen - bessere Programmierer bemerken einfach mehr von ihnen und können sie schneller beheben.

  • Beachten Sie, dass beide obigen Aussagen von Steve McConnells Code Complete stammen - es handelt sich also nicht um unterschiedliche Perspektiven.

Daher habe ich vor kurzem damit begonnen, dies in meinem Code zu sehen. Ich kann ungefähr das 4-5-fache der Code-Menge meiner Kollegen (gemessen an Story-Punkten, die vom Team geschätzt werden) mit höherer Qualität (basierend auf Leistungsmetriken und der Anzahl der nach dem Check-in vorgenommenen Änderungen) herausarbeiten. Aber ich mache immer noch Fehler. Zwischen besseren Komponententests, einem besseren Verständnis für die Funktionsweise des Codes und einem besseren Auge für Probleme bei der Durchführung von Codeüberprüfungen stelle ich nicht das 4-5-fache der Anzahl von Fehlern fest.

Aber ich produziere immer noch ungefähr doppelt so viele Fehler, die von QA gefunden wurden, wie andere Entwickler in meinem Team. Wie Sie sich vorstellen können, verursacht dies einige Probleme bei nicht-technischen Leuten, die metrische Messungen durchführen (siehe: mein Chef).

Ich habe versucht, darauf hinzuweisen, dass ich Bugs mit der halben Rate meiner Kollegen produziere (und doppelt so viele behebe), aber es ist schwer zu verkaufen, wenn es Grafiken gibt, die besagen, dass ich doppelt so viele Bugs produziere.

Wie kann man mit der Tatsache umgehen, dass eine erhöhte Produktivität zu einer erhöhten Anzahl von Fehlern führt?

Telastyn
quelle
27
Oder verlangsamen Sie einfach, damit Sie es richtig machen können.
Brandon
29
Aus praktischer Sicht klingt es so, als würden Sie mehr für die Vermeidung von Fehlern bezahlt als für die Codegenerierung. Verbringen Sie also 1/4 Ihres Tages damit, Code für Ihr Unternehmen zu schreiben, und den Rest des Tages damit, Code für Ihre eigenen Nebenprojekte zu schreiben. Nach dem von ihm festgelegten Kriterium sollte Ihr Chef Sie lieben.
Rob
14
Ich verstehe nicht ganz, warum unsere Community "Geschwindigkeit" mehr als Korrektheit zu feiern scheint. Und ich schreibe "Geschwindigkeit" in Anführungszeichen, denn wenn Sie zurückgehen müssen, um Dinge zu reparieren, dann ist es vielleicht nicht wirklich "Geschwindigkeit". Am Ende werden Sie für die Lieferung von funktionierender Software bezahlt. Wenn Sie Code schneller als gewöhnlich schreiben und Fehler produzieren, indem Sie Tests überspringen oder die Anforderungen nicht richtig verstehen, nehmen Sie sich etwas Zeit, die Sie "übrig" haben, und verwenden Sie ihn, um Ihr Test- / Anforderungsverständnis zu verbessern (was Sie beispielsweise tun) TDD?). Wie Onkel Bob sagt: "Wenn Sie schnell gehen wollen, gehen Sie gut".
MichelHenrich
9
Die Art und Weise, wie Sie dies beheben, besteht darin, die Metriken zu korrigieren.
Robert Harvey
24
@MichelHenrich: Wenn er Bugs mit der halben Rate seiner Kollegen produziert, ist Geschwindigkeit nicht das Problem. Management ist das Problem. Sie lesen diese verrückten Kennzahlen genauso wie seine Chefs.
Robert Harvey

Antworten:

41

Ich denke, Sie mischen Ihre Bedenken. Und es gibt nichts auf Ihrer Seite, was Sie ändern müssen.

Produktivität ist ein Hinweis darauf, wie schnell ein Projekt abgeschlossen sein wird. Projektmanager und alle anderen möchten wissen, wann das Projekt ausgeführt wird. Höhere oder schnellere Produktivität bedeutet, dass das Projekt schneller ausgeführt werden kann.

Die Fehlerrate ist nicht an die Produktivität gebunden, sondern an die Größe des Projekts. Beispielsweise können NFehler pro YCodezeile auftreten. Es gibt nichts in dieser Metrik, was besagt (oder interessiert!), Wie schnell diese Codezeilen geschrieben werden.

Wenn Sie also eine höhere Produktivität haben, werden Sie feststellen, dass die Bugs schneller geschrieben werden. Aber Sie würden sowieso diese Anzahl von Fehlern haben, da es an die Größe des Projekts gebunden ist.

Wenn überhaupt, bedeutet eine höhere Produktivität, dass Sie am Ende des Projekts mehr Zeit haben, um diese Fehler aufzuspüren, oder der Entwickler kann die von ihm verursachten Fehler schneller finden. 1


Um die persönlicheren Aspekte Ihrer Frage anzusprechen.

Wenn Ihr Chef genau auf die Anzahl der von Ihnen produzierten Bugs und nicht auf die Anzahl der von Ihnen produzierten Bugs achtet, ist eine Schulungssitzung angebracht. Die Anzahl der erstellten Fehler ist ohne eine Unterstützungsrate bedeutungslos.

Um dieses Beispiel auf den Punkt zu bringen, sagen Sie Ihrem Chef, dass ich Ihr Gehalt verdoppeln möchte. Warum? Ich habe absolut keine Fehler in Ihrem Projekt verursacht und bin daher ein viel überlegener Programmierer als Sie. Was? Er wird ein Problem haben, dass ich keine einzige Codezeile erstellt habe, von der Ihr Projekt profitiert? Ah. Jetzt haben wir Verständnis dafür, warum Geschwindigkeit wichtig ist.

Es hört sich so an, als ob Ihr Team die Metriken hat, um Fehler pro Story-Punkt zu bewerten. Wenn nichts anderes, ist es besser, als an der rohen Anzahl der erzeugten Fehler gemessen zu werden. Ihre besten Entwickler sollten mehr Bugs erstellen, weil sie mehr Code schreiben. Lassen Sie Ihren Chef diese Grafik oder zumindest eine andere Reihe dahinter werfen, die zeigt, wie viele Story Points (oder welchen geschäftlichen Wert Sie messen) Sie neben der Anzahl der Bugs haben. Diese Grafik wird eine genauere Geschichte erzählen.


1 Dieser Kommentar hat weitaus mehr Aufmerksamkeit auf sich gezogen, als er beabsichtigt war. Seien wir also etwas umständlich (Überraschung, ich weiß) und konzentrieren uns wieder auf diese Frage.

Die Wurzel dieser Frage liegt darin, dass ein Manager die falschen Dinge ansieht. Sie betrachten die Gesamtzahl der Fehler, wenn sie die Generierungsrate im Verhältnis zur Anzahl der erledigten Aufgaben betrachten sollten. Lassen Sie uns nicht über das Messen gegen "Codezeilen" oder Story-Punkte oder Komplexität oder was auch immer besessen sein. Das ist nicht die Frage, und diese Sorgen lenken uns von der wichtigeren Frage ab.

Wie in den Links des OP dargelegt, können Sie eine bestimmte Anzahl von Fehlern in einem Projekt allein anhand der Größe des Projekts vorhersagen. Ja, Sie können diese Anzahl von Fehlern durch verschiedene Entwicklungs- und Testtechniken reduzieren. Auch das war nicht der Punkt dieser Frage. Um diese Frage zu verstehen, müssen wir akzeptieren, dass für ein Projekt bestimmter Größe und eine bestimmte Entwicklungsmethode eine bestimmte Anzahl von Fehlern angezeigt wird, sobald die Entwicklung "abgeschlossen" ist.

Kommen wir also endlich zu diesem Kommentar zurück, den einige völlig missverstanden haben. Wenn Sie zwei Entwicklern Aufgaben mit vergleichbarer Größe zuweisen, wird der Entwickler mit einer höheren Produktivitätsrate seine Aufgabe vor der anderen erledigen. Dem produktiveren Entwickler steht daher am Ende des Entwicklungsfensters mehr Zeit zur Verfügung. Diese "zusätzliche Zeit" (im Vergleich zu anderen Entwicklern) kann für andere Aufgaben verwendet werden, z. B. für die Bearbeitung der Fehler, die in einem Standardentwicklungsprozess auftreten.

Wir müssen das OP beim Wort nehmen, dass sie produktiver sind als andere Entwickler. Nichts innerhalb dieser Behauptungen impliziert, dass das OP oder andere produktivere Entwickler in ihrer Arbeit schlampig sind. Wenn Sie darauf hinweisen, dass es weniger Fehler geben würde, wenn Sie mehr Zeit für das Feature aufwenden, oder wenn Sie vorschlagen, dass das Debuggen nicht Teil dieser Entwicklungszeit ist, werden die gestellten Fragen übersehen. Einige Entwickler sind schneller als andere und produzieren vergleichbare oder qualitativ bessere Arbeiten. Sehen Sie sich auch hier die Links an, die das OP in seiner Frage aufzeigt.


quelle
43
"Das Messen des Programmierfortschritts anhand von Codezeilen ist wie das Messen des Flugzeugbaufortschritts anhand des Gewichts." -Bill Gates
Neil
40
Großartige Programme können tatsächlich mehr Fehler als der durchschnittliche Programmierer verursachen, da großartige Programme dazu neigen, an schwierigeren Problemen zu arbeiten.
15.
4
Bugs / K Lines oder Bugs / Storypoint wären fair. Ich würde so schnell wie möglich rennen, wenn der Chef Bugs / Stunde als Rate verwenden möchte.
Bart van Ingen Schenau
4
"Ihre besten Entwickler sollten mehr Bugs erstellen, weil sie mehr Code schreiben." nein, sie sollten entweder Fehler verhindern oder mehr Funktionen fertigstellen. Oft bedeutet dies, dass sie weniger Code schreiben oder sogar Code-Schwaden entfernen. (Sie wissen das wahrscheinlich, haben es aber nicht so geschrieben.) In einigen Branchen, in denen ich gearbeitet habe (z. B. Luft- und Raumfahrt und Nuklearindustrie), zählt nur der Code, der nachweislich keine Fehler aufweist. Alles andere ist Lärm.
Pete Kirkham
4
"Wenn überhaupt, bedeutet eine höhere Produktivität, dass Sie am Ende des Projekts mehr Zeit haben, um diese Fehler aufzuspüren, oder der Entwickler kann die von ihm verursachten Fehler schneller finden." - Ich halte das für falsch und bedürfte einer genaueren Analyse. Sagen wir es so: Wenn er mehr Zeit für jedes Feature aufwenden würde, hätte er weniger Zeit, um Bugs zu zerstören. Es gäbe aber auch weniger Fehler, die man ausmerzen könnte.
Occulus
21

Nehmen Sie sich etwas Zeit für das Reinigen, Polieren und Testen Ihres Codes. Es wird immer noch Fehler geben, aber es wird weniger geben. Das braucht Zeit. Ihre Code-Ausgaberate wird sinken, aber Ihre fehlerfreie Code-Ausgabe wird zunehmen, was zu einer besseren Produktivität führt. Weil Käfer teuer sind.

Können Sie Ihren Code in einem Zweig oder in einer Testumgebung belassen, bis Sie ihn herumwerfen und mehr Fehler finden? Fehler in einem Zweig verursachen im Allgemeinen weniger Wellen als Fehler im Produktionscode.

Aber ich grabe nicht genau Ihre Behauptungen, die in Ihre Frage führen. Und vielleicht ist Ihr Chef auch nicht.

Ich denke nicht, dass jeder Codierer die gleiche Fehlerrate produziert. Ihr zweiter Link ist eigentlich völlig unangebracht, da er verschiedene Sprachen vergleicht, nicht verschiedene Programmierkenntnisse. Code complete erwähnt einige Messungen mit großen Stichproben, die sich eher auf den Prozess als auf die Fähigkeiten der Codierer beziehen. Und wenn sie behaupten, dass erstklassige Codierer mehr / besseren Code produzieren, bedeutet dies teilweise, dass sie weniger Fehler aufweisen. Kommt auf die Anwendung an. Also, ja, ich denke es ist eine Frage unterschiedlicher Perspektiven.

Am Ende aber, wenn der Chef saubereren Code will, gib ihm saubereren Code.

Philip
quelle
4
+1. Ich weiß nicht, warum die andere Antwort so viele positive Stimmen hat. Es hört sich so an, als hätten Sie Ihrem Chef bereits gute Argumente gegeben, und er hört nicht zu. Verbringen Sie also mehr Zeit mit Testen und weniger Zeit mit dem "Freigeben" von Codezeilen. Wenn das nicht in Ordnung ist, wechseln Sie den Job.
Durron597
21

Ich werde auf die Beine gehen und der Anwalt des Teufels sein. Das heißt nicht, dass ich nicht mit deiner Notlage sympathisiere, aber meine Sympathie wird dir nicht helfen. Gestatten Sie mir also, Philipps Perspektive zu erweitern :

Ihr Chef kümmert sich um die Qualität des Produkts, auch weil sein Name und sein Ruf damit verbunden sind. Ein Teil der Qualität ist die wahrgenommene Menge an Fehlern . Wenn Sie einen fantastischen Bohrer verkaufen, der viermal schneller als alle anderen Bohrer der Konkurrenz bohrt, aber auch doppelt so oft ausfällt, haben Sie einen schlechten Ruf. Auch wenn die Leistung der Übung möglicherweise besser ist, gewöhnen sich die Leute an die Geschwindigkeit, aber sie werden sich an die Pannen erinnern.

Im Nachhinein sind die meisten Fehler offensichtlich vermeidbar. Wenn Sie nur etwas vorsichtiger wären, würde Ihr Chef das Gefühl haben, Sie könnten diese Probleme und alle notwendigen Aufräumarbeiten vermeiden. Aus seiner Sicht ist das eine triviale, sinnliche Frage, und jeder Streit, den Sie dagegen führen, wird nicht funktionieren und Sie schlecht aussehen lassen.

Er kann Ihre überlegene Produktivität nicht messen. Sie behaupten eine höhere Produktivität basierend auf einer überprüfbaren Metrik. Wie stehen Ihre Kollegen dazu? Stimmen sie vielleicht widerwillig zu, dass Sie ein produktiverer Programmierer sind, oder sind Sie Ihrer Meinung nach allein? Sie werden einen stärkeren Punkt betonen, wenn Sie andere Personen haben, die Ihre Behauptungen stützen.

Das ist für die Perspektive. Wie können Sie diese frustrierende Situation, in der Sie sich befinden, beheben?

Mach ein bisschen langsamer. Erwähnen Sie ausdrücklich, wer Aufgaben verteilt, die Sie versuchen werden, die Fehlerrate (*) zu senken, damit sie nicht von Ihrer geringeren Aufnahme überrascht werden. Wenn etwas langsamer wird, verringert sich die Anzahl der Fehler, die Ihnen aufgrund des Mangels an Versorgung zugewiesen wurden.

(*) Es gibt einen Unterschied zwischen, auf der einen Seite, die Erkenntnis , dass es sind Fehler zu Ihrem Namen und dass Sie versuchen , die Menge und zu verringern, auf der anderen Seite zugeben, dass Sie zu viele Fehler zu Ihrem Namen und sollten Handeln Sie.

Versuchen Sie nicht, Ihren Chef zu überzeugen, weil es nicht funktioniert. Auch das bedeutet nicht, dass Sie Ihren Standpunkt einräumen müssen . Sie können einen Kontrapunkt vorbringen und Ihre Meinung vertreten, ohne seine Bedenken zu verneinen. Denn wenn Sie den Punkt argumentieren und Ihre überlegene Produktivität nicht zufriedenstellend beweisen können (und selbst wenn Sie dies können), riskieren Sie, Ihre Kollegen zu beleidigen oder sie als abweisend zu betrachten. Du willst nicht der Typ sein .

JvR
quelle
4
Meine Lieblingsantwort und auch die, die einem Punkt am nächsten kommt, den ich hinzufügen möchte: Was ist der Wert einer abgeschlossenen Anzahl von Story-Punkten und was kostet ein Fehler für das Unternehmen? Das OP kann mit diesen Dingen, die durch die Prioritäten der Chefs gewichtet werden, feststellen, dass es tatsächlich produktiver ist, nur doppelt so viel Code wie andere Entwickler zu erstellen, aber mit viel weniger Fehlern.
Neil Slater
2
Ihr Standpunkt zum Drill hängt von vielen Dingen ab. Insbesondere sein Arbeitszyklus. Wenn ein Bohrer rund um die Uhr und viermal so schnell arbeitet und doppelt so häufig ausfällt, sollten Sie die Produktivität des Bohrers SEHR MINDESTENS berücksichtigen. Denn wenn es weniger als das Doppelte eines normalen Bohrers kostet und Sie es einsetzen können, ist es ein besserer Wert. Sie wissen, Wirtschaft. Sie sagen ihm, er solle den Wert seiner Arbeit im Vergleich zu den Kosten berücksichtigen. Sein Nutzen-Kosten-Verhältnis ist doppelt so gut wie das seiner Kollegen.
Nomen
1
@nomen Oh, aber ich stimme zu: Leute sollten das unbedingt berücksichtigen. Aber tun sie das?
JvR
20

Angenommen, Sie würden in 20% der Zeit die gleiche "Menge" an Code produzieren wie Ihre Kollegen, dann könnten Sie 4-mal so viel für das eigentliche Debuggen und Vervollkommnen des Codes ausgeben, was Ihre Fehlerrate noch weiter verringern würde. Dann könnten Sie sich einen guten Programmierer nennen.

Die größte Frage ist, warum Sie 5-mal so viel programmieren wie die anderen, anstatt auf Qualität zu setzen. Ist das etwas, was dein Ego dir diktiert oder zwingt dich dein Boss?

Außerdem müssen Sie die Kosten für die Behebung eines Fehlers berücksichtigen. Wenn Sie es frühzeitig finden, sind Sie möglicherweise immer noch "in" dem Code, um es schnell zu beheben. Erscheint es erst nach einem weiteren Monat der Entwicklung, kann es schwierig sein, Sie zu zwingen, große Teile des bereits programmierten Codes zu ändern.

Sie scheinen die Fähigkeiten zu haben, um Code zu produzieren, und Sie könnten es großartig machen, wenn Sie sich auf Qualität statt auf Geschwindigkeit konzentrieren. Versuchen Sie es eine Weile, ich schätze, es wird Ihnen gefallen.

Das nächste Problem ist dann, die Bestätigung (Sprechen Sie Geld) für Ihre bessere Leistung zu bekommen. Sprechen Sie mit Ihrem Chef und fragen Sie ihn, wie er vorgehen soll, es ist schließlich seine Firma und sein Geld, und wenn er möchte, dass Sie weniger Fehler produzieren, sollte er auch entscheiden, auf welche Weise dies geschieht.

awsm
quelle
11
OP liefert 500% der Story Points der anderen Teammitglieder mit 60% weniger Fehlern pro Story Point, und Sie möchten seine Arbeitsweise ändern?
Justin
6
" Die größte Frage ist, warum Sie 5-mal so viel programmieren wie die anderen, anstatt [...] auf Qualität zu setzen, anstatt auf Geschwindigkeit " - Sie haben meinen Tag gemacht, Mann. Wer auch immer dem zustimmte: Bitte machen Sie Ihre grundlegenden Mathe-Hausaufgaben. Um es klar zu sagen: Ich würde das OP sofort einstellen und mich weigern, Sie einzustellen.
JensG
1
Die Mathematik könnte falsch sein, aber ich denke, der Punkt ist gültig. Ich würde lieber jemanden einstellen, der eine höhere Qualität anstrebt, um in meinem derzeitigen Unternehmen zu arbeiten. Die Anforderungen variieren jedoch, insbesondere nach Branche und Unternehmensgröße.
Michael Durrant
1
Ich würde lieber jemanden einstellen, der tut, was sein Chef von ihm verlangt, anstatt sich im Internet darüber zu beschweren. Manchmal weiß es der Chef am besten.
Dawood sagt, Monica
8

Entwickler können brillant und sogar genial sein und die Fähigkeit besitzen, Solos zu verstehen und zu programmieren, ohne GUTE Entwickler zu sein. Ein guter Entwickler schafft ein qualitativ hochwertiges Stück Arbeit und verbessert das gesamte Projekt.

Ich sage nicht, dass Sie das sind, aber einer der frustrierendsten Programmierer, mit denen ich je zusammengearbeitet habe, hat mehr Code geschrieben als jeder andere im Team, und wir hatten gute Leute im Team. Wir haben Commits mit einer Ranking-Software nachverfolgt, sodass es für einige Leute fast ein Wettbewerb war. Er hat eine Menge Code ausgegeben, ZERO-Dokumentation und undurchdringliche Wälder hinterlassen und es mir tatsächlich schwer gemacht, einen Teil meines eigenen Codes zu verstehen (ich kann das alleine tun, vielen Dank!). Schließlich hätte er das Projekt beinahe entgleist, weil er zu einer One-Man-Show wurde. Die Leute konnten ihm nicht folgen. Wir waren als Team nicht synchron. Wir haben einige seiner Features Jahre später neu geschrieben, um die Wartbarkeit wiederherzustellen.

Das, was ich von ihm wollte, war, langsamer zu werden und mehr Zeit zu verbringen: 1) Die Qualität der Codebasis zu verbessern 2) Mit dem Team zu kommunizieren 3) An Dingen zu arbeiten, die anderen geholfen haben, und ihm dabei zu helfen, Features / Storys zu beenden 4) Fehler zu beheben Bugs

Ich bin nicht damit einverstanden, die Produktivität anhand von Codezeilen zu messen, aber dies ist eine Schlüsselmetrik. Enthält Ihr Codezähler Kommentare? In diesem Fall gibt es eine einfache Möglichkeit, die Zeilenausgabe beizubehalten und gleichzeitig die "Fehlerquote" zu verringern. Erhöhen Sie einfach die Qualität und Quantität der von Ihnen geschriebenen Kommentare. Kommentare weisen selten Fehler auf (obwohl dies möglich ist), und wir haben im Allgemeinen nicht genügend Qualitätskommentare. Ich befürworte keine Code-Inflation, aber das Kommentieren ist wie ein Mini-Code-Review. Es zwingt Sie zum Nachdenken, Umgestalten und Verbessern.

Codenheim
quelle
1
Ein guter Punkt. Ich bin nicht einverstanden, Kommentare hinzuzufügen (da klarerer, besser lesbarer Code besser ist), und wir messen anhand des Handlungspunkts, der vollständig ist, und nicht anhand von Codezeilen. Ich habe das Gefühl, dass ich damit einen guten Job mache (Code-Reviews helfen den Leuten, mir die Dinge klar zu machen), aber +1, weil es sicherlich nicht jeder tut.
Telastyn
1
Ich möchte keine Kommentare zu Flusen / Boilerplates hinzufügen. Ich habe nur angenommen, dass Sie wie die meisten von uns sind und nicht genug kommentieren. Ja,
meiden Sie
4
Nach meiner Erfahrung enthalten Kommentare häufig Fehler.
Dawood sagt, Monica
Nicht die funktionale, messbare Art ...
Codenheim
6
@ DavidWallace, in meiner Erfahrung enthält Code häufig Fehler. Es bedeutet nicht, dass Sie aufhören, es zu schreiben.
Charles E. Grant
4

Der Versuch, das Management aufzuklären, ist kein Anfänger. Es gibt ein altes Klischee: "Wirst du mir oder deinen Lügenaugen glauben?" Was Ihre Chefs betrifft, sind die Fehlerzahlen. Kein Ausmaß an Rationalisierung wird ihnen sagen, dass es akzeptabel ist. Es ist mehr als doppelt so riskant. Darüber hinaus sind Sie nicht der einzige, der von Ihrer Fehleranzahl betroffen ist. QA hat die doppelte Arbeit, um Ihre Fehler zu identifizieren. Das Management möchte, dass Sie weniger daraus machen.

Die beste Lösung ist, die Anzahl der von Ihnen verursachten Fehler zu verringern . Das Management wird nicht nur glücklicher sein, sondern auch Sie. Willst du nicht? Weil ich ziemlich sicher , dass so viel wie ich Ihnen viel Spaß beim Prahlen Sie Ihre Mitarbeiter um einen Faktor von vier übertreffen, dann würden Sie lieben zu sagen , Sie tun so dass es die gleiche Anzahl von, oder sogar weniger, Wanzen , als sie tun.

Wie Sie sagten, "... wird die Fehlerquote im Code ... in der Regel von den Prozessen beeinflusst, die beim Schreiben des Codes und nach dem Schreiben des Codes verwendet werden." Wenn Sie die Rate ändern möchten, mit der Sie Fehler produzieren, müssen Sie die Prozesse ändern, die Sie zum Schreiben von Code verwenden.

Programmierer verwenden Produktionsmethoden, um Code zu erzeugen, so wie eine Fertigungsstraße Methoden verwendet, um ein in Serie hergestelltes Objekt zu erzeugen. Okay, die Praktiken der Softwareindustrie ähneln eher dem Schnickschnack von Zweigen, die im Wald gefunden wurden. Da wir jedoch Maschinen herstellen, sollten wir die gleiche Sorgfalt und Disziplin anwenden, die auch für die Hochgeschwindigkeitsmaschinen der Massenproduktion angewendet wird.

Dies schließt die gleichen Techniken ein, die in der Massenproduktion zur Reduzierung der Fehlerrate verwendet werden: Ursachenanalyse, um festzustellen, warum Fehler gemacht werden, und um den Prozess so zu ändern, dass dies nicht der Fall ist. Oder zumindest, dass Sie fangen, bevor QA es tut.

  1. Stellen Sie eine Liste Ihrer Bugs zusammen. Sie haben wahrscheinlich schon einen Dank an die QA-Leute. Möglicherweise auch kategorisiert. Art des Fehlers, Schweregrad, Zeitpunkt, an dem der Fehler in den Code eingefügt wurde usw.

  2. Wählen Sie die größte Kategorie von Fehlern. Da Ihr Volumen so hoch ist, sollten Sie zuerst auf diese Kategorie abzielen. Andere Kategorien sind die am einfachsten zu findenden und die am einfachsten zu erstellenden.

  3. Wenn Sie wissen, wo diese Fehler in den Code eingefügt werden, sollten Sie in dieser (und einer früheren) Phase Änderungen vornehmen, die das Auftreten dieser Fehler verhindern, und Möglichkeiten finden, wie Sie sie in dieser Phase leichter erkennen können.

  4. Achten Sie darauf, nicht mit der Programmierung zusammenhängende Nebeneffekte zu berücksichtigen, da diese die Qualität Ihrer Arbeit beeinträchtigen können. Hintergrundmusik, Unterbrechungen, Essenszeiten, pausenloses Arbeiten, Hunger etc.

Was Sie finden, kann dazu führen, dass Sie langsamer werden. Auf der anderen Seite kann es Ihnen helfen, noch schneller zu produzieren, da Sie weniger Dinge überarbeiten müssen, die Sie bereits hinter sich gebracht haben. So wie es ist, ist viermal so viel Code nicht annähernd eine Größenordnung besser als Ihre Mitarbeiter. Daher ist eine Änderung Ihres Prozesses auf jeden Fall der richtige Weg.

Huperniketes
quelle
3

Ändern Sie Ihr Ziel, indem Sie nicht mehr den meisten Code produzieren, sondern dem Unternehmen dabei helfen, die meisten Fortschritte zu erzielen.

Da anscheinend viele Kollegen und zusätzliche Zeit zur Verfügung stehen, besteht der größte Effekt auf eine schnellere Bereitstellung von Funktionen und Fehlerbehebungen darin, Ihren Kollegen zu helfen.

Helfen Sie Ihren Kollegen durch

  • Verwenden von Codeüberprüfungen zur Verbesserung der Codequalität und -erziehung.
  • Prozessautomatisierung schaffen, um ihre Arbeit zu beschleunigen und ihr Leben zu erleichtern.
  • Mit ihnen bessere Tests schreiben
  • Angreifen von technischem Code zur Verbesserung der Codebasis
  • Der Ansprechpartner zu sein, der immer zur Verfügung steht, um anderen zu helfen.
  • Schreiben / Verbessern von Tools zur Steigerung der Entwicklerproduktivität
  • Setzen Sie sich mit dem Management für bessere Werkzeuge / Geräte / Arbeitsbedingungen für Ihre Mitarbeiter ein, wenn Sie mehr Einfluss haben.
  • Vorbereitung und Leitung von Schulungssitzungen zum Schreiben von besserem Code.
  • Demut üben
Michael Durrant
quelle
1

Wie kann man mit der Tatsache umgehen, dass eine erhöhte Produktivität zu einer erhöhten Anzahl von Fehlern führt?

Ihr Chef ist die einzige Person, die dies in Ihrem Fall beantworten kann. Sprechen Sie mit ihm, zeigen Sie Ihr besseres Verhältnis auf und lassen Sie ihn entscheiden. Wenn seine Entscheidung keinen Sinn ergibt, ist es Zeit, nach einem Unternehmen mit Ihrer Denkweise zu suchen.

Als Fachmann sollten Sie in der Lage sein, mit den gegebenen Kundenbedingungen zu arbeiten. Stellen Sie nur sicher, dass sie die Konsequenzen verstehen. Ein nettes Fehler- / Story-Diagramm kann Ihrem Chef helfen, zu verstehen, wie viel Ihre Produktivität sinkt, wenn Sie sich die Zeit nehmen, weniger Fehler zu produzieren.

Sie müssen auch diese Punkte berücksichtigen:

  • Komplexität von Geschichten, zum Beispiel einfache Getter / Setter-Wrapper gegenüber statistischen Berechnungen oder Echtzeitprogrammierung oder sogar Echtzeitstatistik ...
  • Schwere von Fehlern, kleine Tippfehler in Textfeldern oder falsche Berechnungsergebnisse, Programmabstürze
  • Die Behebung der Fehler ist kostenpflichtig, sowohl wenn Sie es jetzt, später oder wenn jemand anderes Ihren Code verstehen muss, weil Sie gegangen sind
Mardersturm
quelle
0

Die Situation ist, dass Sie viermal so schnell arbeiten wie der durchschnittliche Programmierer, aber in einer bestimmten Zeit doppelt so viele Fehler machen. Im Verhältnis zu der Menge an Arbeit, die Sie leisten, machen Sie tatsächlich HALB so viele Fehler wie "durchschnittlich".

Sie können versuchen, auf Ihr geringes Fehler-zu-Arbeits-Verhältnis oder sogar auf Fehler beim fertigen Produkt hinzuweisen (die Sie in einem Viertel der normalen Zeit erledigen können). Die meisten Chefs werden das akzeptieren.

Es gibt ein paar Chefs, die das nicht tun, weil sie mit einer gewissen "Toleranz" von Fehlern pro Zeit arbeiten. Dann können Sie Ihr Arbeitstempo verlangsamen, indem Sie in einer bestimmten Zeit ZWEIMAL so viel Arbeit erledigen wie im Durchschnitt und dieselben (oder weniger) Fehler machen, weil Sie mehr Zeit haben, Ihre Arbeit zu überprüfen.

Tom Au
quelle
0

Wenn Ihr Chef möchte, dass Sie die Qualität Ihrer Arbeit verbessern, dann verbessern Sie die Qualität Ihrer Arbeit.

Sie sollten auf null Fehler abzielen und nicht darauf, nur doppelt so viele zu produzieren wie der nächstbeste Programmierer.

Laut Dawood soll Monica wieder eingesetzt werden
quelle
6
Zero Bugs ist ein weitgehend unerreichbares Ziel , das oft nicht wirtschaftlich ist.
Telastyn
7
Das ist keine Entschuldigung dafür, Ihre Fehlerquote nicht zu senken. Wenn Ihr Chef möchte, dass Sie besseren Code erstellen, ist es Zeit, besseren Code zu erstellen, und keine Ausreden zu treffen.
Dawood sagt, Monica
4
Ich habe nur gesagt, Sie sollten auf null Fehler abzielen , nicht, dass Sie es erreichen müssen. Denken Sie an Bogenschießen. Ich bin nicht gut im Bogenschießen - ich habe noch nie die "10" in der Mitte des Ziels getroffen. Soll ich auf den "7" -Ring zielen, weil "10" zu schwierig wäre?
Dawood sagt, Monica
6
Ja, aber Ihr Chef sagt, dass Ihre Arbeit NICHT "gut genug" ist. Mit anderen Worten, Sie sollten es besser machen. Sie haben keinen guten Grund angegeben, warum Sie es nicht besser machen können. Diese ganze Diskussion klingt für mich wie jemand, der versucht, Ausreden für die Erstellung von fehlerhaftem Code zu finden. "Ich bin in einem Team von sehr langsamen Entwicklern und muss daher doppelt so viele Fehler machen wie alle anderen". Bitte!
Dawood sagt, Monica
3
In jedem Release-Zyklus produzieren Sie doppelt so viele Bugs wie Ihre Kollegen. Bugs sind teuer zu finden und teuer zu beheben. Also muss Ihr Chef die Ressourcen einplanen, um Ihre Fehler zu beheben. und es ist doppelt so viel für deine Bugs wie für die Bugs des nächsten. Daher möchte Ihr Chef, dass Sie weniger Bugs produzieren, unabhängig davon, was der Rest Ihres Teams tut. Vielleicht weiß er, dass Sie mehr Erfahrung als der Rest des Teams haben und daher in der Lage sein sollten, weniger Bugs zu produzieren. Auf jeden Fall verstehe ich nicht, warum Sie sich über einen Chef beschweren, der möchte, dass Sie weniger Bugs produzieren.
Dawood sagt, Monica
0

Sie sollten Ihrem Chef mitteilen, dass die von ihm verwendeten Messdaten fehlerhaft sind. Wenn Sie sich die Umsätze der Wachen in der NBA ansehen, werden Sie feststellen, dass diese tendenziell höhere Zahlen als die Vorwärtsumsätze aufweisen. Aber das liegt daran, dass sie mehr mit dem Ball umgehen. Wenn eine nicht startende Wache 1/5 so viel spielt wie eine startende Wache und den Ball im Durchschnitt 3-mal umdreht .vs. eine Startwache, die den Ball 7-mal pro Spiel umdreht - auf den ersten Blick könnte es so aussehen, als wäre die Startwache schlechter. Wenn Sie jedoch die Anzahl der Umsätze durch die Anzahl der gespielten Minuten dividieren, hat der Startgarde eindeutig viel bessere Zahlen, basierend auf den gespielten Minuten.

Ebenso haben Sie viel bessere Zahlen, wenn die Anzahl der Bugs durch die Anzahl der abgeschlossenen Story-Punkte dividiert wird. Das würde ich Ihrem Manager vorschlagen. Ändern Sie die Metrik so, dass sie die Anzahl der Fehler dividiert durch die erreichten Story-Punkte darstellt, oder fügen Sie mindestens eine neue Metrik hinzu, wenn die Gesamtzahl der Fehler pro Entwickler benötigt wird. Da einige Story Points jedoch viel schwieriger und komplexer sind als andere Story Points, kann und wird es durchaus Abweichungen geben, die auch vom Manager berücksichtigt werden müssen.

Was ich nicht denke, dass Sie tun sollten, ist zu verlangsamen.

Bob Bryan
quelle
0

Wertschöpfung messen

Argumentieren Sie, was wirklich zählt, ist der Wert, den Sie hinzufügen. Dann gehen Sie und führen Sie eine grobe (manuelle) Messung davon ein:

  • Schätzen Sie den Wert der von Ihnen produzierten Funktionalität
  • Subtrahieren Sie Ihr Gehalt
  • Subtrahieren Sie die geschätzten Kosten Ihrer Fehler (mindestens die Kosten für deren Behebung)
  • Subtrahieren Sie die geschätzten Kosten aller anderen von Ihnen produzierten technischen Schulden

Der Rest ist Ihr Mehrwert. Ebenso für alle anderen.

Diese Schätzungen sind schwierig, aber auch grobe Schätzungen können den Ausschlag geben. Der bloße Prozess der Erörterung dieser Schätzungen ist für das Team und das Projekt nützlich.

Lutz Prechelt
quelle
-1

Top-Programmierer neigen dazu, sehr regelmäßigen Code zu schreiben, der leicht zu debuggen und zu verstehen ist. Sie verwenden die verfügbaren Tools (statische Analyse, Compilerfehler, Debug-Code) mit maximaler Genauigkeit. Auch Top-Programmierer haben den Wert des Unit-Testens bereits aus eigener harter Erfahrung gelernt.

Während also die anfängliche Anzahl von Problemen pro Zeile gleich ist, werden die Probleme schneller beseitigt.

zzz777
quelle
question weist darauf hin, dass dies nicht hilft: "Ich habe versucht, darauf hinzuweisen, dass ich Bugs mit der halben Rate meiner Kollegen produziere (und doppelt so viele behebe), aber es ist schwer zu verkaufen, wenn es Grafiken gibt, die besagen, dass ich produziere doppelt so viele Bugs ... "
Mücke
Das ist relativ und eher subjektiv, nicht wahr? Ich weiß nicht, was "normaler" Code bedeutet. Ich würde argumentieren, dass Top-Programmierer versuchen, alle Bibliotheken und Sprachkonstrukte, die ihnen zur Verfügung stehen, zu ihrem maximalen Nutzen in Bezug auf Produktivität und Ausdruckskraft zu nutzen, was den Code für andere hochfunktionierende Programmierer sehr einfach verständlich machen sollte ... könnte aber in Für fortgeschrittene Programmierer, insbesondere diejenigen, die mit den fortgeschrittenen Architekturkonzepten, dem Kontrollfluss und den Datenstrukturen nicht vertraut sind, ist dies äußerst schwer zu verstehen.
Aaronaught
IMHO, Größe wird durch die lange Erfolgsgeschichte definiert und 90% der lebenden Software-Ingenieure hatten nie die Chance, großartige zu treffen. Ich habe versucht, meine Eindrücke von zwei großartigen Programmierern, mit denen ich zusammenarbeite, zusammenzufassen. "Regulärer" Code bedeutet: (a) dasselbe wird für den gesamten produzierten Code auf die gleiche Weise getan, (b) es ist leicht, eine Änderung zu interpretieren, und (c) es ist definitiv das Gegenteil von "leicht zu verstehen für andere High-End-Benutzer". funktionierende Programmierer ... ".
zzz777