¿Son los errores parte de la deuda técnica?

Creo que la respuesta aquí es bastante simple: la característica clave de la deuda técnica es que es algo en lo que incurrimos por elección.

Elegimos tomar decisiones de arquitectura, diseño o implementación que esperamos que nos causen problemas más adelante para lograr objetivos específicos antes.

Un error no es algo que elegimos tener en nuestro código, por lo que de facto no es una deuda técnica.

Por supuesto, uno puede hacer todo tipo de argumentos interesantes (y posiblemente válidos) sobre las elecciones realizadas después del descubrimiento, pero fundamentalmente (y particularmente en el contexto de la pregunta) no, los errores no son una deuda técnica, suena más como un abuso del bingo de palabras de moda. a mi.

Como posdata: no estoy de acuerdo con la afirmación de que es un hecho que la deuda técnica conducirá a errores en sí misma, ya que hace mucho para muchas suposiciones sobre la naturaleza de las elecciones hechas. Por ejemplo, puede tener un código bien escrito, bien estructurado y cubierto por pruebas que aún presente, digamos, compromisos arquitectónicos para la entrega temprana. Del mismo modo, puede elegir no automatizar sus procesos de implementación que no provocarán errores, sino que probablemente generarán mucho estrés y dolor. Por supuesto, si la deuda es que has escrito un código que no es SÓLIDO (o lo que sea), entonces sí ... pero eso no es siempre el caso.

Sí.

  

La deuda técnica (también conocida como deuda de diseño o deuda de código) es una metáfora neologista que se refiere a las posibles consecuencias de una arquitectura de software deficiente o en evolución y al desarrollo de software dentro de una base de código.

Fuente: Wikipedia

Lea la deuda técnica como algo que podría haber evitado al tener un mejor flujo de trabajo (por ejemplo, hacer una arquitectura adecuada antes de pasar a la codificación, hacer TDD, etc.), mejores prácticas de codificación, etc.

La mayoría de los errores podrían haberse evitado mediante una revisión adicional o el uso de métodos más formales. Al no hacer todo lo posible para no tener errores en primer lugar, reduce el costo inmediato / a corto plazo del proyecto, pero aumenta la deuda técnica.

Después de leer la respuesta de BЈовић , veo que puede que no sea tan fácil como pensé.

• Por ejemplo, ¿Los errores son parte de la deuda técnica? el artículo afirma que solo los errores que conoce pero que decidió no solucionar son parte de la deuda técnica.

• Otro ejemplo, Reflexiones de Christopher sobre la deuda técnica califica a los errores como el resultado de deuda técnica, no parte de ella. Dicho esto, muchos de los resultados enumerados, como "costo para implementar una nueva característica", están influenciados por la cantidad de errores.

• Finalmente, al crear modelo de deuda técnica ABCDE-T , incluí errores como uno de los seis factores, pero son considerado de manera diferente. El enfoque no está en los errores en sí mismos, sino en la forma en que se recopilan, priorizan y resuelven. Los errores aparecen como resultado de la deuda técnica (como en el ejemplo anterior), pero nunca aparecen como un factor de deuda técnica.

Dicho esto, Todavía me inclino a responder que los errores, cualquier error, son parte de la deuda técnica.

Primer argumento:

Leyendo la cita de Jeff Atwood, la mayoría de los errores calificarían como:

  

el esfuerzo adicional que tenemos que hacer en el desarrollo futuro debido a la elección de diseño rápido y sucio

En las aplicaciones empresariales, casi todos los errores provienen de una elección de diseño rápida y sucia o de malas prácticas (sería la falta de pruebas, el uso de tecnologías que los desarrolladores no conocen lo suficiente, la falta de comunicación, la falta de comprensión de el dominio, etc.) Esto significa que "al refactorizar el diseño rápido y sucio al mejor diseño" y al adaptar las mejores prácticas, las empresas podrían resolver la mayoría de sus errores.

Segundo argumento:

Si hacemos un paralelismo entre la deuda ordinaria de una empresa que es importante tener en cuenta cuando una empresa se vende a otra, y la deuda técnica, que es igualmente importante tener en cuenta cuando un proyecto se vende a otra En compañía o entregado a otro equipo, podemos ver fácilmente que los errores son parte de la deuda técnica, ya que el nuevo equipo:

• Tiene que lidiar con esos errores antes de crear nuevas funciones (punto 5 de Joel Test: ¿Corrige los errores antes de escribir un nuevo código?)

• O mantenga los errores, preservando / aumentando de esta manera la deuda técnica.

Jeff Atwood en su artículo Cómo pagar su deuda técnica da una respuesta bastante buena sobre lo que es la deuda técnica:

  

la deuda técnica incurre en pagos de intereses, que se presentan en forma de   El esfuerzo adicional que tenemos que hacer en el desarrollo futuro debido a   La elección de diseño rápido y sucio. Podemos optar por seguir pagando.   El interés, o podemos pagar el principal mediante la refactorización de la   Diseño rápido y sucio en el mejor diseño. Aunque cuesta   Pagamos el principal, ganamos por pagos de intereses reducidos en el   futuro.

Estrictamente hablando, los errores no son parte de la deuda técnica, si no ralentizan el desarrollo de software (cambiando las cosas, agregando nuevas funciones, etc.). Son defectos de software.

Sin embargo, cuando es demasiado costoso arreglar un error o lo obliga a solucionarlo (e introducir una deuda aún más técnica), se convierte en parte de una deuda técnica.

Un error no es deuda técnica. La deuda técnica está escatimando en calidad, no en su ausencia. El software no se debe entregar con errores en él en primer lugar. Ya sabes, todo el software en funcionamiento sobre la documentación completa.

Los mayores infractores de la deuda técnica son las "correcciones de errores temporales". Conoces los que has superado para aprobar la prueba y que se acepte la historia. Los que te prometiste a ti mismo los refactorizarás más tarde, pero nunca lo harás. A medida que estos arreglos temporales, parches y otras cosas se acumulan, el código se vuelve innecesariamente abarrotado, difícil de actualizar y probar y, en general, es una pesadilla, pero aún así hace su trabajo.

Para apoyar esta opinión, fui directamente a la fuente, Ward Cunningham. Respecto a esto, Ward hizo una buena entrevista hace un tiempo con Capers Jones, vale la pena verlo.

Debate de deuda técnica, con Ward Cunningham & Capers Jones

Otro artículo que vale la pena leer es de Martin Fowler

Martin Fowler sobre deuda técnica

En el artículo de Martin, encuentre el enlace a la mención original de deuda técnica por Ward Cunningham, de OOPSLA92:

El sistema de gestión de cartera WyCash

Una cita del artículo anterior:

  

Aunque el código inmaduro puede funcionar bien y ser completamente aceptable para   el cliente , las cantidades en exceso harán que un programa no se pueda administrar,   Lo que lleva a la extrema especialización de los programadores y, finalmente, una   Producto inflexible. Enviar el primer código de tiempo es como endeudarse.

Al final, la deuda técnica puede haber llegado a incluir errores para algunas personas, y supongo que eso está bien. Simplemente no creo que esa fuera la intención original.

En mi opinión, realmente no importa si usted dice que los errores son parte de la deuda técnica ... o no.

El hecho evidente es que los errores existentes representan un trabajo adicional que puede necesitar ser realizado en el futuro, ya sea para solucionarlos o para solucionarlos.

La deuda técnica (como se suele usar la etiqueta) también representa un trabajo adicional que puede debe realizarse en el futuro ... de una forma u otra.

Entonces, si usted dice que los errores conocidos (o desconocidos) son una deuda técnica ... o no ... es solo una cuestión de definiciones. Y dado que no hay una definición de "deuda técnica" en autoritativa ¹ , toda la discusión no tiene sentido.

Como Lewis Carroll escribió:

  

'Cuando uso una palabra', dijo Humpty Dumpty en tono burlón, 'significa simplemente lo que elijo que signifique, ni más ni menos'. .

Así es como funciona el lenguaje natural. Las palabras significan lo que la gente piensa que significa. Las definiciones de diccionario y demás, simplemente document , la forma en que se usan las palabras, y no son necesariamente una documentación precisa. Si su Scrum Master quiere referirse a errores conocidos como deuda técnica, ¿quién puede decir que está "equivocado"?

^{1 - Tampoco ayuda citar a personas como Ward Cummingham y Caper Jones. En el mejor de los casos, nos dice qué significan (o qué significan) cuando usan (usan) la frase. No "poseen" la frase. Si bien, sin duda, son autoridades en estos temas, esta es solo su opinión.}

Estrictamente hablando, la respuesta a su pregunta es No.

La deuda técnica puede (y probablemente lo hará) provocar errores, pero concluir que cualquier error es el resultado de una deuda técnica es poner una interpretación entre dos hechos: hay un error y hay información técnica deuda (suponiendo que se pueda concluir como un hecho).

Si su Scrum Master está afirmando 'como una teoría' que los errores son el resultado de una deuda técnica, él está cortando esquinas. Si está diciendo esto sobre errores específicos que siguen apareciendo, puede que tenga razón: desde aquí no podemos ver la calidad del código ;-)

También puede tener una queja en curso sobre las personas que no lo escuchan sobre la deuda técnica y, por lo tanto, etiquetan cada error como deuda técnica, pero ahora estoy especulando.