Estoy obteniendo 4-5 veces más puntos de historia que el promedio, pero produzco errores a la mitad de la tasa. Los gráficos dicen que son 2 veces más errores, ¿cómo lidiar con eso?

Por lo tanto, generalmente se acepta que los programadores de nivel superior pueden producir un orden de magnitud de código más / mejor que sus pares más promedio.

También se acepta generalmente que la tasa de errores cometidos en el código es relativamente constante para los programadores.

En cambio, tiende a verse afectado por los procesos utilizados al escribir el código y después de que se escribe el código . (Según tengo entendido) Los humanos tienden a cometer errores a un ritmo bastante constante: los mejores programadores solo notan más y son más rápidos para corregirlos.

• Tenga en cuenta que ambas afirmaciones anteriores provienen de Code Complete de Steve McConnell, por lo que no se trata de perspectivas diferentes.

Así que comencé a ver esto recientemente en mi código. Puedo obtener aproximadamente 4-5 veces la cantidad de código que muchos de mis compañeros (medidos por los puntos de historia estimados por el equipo), con una mayor calidad (según las métricas de rendimiento y la cantidad de cambios realizados después del check-in). Pero sigo cometiendo errores. Entre mejores pruebas unitarias, una mejor comprensión de lo que está haciendo el código y un mejor ojo para los problemas al hacer revisiones de código, no estoy produciendo entre 4 y 5 veces la cantidad de errores.

Pero sigo produciendo aproximadamente el doble de errores encontrados por QA que otros desarrolladores de mi equipo. Como puede imaginar, esto causa algunos problemas con personas no técnicas que realizan mediciones métricas (léase: mi jefe).

Intenté señalar que estoy produciendo errores a la mitad de la velocidad de mis pares (y corregir el doble), pero es difícil de vender cuando hay gráficos que dicen que produzco el doble de errores.

Entonces, ¿cómo lidiar con el hecho de que una mayor productividad conducirá a un mayor número de errores?

Creo que estás mezclando tus preocupaciones. Y no hay nada de tu lado que debas cambiar.

La productividad es una pista de lo rápido que se completará un proyecto. A los gerentes de proyectos y a todos los demás les gusta saber cuándo se realizará el proyecto. Una productividad más alta o más rápida significa que veremos el proyecto entregar antes.

La tasa de errores no está vinculada a la productividad, sino al tamaño del proyecto. Por ejemplo, puede tener Nerrores por Ylíneas de código. No hay nada dentro de esa métrica que diga (¡o le importa!) Cuán rápido se escriben esas líneas de código.

Para unir eso, si tiene una mayor productividad, sí, "verá" los errores que se escriben más rápidamente. Pero de todos modos ibas a tener esa cantidad de errores, ya que está relacionado con el tamaño del proyecto.

En todo caso, una mayor productividad significa que tendrá más tiempo al final del proyecto para buscar esos errores o el desarrollador será más rápido en encontrar los errores que crearon. ¹

Para abordar los aspectos más personales de su pregunta.

Si su jefe está observando estrictamente la cantidad de errores que produce en lugar de la tasa de errores que produce, una sesión educativa está en orden. El número de errores creados no tiene sentido sin una tasa de respaldo.

Para llevar ese ejemplo al extremo, dígale a su jefe que quiero duplicar su salario. ¿Por qué? No he creado absolutamente ningún error en su proyecto y, por lo tanto, soy un programador muy superior a usted. ¿Qué? ¿Va a tener un problema porque no he producido una sola línea de código para beneficiar su proyecto? Ah Ahora entendemos por qué la tasa es importante.

Parece que su equipo tiene las métricas para evaluar errores por punto de historia. Por lo menos, es mejor que medirlo por la cantidad bruta de errores creados. Sus mejores desarrolladores deberían estar creando más errores porque están escribiendo más código. Haga que su jefe arroje ese gráfico o al menos arroje otra serie detrás de él que muestre cuántos puntos de la historia (o cualquier valor comercial que mida) junto con la cantidad de errores. Ese gráfico contará una historia más precisa.

¹ _{Este comentario en particular ha atraído mucha más atención de la que pretendía. Así que seamos un poco pedantes (sorpresa, lo sé) y restablezcamos nuestro enfoque en esta pregunta.}

_{La raíz de esta pregunta es sobre un gerente que mira las cosas incorrectas. Están mirando los totales de errores sin procesar cuando deberían mirar la tasa de generación versus el número de tareas completadas. No nos obsesionemos con la medición contra "líneas de código" o puntos de historia o complejidad o lo que sea. Esa no es la pregunta en cuestión y esas preocupaciones nos distraen de la pregunta más importante.}

_{Según lo establecido en los enlaces por el OP, puede predecir un cierto número de errores en un proyecto únicamente por el tamaño del proyecto solo. Sí, puede reducir este número de errores mediante diferentes técnicas de desarrollo y prueba. De nuevo, ese no era el punto de esta pregunta. Para comprender esta pregunta, debemos aceptar que para un proyecto de tamaño determinado y una metodología de desarrollo, veremos un número determinado de errores una vez que el desarrollo esté "completo".}

_{Así que finalmente volvamos a este comentario que algunos entendieron completamente mal. Si asigna tareas de tamaño comparable a dos desarrolladores, el desarrollador con una mayor tasa de productividad completará su tarea antes que el otro. Por lo tanto, el desarrollador más productivo tendrá más tiempo disponible al final de la ventana de desarrollo. Ese "tiempo extra" (en comparación con el otro desarrollador) se puede utilizar para otras tareas, como trabajar en los defectos que se filtrarán a través de un proceso de desarrollo estándar.}

_{Tenemos que tomar la OP en su palabra de que son más productivos que otros desarrolladores. Nada dentro de esas afirmaciones implica que el OP u otros desarrolladores más productivos están siendo descuidados en su trabajo. Señalando que habría menos errores si pasaran más tiempo en la función o sugiriendo que la depuración no es parte de este tiempo de desarrollo, se pierde lo que se ha pedido. Algunos desarrolladores son más rápidos que otros y producen trabajos comparables o de mejor calidad. Nuevamente, vea los enlaces que el OP presenta en su pregunta.}

Dedique parte de ese tiempo extra a limpiar, pulir y probar su código. Todavía habrá errores, pero habrá menos. Eso lleva tiempo. La tasa de salida de su código disminuirá, pero su salida de código libre de errores aumentará, y eso dará como resultado una mejor productividad. Porque los errores son caros.

¿Puedes mantener tu código en una rama o en un entorno de prueba hasta que lo patees y descubras más errores? Los errores en una rama generalmente causan menos ondas que los errores en el código de producción.

Pero no estoy cavando exactamente sus afirmaciones que conducen a su pregunta. Y quizás tu jefe tampoco lo sea.

No creo que cada codificador produzca la misma tasa de errores. Su segundo enlace en realidad está completamente fuera del tema, ya que compara diferentes idiomas, no diferentes niveles de habilidades de codificador. El código completo menciona algunas mediciones de muestras grandes que analizan el proceso en lugar de la habilidad de los codificadores. Y cuando dicen que los codificadores de nivel superior producen más / mejor código, parte de eso significa que tiene menos errores. Depende de la aplicación. Entonces, sí, creo que ES una cuestión de perspectiva diferente.

Al final, si el jefe quiere un código más limpio, dale un código más limpio.

Me arriesgaré y seré el abogado del diablo. Eso no quiere decir que no simpatice con su situación, pero, bueno, mi simpatía no lo ayudará. Permítanme agregar a la perspectiva de Philip :

Su jefe se preocupa por la calidad del producto, en parte porque su nombre y reputación estarán vinculados a él. Parte de la calidad es la cantidad percibida de errores . Si vende un simulacro impresionante que perfora cuatro veces más rápido que cualquier simulacro de la competencia, pero que también se descompone el doble de veces, tendrá una mala reputación. Incluso si es discutible que el ejercicio funcione mejor, las personas se acostumbran a la velocidad, pero recordarán las averías.

En retrospectiva, la mayoría de los errores son obviamente prevenibles. Si solo fue un poco más cuidadoso, su jefe lo sentirá, podría evitar estos problemas y cualquier limpieza necesaria. Desde su perspectiva, es algo trivial y sensato preguntar, y cualquier discusión que hagas al respecto no funcionará y te hará quedar mal.

No puede medir su productividad superior. Reclama una mayor productividad basada en una métrica verificable, entonces, ¿cómo se sienten sus colegas al respecto? ¿Están de acuerdo, quizás a regañadientes, en que eres un programador más productivo o estás solo en tu opinión? Hará un punto más fuerte si tiene otras personas que respalden sus afirmaciones.

Eso es por perspectiva. Ahora, ¿cómo haces para 'arreglar' esta situación frustrante en la que te encuentras?

Disminuya la velocidad un poco. Mencione explícitamente a quien distribuya las tareas que intentará reducir la tasa de errores (*), para que no se sorprendan por su menor ingesta. En todo caso, reducir la velocidad reducirá la cantidad de errores asignados a usted por pura falta de suministro.

_{(*) Hay una diferencia entre, por un lado, reconociendo que hay son insectos a su nombre y que se va a tratar de disminuir esa cantidad y, por otro lado, admitiendo que usted tiene demasiados errores a su nombre y debe tomar acción.}

No trates de convencer a tu jefe, porque no funcionará. Nuevamente, eso no significa que tenga que reconocer su punto; Puede presentar un contrapunto y mantener su opinión sin descartar sus preocupaciones. Porque si argumenta el punto y no puede probar satisfactoriamente su productividad superior (e incluso si puede), correrá el riesgo de insultar a sus colegas o parecer despectivo. No quieres ser ese tipo .

Suponiendo que produciría la misma "cantidad" de código que sus colegas en el 20% de su tiempo, podría gastar 4 veces más en realmente depurar el código y hacerlo perfecto, lo que reduciría aún más su índice de errores. Entonces podrías llamarte un buen programador.

La pregunta más importante es por qué codifica 5 veces más que los demás en lugar de apuntar a la calidad. ¿Es esto algo que tu ego te dicta o tu jefe te obliga?

También debe considerar los costos para corregir un error. Cuando lo encuentre temprano, es posible que aún esté "dentro" del código lo suficiente como para solucionarlo rápidamente. Si aparece solo después de otro mes de desarrollo, podría ser difícil de encontrar o incluso forzarlo a cambiar grandes partes del código ya programado.

Parece que tienes el conjunto de habilidades para producir código, y podrías hacerlo increíble si te enfocas en la calidad en lugar de la velocidad. Pruébalo un rato, supongo que te gustará.

El siguiente problema es obtener el reconocimiento (hablar dinero) para su mejor desempeño. Hable con su jefe y pregúntele cómo proceder, después de todo, es su compañía y su dinero, y si quiere que produzca menos errores, también debe decidir de qué manera sucede.

Los desarrolladores pueden ser brillantes, incluso geniales, con una aptitud para comprender y codificar solo, sin ser buenos desarrolladores. Un buen desarrollador crea un trabajo de calidad y mejora todo el proyecto.

No digo que sea usted, pero uno de los programadores más frustrantes con los que he trabajado escribió más código que nadie en el equipo, y tuvimos buenas personas en el equipo. Seguimos los compromisos con un software de clasificación, por lo que fue casi una competencia para algunas personas. Produjo franjas de código, dejando atrás documentación CERO, bosques impenetrables, y de hecho hizo que mi código fuera difícil de entender (¡puedo hacerlo solo, muchas gracias!). Finalmente, casi descarriló el proyecto, porque se convirtió en un espectáculo individual. La gente no podía seguirlo. No estábamos sincronizados como equipo. De hecho, reescribimos algunas de sus características años después, solo para recuperar la capacidad de mantenimiento.

Lo que quería de él era reducir la velocidad y pasar más tiempo: 1) Mejorar la calidad de la base de código 2) Comunicarse con el equipo 3) Trabajar en cosas que ayudaron a otros, así como ayudarlo a terminar características / historias 4) Reparación loco

No estoy de acuerdo con medir la productividad por líneas de código, pero es una métrica clave. ¿Su contador de código incluye comentarios? Si es así, hay una manera fácil de mantener su salida de línea al tiempo que reduce su "proporción de errores"; simplemente aumente la calidad y cantidad de comentarios que escribe. Los comentarios rara vez tienen errores (aunque pueden) y, en general, no tenemos suficientes comentarios de calidad. Estoy no condonando código de la inflación, pero el acto de comentar es como una mini revisión de código, que obliga a pensar, refactor y mejorar.

Tratar de iluminar la administración no es un comienzo. Hay un viejo cliché: "¿Vas a creerme a mí oa tus ojos mentirosos?" Lo que preocupa a tus jefes son los errores. Ninguna cantidad de racionalización les dirá que es aceptable. Es más del doble de arriesgado. Además, no eres el único afectado por tu conteo de errores. El control de calidad tiene el doble de trabajo tratando de identificar sus errores, por lo que la administración querrá que haga menos de ellos.

La mejor solución es reducir la cantidad de errores que produce , punto. No solo la administración será más feliz, sino que usted también lo será. ¿No quieres? Porque estoy bastante seguro de que por mucho que disfrutes alardeando de que superas a tus compañeros de trabajo por un factor de cuatro, te encantaría decir que lo haces haciendo la misma cantidad de errores, o incluso menos, que ellos.

Como usted dijo, "... la tasa de errores cometidos en el código ... tiende a verse afectada por los procesos utilizados al escribir el código y después de que se escribe el código". Si desea modificar la velocidad a la que produce errores, tendrá que cambiar los procesos que utiliza para escribir código.

Los programadores usan métodos de producción para producir código, al igual que una línea de ensamblaje usa métodos para producir algún objeto producido en masa. De acuerdo, las prácticas de la industria del software se parecen más a la reducción de chucherías de las ramas que se encuentran en el bosque. Pero como estamos produciendo máquinas, debemos emplear el mismo rigor y disciplina que se usa para las máquinas de alta velocidad de producción en masa.

Eso incluye las mismas técnicas utilizadas en la producción en masa para reducir la tasa de defectos: análisis de la causa raíz para determinar por qué se producen errores y cambiar el proceso para que no se produzcan. O al menos eso que atrapas antes que el control de calidad.

1. Haga una lista de sus errores. Probablemente ya tienes uno gracias a los chicos de QA. Posiblemente categorizado también. Tipo de error, gravedad, el punto en el que se inyectó el error en el código, etc.

2. Elija la categoría más grande de errores. Como su volumen es tan alto, primero debe orientar esa categoría. Otras categorías incluyen las más fáciles de encontrar y las más fáciles de hacer.

3. Al saber dónde se introducen esos errores en el código, considere realizar cambios en esa fase (y anteriores) que eviten que ocurran esos errores, y formas de facilitar su detección en esa fase.

4. Asegúrese de ver los incidentes no relacionados con la programación, ya que pueden marcar la diferencia en la calidad de su trabajo. Música de fondo, interrupciones, comidas, trabajar demasiado tiempo sin descanso, hambre, etc.

Lo que encuentre puede llevarlo a ir más lento. Por otro lado, puede ayudarte a producir aún más rápido, ya que tendrás menos necesidad de volver a trabajar las cosas que ya has dejado atrás. Tal como está, cuatro veces más código no está cerca de ser un orden de magnitud mejor que sus compañeros de trabajo, por lo que cambiar su proceso es definitivamente el camino a seguir.

Cambie su objetivo de producir la mayor cantidad de código para ayudar a la empresa a avanzar más.

Como parece que tiene muchos colegas más tiempo adicional disponible, el mayor efecto que puede tener en una entrega más rápida de funciones y correcciones de errores es ayudar a sus colegas.

Ayude a sus colegas a

• utilizando revisiones de código para mejorar la calidad y la educación del código.
• creando automatización de procesos para hacer su trabajo más rápido y sus vidas más fáciles.
• escribiendo mejores pruebas con ellos
• atacando el código técnico para mejorar la base del código
• ser el tipo que siempre está disponible para ayudar a otros.
• herramientas de escritura / mejora que ayudan con la productividad del desarrollador
• haciendo caso a la gerencia para mejores herramientas / equipos / condiciones de trabajo para sus compañeros de trabajo si tiene más influencia.
• preparando y liderando sesiones educativas sobre cómo escribir un mejor código.
• practicando la humildad

Entonces, ¿cómo lidiar con el hecho de que una mayor productividad conducirá a un mayor número de errores?

Su jefe es la única persona que puede responder esto en su caso. Hable con él, señale su mejor relación y deje que él decida. Si su decisión no tiene sentido, es hora de buscar una empresa con su forma de pensar.

Como profesional, debe poder trabajar con cualquier condición dada del cliente, solo asegúrese de que comprenda las consecuencias. Un buen gráfico de errores / historias puede ayudar a su jefe a comprender cuánto se hundirá su productividad si se toma el tiempo para producir menos errores.

También debe tener en cuenta estos puntos:

• complejidad de las historias, por ejemplo, envoltorios simples de captador / definidor versus cálculos estadísticos o programación en tiempo real o incluso estadísticas en tiempo real ...
• gravedad de los errores, si se trata de pequeños errores tipográficos en los campos de texto o resultados de cálculo incorrectos, el programa se bloquea
• cuesta arreglar los errores, tanto si lo hace ahora, más tarde o si alguien más tiene que entender su código porque se fue

La situación es que trabajas cuatro veces más rápido que el programador promedio, pero cometes el doble de errores en un período de tiempo determinado. En relación con la cantidad de trabajo que realiza, en realidad comete la MITAD de tantos errores como "promedio".

Puede intentar señalar sus bajos errores en la proporción de trabajo, o incluso los errores en el producto completado (que puede completar en un cuarto del tiempo normal). La mayoría de los jefes lo aceptarán.

Hay algunos jefes que no lo hacen porque trabajan con una mentalidad de errores de "tolerancia" por vez. Luego, puede reducir su ritmo de trabajo, hacer DOS VECES tanto trabajo como el promedio en un tiempo determinado, y cometer los mismos (o menos) errores porque tiene más tiempo para verificar su trabajo.

Si su jefe quiere que mejore la calidad de su trabajo, entonces mejore la calidad de su trabajo.

Debería apuntar a cero errores, no apuntar a producir solo el doble que el próximo mejor programador.

Debes decirle a tu jefe que las métricas que está usando son bastante defectuosas. Si observa las pérdidas de balón de los guardias en la NBA, encontrará que tienden a tener un número mayor que los delanteros. Pero eso se debe a que están manejando más la pelota. Si un guardia no titular juega 1/5 tanto como un guardia inicial y gira la pelota más de 3 veces en promedio .vs. un guardia inicial que gira la pelota 7 veces por juego; a primera vista, podría parecer que el guardia inicial es peor. Pero, si divide el número de pérdidas de balón por el número de minutos jugados, entonces claramente el guardia inicial tiene números mucho mejores en función de los minutos jugados.

Del mismo modo, tiene números mucho mejores si la cantidad de errores se divide por la cantidad de puntos de historia completados. Entonces, eso es lo que le propondría a su gerente. Cambie la métrica para que sea la cantidad de errores divididos por los puntos de historia completados, o al menos agregue una nueva métrica para esto si se necesita la cantidad total de errores por desarrollador. Pero, dado que algunos puntos de la historia son mucho más difíciles y complejos que otros puntos de la historia, puede haber y habrá bastante variación, y el gerente también debe tenerlo en cuenta.

Lo que no creo que debas hacer es reducir la velocidad.

Medir el valor agregado

Argumenta que lo que realmente cuenta es el valor que agregas. Luego ve e introduce una medición aproximada (manual) de eso:

• Estime el valor de la funcionalidad que produce
• Resta tu salario
• Reste el costo estimado de sus errores (al menos el costo para corregirlos)
• Reste el costo estimado de todas las demás Deudas técnicas que produzca

El resto es su valor agregado. Del mismo modo para todos los demás.

Estas estimaciones son difíciles, pero incluso las aproximadas pueden hacer el punto. Y el simple proceso de discutir estas estimaciones es útil para el equipo y el proyecto.

Los principales programadores tienden a escribir código muy regular que es fácil de depurar y comprender, utilizan las herramientas disponibles (análisis estático, errores del compilador, código de depuración) al máximo. Además, los mejores programadores ya aprendieron el valor de las pruebas unitarias a través de su propia experiencia.

Entonces, aunque la cantidad inicial de problemas por línea es la misma, los problemas se eliminan más rápido.