¿Hay un beneficio marginal en la corrección de errores [cerrado]

Un ex colega me ha dicho que no todos los errores deben corregirse, ya que a medida que avanza en la lista de prioridades de errores, el caso de uso que causa ese error se vuelve más oscuro o la satisfacción del cliente obtenida disminuye. Pero aún debe dedicar un tiempo considerable a solucionar ese error.

En un esfuerzo por convencer a nuestro propietario del producto sobre este concepto, no pude encontrar buenos recursos. Todo lo que pude encontrar fue discusiones sobre si hay un costo marginal en el desarrollo de software o no.

¿Existe realmente un beneficio marginal en la corrección de errores? ¿Existe un término diferente que explique este concepto?

Desde una perspectiva empresarial, una corrección de errores no es diferente a una solicitud de función. Tiene un cierto costo en tiempo de desarrollo, y tiene un cierto valor para los clientes. Si un error no es crítico, puede tener un buen sentido comercial priorizar una característica valiosa por encima de la corrección del error.

Pero desde una perspectiva técnica, los errores pueden ser más críticos, ya que indican un error en una base que otro código podría usar / construir, en cuyo caso el error es "contagioso" y agrega costos al mantenimiento futuro. Por lo tanto, no corregir un error es una deuda técnica que requiere administración, mientras que no implementar una característica realmente no tiene un costo continuo. Pero el nivel de deuda técnica incurrido por un error depende mucho de la naturaleza del error.

Todos estos factores deben tenerse en cuenta al priorizar.

En cuanto a si hay un beneficio marginal para corregir errores: esto es un hecho. Dado que no todos los errores son iguales en gravedad, naturalmente prioriza primero los errores más importantes. Entonces, cuantos más errores solucione, menor será el valor marginal de corregir el siguiente. Pero si alguna vez alcanza el nivel en el que solucionar el error no vale la pena, es una decisión comercial más que una decisión técnica.

Aquí hay una buena referencia

http://www.joelonsoftware.com/articles/fog0000000043.html

¿Tú arreglas los errores antes de escribir un nuevo código? La primera versión de Microsoft Word para Windows se consideró un proyecto de "marcha de la muerte". [...] porque la fase de corrección de errores no formaba parte de la programación formal [...]

Microsoft adoptó universalmente algo que la [...] máxima prioridad es eliminar errores antes de escribir cualquier código [...] nuevo En general, cuanto más espere antes de corregir un error, más costoso (en tiempo y dinero) es corregirlo. .

Puede estar seguro de que cuanto más tiempo estarán esos errores, más tiempo tardará en solucionarlos una vez que se conviertan en la prioridad. Entonces, en lugar de tener un beneficio bruto en este momento, está evitando una pérdida más costosa en el futuro.

Una buena manera de gestionarlo sería definir una cantidad de tiempo asignada para manejar los problemas de la acumulación. Esto no presionaría tanto como lo hizo Microsoft, pero asegurará una cantidad de resolución de problemas futuros, si aún no son su problema, incluso si al cliente realmente no le importa.

En un esfuerzo por convencer a nuestro propietario del producto sobre este concepto, no pude encontrar buenos recursos.

Suponiendo que esté trabajando para una organización comercial, seguramente habrá alguien allí que conozca el Análisis de costo-beneficio .

Su organización tiene una cantidad finita de recursos para desarrolladores y una lista infinita de cosas beneficiosas para hacer. Esas cosas beneficiosas incluyen agregar nuevas funciones y eliminar errores existentes: eliminar un error mejora el software, al igual que agregar una nueva función.

Entonces, obviamente, hay que tomar decisiones sobre cómo asignar este recurso finito a esta lista infinita, y no es particularmente sorprendente que el resultado sea que algunos errores no se solucionan en este momento, la próxima semana, el próximo año o en hecho alguna vez.

Si está buscando un enfoque más estructurado aquí, puede probar el sistema PEF / REV que asigna números a las vistas de error y del programador, como punto de partida para decidir qué se arregla y qué no.

Vea también estas dos publicaciones aquí en Ingeniería de software:

Resolver qué errores darán el mayor beneficio de costo

Casi todos los errores reportados son de alta prioridad

No todos los aspectos no intencionales o indeseables del comportamiento del software son errores. Lo importante es garantizar que el software tenga una gama útil y documentada de condiciones en las que se pueda confiar para que funcione de manera útil. Considere, por ejemplo, un programa que debe aceptar dos números, multiplicarlos y generar los resultados, y que genera un número falso si el resultado es más de 9.95 pero menos de 10.00, más de 99.95 pero menos de 100.00, etc. Si el programa fue escrito con el propósito de procesar números cuyo producto estaba entre 3 y 7, y nunca se le pedirá que procese ningún otro, corregir su comportamiento con 9.95 no lo haría más útil para el propósito previsto. Sin embargo, podría hacer que el programa sea más adecuado para otros fines.

En una situación como la anterior, habría dos cursos de acción razonables:

1. Solucione el problema, si hacerlo es práctico.

2. Especifique rangos en los cuales la salida del programa sería confiable y establezca que el programa solo es adecuado para su uso en datos que se sabe que producen valores dentro de rangos válidos.

El enfoque n. ° 1 eliminaría el error. El Enfoque n. ° 2 puede hacer que el progreso sea menos adecuado para algunos propósitos de lo que podría ser de otra manera, pero si no hay necesidad de que los programas manejen los valores problemáticos, eso podría no ser un problema.

Incluso si la incapacidad para manejar los valores de 99.95 a 100.0 correctamente es el resultado de un error de programación [por ejemplo, decidir generar dos dígitos a la izquierda del punto decimal antes de redondear a un lugar después, dando así 00.00], solo debe considerarse un error si el programa se especificaría de otro modo como producir resultados significativos en tales casos. [Por cierto, el problema antes mencionado ocurrió en el código Turbof 2.00 printf; en ese contexto, es claramente un error, pero el código que llama a printf defectuoso solo tendría errores si pudiera producir salidas en los rangos problemáticos].

En un sentido laxo, sí, no todos los errores deben corregirse. Se trata de analizar la relación riesgo / beneficio.

Lo que generalmente sucede es que la empresa tendrá una reunión con líderes técnicos y partes interesadas para discutir errores que obviamente no están en la pila de 'necesidad de arreglar'. Decidirán si el tiempo (= dinero) invertido en solucionar el error valdrá la pena para el negocio.

Por ejemplo, un 'error menor' podría ser un ligero error ortográfico / gramatical en la sección de Términos y condiciones de un sitio web. La persona que planteó esto puede pensar que es demasiado pequeño para cambiar, pero la empresa reconocería el daño potencial que podría causar a la marca y la relativa facilidad de corregir algunos caracteres.

Por otro lado, podría tener un error que parece importante, pero es difícil de solucionar y solo afecta a una cantidad insignificante de usuarios. Por ejemplo, un enlace de botón menor está roto para los usuarios que usan una versión heredada de Google Chrome y también tienen JavaScript deshabilitado.

Otras razones para que la empresa NO repare un error podría ser que el tiempo invertido retrasaría el proyecto una cantidad inesperada de tiempo, o que el tiempo del desarrollador se gastaría mejor trabajando en otras correcciones / codificación. También podría ser que el error sea lo suficientemente menor como para que pueda activarse y luego repararse en una fecha posterior.

¡Espero que eso explique el concepto un poco mejor! Ciertamente me alejaría de pensar en esto en términos generales: cada error es único y debe tratarse como tal.

Porque a medida que avanza en la lista de errores prioritarios, el caso de uso que causa ese error se vuelve más oscuro o la satisfacción del cliente obtenida disminuye.

Entonces su "argumento" es en realidad

Si ignora el error el tiempo suficiente, el Usuario olvidará cuál fue el problema o encontrará alguna forma de solucionarlo.

Los errores deben ser priorizados y tratados "en orden" al igual que las nuevas solicitudes de funciones (pero, posiblemente, más allá de todo lo último).