¿Deben las organizaciones penalizar a los desarrolladores por la cantidad de informes de defectos presentados contra el código en el que trabajaron? [duplicar]

Parece que haría más daño que bien. Ignorando por un momento si es justo que un gerente haga eso, veamos la logística ...

Problema 1: ¿Todos los errores se crean de la misma forma?
Developer 1 introduce un error: borra todos los datos de los clientes y los insulta.
El desarrollador 2 introduce dos errores: las etiquetas de formulario no se dejan alineadas, y la función de calendario está desactivada por 1 segundo si se crea un evento que abarca dos años bisiestos.

Claramente, el desarrollador 2 merece más duelo de parte de su administrador porque tiene el doble de errores. Por supuesto que no, así que creas un sistema de clasificación de errores para que los desarrolladores con errores triviales no sean tan afectados. Pero espere, ¿debería el sistema tener en cuenta un modificador para un desarrollador que claramente está cometiendo el mismo error trivial repetidamente y está perdiendo el tiempo del examinador porque nunca aprenden de sus errores? Tal vez, hmmm. Esto es complicado.

Problema 2: ¿Qué se considera un error?
Administrador : este informe debía incluir un total acumulado, ¡ese es un error para usted!
Desarrollador : eso no estaba en los requisitos, eso es una CARACTERÍSTICA no un error.

Problema 3: ¿Cómo agrupas errores?
Desarrollador - "[Nombre del administrador], los evaluadores presentaron 10 errores en mi contra porque las velocidades eran incorrectas en 10 pantallas diferentes, pero todo se relacionó con un solo error en la función getVelocity. Discutimos durante 3 horas al respecto, pero no se movieron. Nos gustaría una reunión con usted para decidir cuántos errores se deben presentar . Ah, y por cierto, no hay manera de que lleguemos a la fecha límite de código completa mañana ".

Problema 4: más SLOC probablemente significa más errores
Developer 1 permanece en su trasero todo el día, pero logra escribir 3 líneas de código sin errores entre los argumentos de Reddit sobre la ley de inmigración de Arizona.
Developer 2 funciona todo el día y produce una IA completamente funcional que no matará a John Connor la primera oportunidad que tenga ".

Obviamente, usted quiere penalizar al desarrollador que progresa más y / o toma más riesgos mediante la innovación, ¿no?

Resumen
Probablemente haya soluciones viables para varios de estos, pero como gerente de un equipo de programación que intenta cumplir con una fecha límite, ¿realmente quiere que todos pasen tiempo discutiendo sobre lo que cuenta como un error, lo que cuenta como un error discreto, la importancia de un error, etc.? Ninguna de estas cosas hará avanzar su proyecto y esto será un veneno para los equipos que se verán obligados a competir en temas que no tengan un impacto significativo en el software real que se está creando. Sin mencionar lo que le hace a su cultura de empleados enfocar este gran esfuerzo en encontrar maneras de asegurarse de que los errores de cada empleado se registran meticulosamente para que puedan ser rechazados en su cara más adelante.

Inevitablemente, los desarrolladores persuadirán a los evaluadores para que resuelvan su sistema de seguimiento de errores e informen los problemas directamente para que puedan solucionarlos sin que se encuentren en su "ARCHIVO PERMANENTE". Entonces, ni siquiera tiene una contabilidad precisa de los errores o en lo que la gente realmente está trabajando.

Luego está la cuestión del impacto adverso. Para eso está el tema de Recursos Humanos, es mejor que tenga una buena documentación antes de comenzar a penalizar a los empleados, especialmente a nivel financiero. Y si alguno de ellos es una clase protegida (minorías, veteranos, mujeres, discapacitados, etc.) es mejor que se triplique para asegurarse de que cualquier sistema que haya establecido no discrimine a uno de ellos en función de su membresía en esa clase (o que un juez podría ser convencido como tal), incluso si es solo un efecto secundario no planeado del plan.

Por lo tanto, en última instancia, no está creando incentivos para crear menos errores, lo que es difícil, sino más bien para negociar los errores minimizando su importancia o culpándolos a otra persona.

Versión corta No.

Los programadores son conocidos por optimizar lo que los gerentes comienzan a recompensar. Si recompensa a LOC, entonces obtiene una gran cantidad de espacios en blanco para rellenar las líneas de la métrica del código. Si intentas castigar por el número de errores, comenzarás a meterte en guerras en las que los desarrolladores afirman que X no es su (el error está en el compilador o API o simplemente en algún otro lugar) - y el error que se presentó contra ellos es incorrecto.

El último lugar donde trabajé tenía un desarrollador "a cargo" de un producto. Mientras que el desarrollador "a cargo" nunca cambió con el paso del tiempo, otros trabajaron en el proyecto cuando la carga estacional lo hizo necesario. Nadie señaló con el dedo y dijo "¡usted escribió ese error!" En cambio, el objetivo era reducir los errores en los productos.

Los lugares en los que he trabajado que tenían penalizaciones por errores también tuvieron un giro muy alto. El hecho de señalar con el dedo contribuyó a crear un entorno hostil que llevó a la salida de los desarrolladores.

Los desarrolladores deben responsabilizarse por la calidad del código que producen, y deben esperar que su gerente haga lo mismo. Pero eso no significa que algún desarrollador deba obtener un demérito cada vez que se informe de un error. Ningún gerente en su sano juicio diría:

  

Bueno, Johnson, verificaste 500 líneas de código la semana pasada, y hasta ahora   Se han rastreado 241 informes de errores a ese código.

Es mucho trabajo averiguar a quién culpar por cada pequeño defecto, y la cantidad de informes de errores no siempre te dice mucho sobre la calidad del código. Pero un buen gerente debe notar los problemas y encontrar maneras de solucionarlos. Él o ella podría decir:

  

Johnson, eso fue un hedor de un registro la semana pasada, hemos estado   Obtención de informes de errores a tres veces la tasa normal. Necesitamos conseguir   lo solucioné lo antes posible, así que le pedí a Ferguson 'Ojo de Águila' que repasara el   codigo contigo Estoy seguro de que ustedes dos lo resolverán, y ol '   Eagle-Eye puede mostrarte algunos trucos en el camino.

Todos los desarrolladores deben esperar que el administrador note su rendimiento, incluida la calidad general de su código. Los desarrolladores también deben esperar que sus colegas lo noten, después de todo, todo está en el repositorio. Así que si eres ese tipo con el alto número de errores, no te avergüences de pedir ayuda. Probablemente, el resto del equipo ya sepa dónde se encuentra, y si hace un esfuerzo concertado para mejorar el equipo (y el gerente) se dará cuenta de eso también.

Entonces, sí , debe ser responsable del código que escribe, pero no , la organización no debe tener una política de penalizar a los desarrolladores individuales por defectos específicos. , o por exceder algunos informes de defectos. Eso solo va a alentar a las personas a encontrar formas de evitar la culpa, como señalar con el dedo o ser tan cuidadosos que la productividad disminuye. No ayuda el esfuerzo de desarrollo si las personas tienen miedo de aceptar la responsabilidad por lo que escriben. Por cierto, también no ayuda a darle la vuelta y recompensar las correcciones de errores específicos . ;-)

No, no deberían. Esto no es un trabajo manual y ninguno crea errores intencionalmente. ¿Cómo podemos esperar productividad de un triste programador horrorizado? Las cosas deberían estar bien a su alrededor. En última instancia, nadie se beneficia de penalizar.  

Yo digo que esta es una mala idea que hará poco pero creará un entorno de trabajo hostil.

Incluso me atrevería a decir que CUALQUIER REFUERZO NEGATIVO como motivador para el desempeño laboral creará una fuerza laboral infeliz y una alta rotación. Incluso los buenos desarrolladores se sentirán estresados por el deslizamiento.

El refuerzo negativo es incluso degradante para los niños y los perros, ¿por qué trataría a un profesional de esta manera?

En su lugar, use refuerzos positivos para los NÚMEROS DE DEFECTO BAJOS e intente activamente ayudar a los miembros de su equipo que tienen dificultades. Si no funciona con alguien a largo plazo, simplemente déjalo ir.

Abandonaré la tendencia aquí, me arriesgaré y le daré un rotundo ¡SÍ! , pero con cierta calificación: solo para desarrolladores que tienen al menos una desviación estándar peor que su compañeros

Déjame dividirlo un poco, porque hay algunos problemas cargados aquí. En primer lugar está la palabra "compañeros". Ciertamente no es correcto comparar el trabajo de un veterano de 10 años con el de un nuevo empleado recién salido de la universidad. El novato tiene menos experiencia, pero al profesional se le asignan tareas más difíciles.

El siguiente paso es la desviación estándar. Históricamente, los programadores, por un lado, resistirán cualquier intento de medir cuantitativamente su trabajo con las métricas de juego, y, por el otro, practicarán el arte de encontrar diariamente formas de cuantificar lo no cuantificable a través del software y citarán métricas acerca de cómo son los programadores de Rockstar X veces más productivo que el promedio. Hay una verdad obvia en ambos lados.

Mi creencia es que la mejor métrica de uso, incluso las simplistas como "líneas de código", es para identificar los sobresalientes. Establece un límite de una desviación estándar o dos fuera de la norma, de modo que los programadores individuales no podrán salir del paquete. No busque el programador superior o inferior. El punto aquí es que la mayoría de las veces, nadie está identificado y, por lo tanto, no hay nada en juego. Pero de vez en cuando te ayudará a encontrar esa joya de programador o a decirte quién es tu bajo desempeño. ¿Y entonces sabes lo que haces? Nada . Al menos al principio. En cambio, piense en ello como inteligencia no confirmada. Use la información para observar a la persona y busque para confirmarla en otro lugar.

Si tiene un programador que está revisando los errores un orden de magnitud más a menudo que sus compañeros, primero encuentre algo que corrobore su desempeño general y luego hable con él. Y la primera vez, probablemente debería ser solo una charla.

Mi opinión es negativa, ya que si una organización penaliza a los desarrolladores por la cantidad de errores que se presentan en su contra, el desarrollador puede ser menos productivo para evitar las penalizaciones, suponiendo que sean importantes. También puede haber conflicto sobre qué errores se presentarían contra un desarrollador, ya que puede haber una persona de control de calidad que tome una visión liberal de lo que constituye un error que es otro factor aquí. Si bien se podría tratar de equilibrar las sanciones, me gustaría saber qué tan bien se hace en la realidad.

Mi antiguo compañero de trabajo me contó la historia de un lugar donde esta práctica se aplicaba realmente: los desarrolladores fueron penalizados por cada error encontrado en su código, y el control de calidad fue recompensado por cada error que descubrieron. El resultado fue que los desarrolladores simplemente dejaron de desarrollar código nuevo porque esa era la única forma de protegerse de las sanciones.

Los desarrolladores no son perezosos ni ignorantes de lo que es mejor. En mi opinión, sería más productivo ofrecer a los desarrolladores una línea de tiempo más precisa y mejores especificaciones antes de que se inicie el proyecto.

Definitivamente no.

Es como degradar a los médicos porque algunos de los pacientes mueren, sin considerar la gravedad de la enfermedad / lesión.

Hay algunos proyectos donde los defectos son inevitables. Si tiene patrocinadores de proyectos con necesidades conflictivas, los requisitos de los usuarios que entran en conflicto con las pautas de seguridad, aunque se realicen cambios de última hora, se plantearán defectos independientemente de la calidad de su código.

También existe un problema perenne (al menos en la mayoría de las organizaciones grandes) de la infraestructura que cambia a su alrededor. Codifica V1.25 de la base de datos en V3.8 del sistema operativo, pero otro departamento actualiza a V2.0 y V4.0 justo antes de su lanzamiento. (O baje la calificación, en un caso, codificamos para V5.0 J2EE solo para que se cancele la actualización y debamos desclasificar a V4.0 días antes del lanzamiento: hubo muchos defectos).

Finalmente, tenemos usuarios pragmáticos que plantean defectos en lugar de solicitudes de cambio, ya que la carga burocrática es significativamente menor.

No. Suena tratando de tratar un síntoma, no el problema de la raíz. En lugar de centrarse en cuántos errores hay en un trozo de código y quién los introdujo, ¿por qué no enfocarse en desarrollar un sistema que ayude a eliminar errores en primer lugar?

Las herramientas como Pruebas Unitarias, Pruebas de Integración, Desarrollo Dirigido por Pruebas, Análisis de Código Estático, Revisiones de Diseño y Revisiones de Código a menudo pueden detectar un buen número de errores antes de ingresar al código base. La integración continua también ayuda a identificar los problemas más temprano que tarde.

Por cierto, el seguimiento lógico de la pregunta OP: Si heredo un fragmento de código lleno de errores, ¿debería ser penalizado por todos los errores restantes si soluciono uno? Por la propuesta original, ya que trabajé en el código, ahora soy responsable de los errores.

¿Cuál es la motivación para penalizar a los desarrolladores por sus tasas de defectos?

Sin duda, el objetivo es intentar medir la calidad del código que está escribiendo el desarrollador.

El problema es que la calidad es un poco amorfa: es muy difícil de medir. De hecho, no se puede medir directamente, hay que intentarlo y aproximarlo midiendo otras cosas.

Además, elegir un solo KPI, como # defectos, da como resultado el juego del sistema. Si sugiere penalizar a cada desarrollador $ 10 por defecto, ¿cuánto tiempo cree que pasaría antes de que uno de los desarrolladores haga un trato con un probador ... le pagaré $ 5 por cada defecto que me informe sobre eso No te registres.

Permítales que repare todos los errores relacionados con su código, envíeles las quejas del departamento de pruebas y ya deberían saber que menos errores es mejor para ellos.

Y cuando todo va bien, y no llegan informes de errores, una palmada en la espalda como recompensa y algunas palabras amables deben hacer el resto.

Aunque no estoy de acuerdo con la premisa ...

Solo podría ser factible si recompensara al programador que también tiene características más desafiantes desde el punto de vista técnico: "mayor riesgo, mayor recompensa". De lo contrario, ¿por qué un programador podría asumir un trabajo desafiante en ese entorno, ya que cualquier desafío técnico es una responsabilidad (no una oportunidad de recompensa)?

Estoy de acuerdo en que también crearía un ambiente muy hostil. En mi experiencia, una cantidad significativa de defectos se debe a la ambigüedad del requisito o simplemente a la falta de un requisito. Así que creo que esto también podría llevar a que esos defectos se asignen explícitamente al analista de negocios, ingeniero de sistemas o patrocinador del proyecto, y deberían estar sujetos a la misma sanción, lo que no sería algo malo.

Yo diría que contarlos es un error. No hay forma de que puedas moler algo así a un número. Sin embargo, si el código de un desarrollador en particular parece tener más problemas que un código similar escrito por otros, y este es un patrón consistente, entonces diría que el desarrollador probablemente no sea tan bueno, todas las demás cosas son iguales. Es un hecho que hay que poner en la mezcla.

En cualquier caso, he estado en este negocio durante décadas, y no puedo decir que alguna vez he visto a un programador que tenía una tasa de errores inusualmente alta o inusualmente baja. He visto programadores que eran más rápidos o más lentos, programadores que podían hacer trabajos o que tenían problemas. He visto programadores que naturalmente escriben código muy fácil de entender, código muy rápido o código muy confuso. Pero nunca he visto a un programador con una tasa de errores atípicamente alta o baja. Quizás no haya prestado suficiente atención.

No me opongo a esta idea, pero SOLO si hay consenso acerca de los defectos: un grupo designado de técnicos de alto nivel que rige sobre ellos. Los usuarios, licenciados y administradores a menudo no están calificados para decidir qué es un defecto de código, y siempre es peligroso poner algo como esto bajo el control de una (o cualquiera) persona.

Pero no creo que sea realmente necesario: cuando un desarrollador escribe constantemente un código incorrecto, si sus superiores y compañeros están haciendo su trabajo, no será un secreto por mucho tiempo y el desarrollador sufrirá las consecuencias con una Sistema formal de 'deméritos'.