¿Los errores son parte de la deuda técnica?

Nuestro Scrum Master sigue refiriéndose a los errores como deuda técnica. ¿Tiene razón, se considera que los errores son una deuda técnica en el mundo de Agile?

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 hecho 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, me parece más un abuso del bingo de palabras de moda.

Como una 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 eso lleva a muchos supuestos sobre la naturaleza de las elecciones realizadas. Por ejemplo, puede tener un código cubierto de prueba, bien estructurado y bien escrito que aún suponga, por ejemplo, compromisos arquitectónicos para la entrega anticipada. Del mismo modo, podría optar por no automatizar sus procesos de implementación, lo que no generará errores, pero probablemente generará mucho estrés y dolor. Por supuesto, si la deuda es que ha escrito un código que no es SÓLIDO (o lo que sea), entonces sí ... pero de ninguna manera siempre es así.

Si.

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 pobre o en evolución y el 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 la arquitectura correctamente antes de saltar 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 pensaba.

• Por ejemplo ¿Son los errores parte de la deuda técnica? El artículo afirma que solo los errores que conoce pero decidió no corregir son parte de la deuda técnica.

• Otro ejemplo, Christopher's Thoughts on Technical Debt califica los errores como resultado de la 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 el modelo ABCDE-T de deuda técnica , incluí los errores como uno de los seis factores, pero se consideran de manera diferente. El enfoque no está en los errores en sí mismos, sino en las formas en que se recopilan, priorizan y resuelven. Los errores en sí aparecen como resultado de una deuda técnica (como en el ejemplo anterior), pero nunca aparecen como un factor de deuda técnica.

Dicho esto, todavía estoy dispuesto a responder que los errores, muchos errores, 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 comerciales, 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 del dominio, etc.) Esto significa que "refactorizando el diseño rápido y sucio en el mejor diseño" y adaptando mejores prácticas, las empresas podrían resolver la mayoría de sus errores.

Segundo argumento:

Si hacemos un paralelo 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 empresa o se entrega para otro equipo, podemos ver fácilmente que los errores son parte de la deuda técnica, ya que el nuevo equipo:

• O bien, debe lidiar con esos errores antes de crear nuevas funciones (punto 5 de la Prueba de Joel: ¿corrige los errores antes de escribir un nuevo código?)

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

Jeff Atwood en su artículo Pagando su deuda técnica da una respuesta bastante buena sobre qué es la deuda técnica:

la deuda técnica incurre en pagos de intereses, que vienen en la forma del esfuerzo adicional que tenemos que hacer en el desarrollo futuro debido a la elección de diseño rápida y sucia. Podemos elegir continuar pagando los intereses, o podemos pagar el principal refactorizando el diseño rápido y sucio en el mejor diseño. Aunque cuesta pagar el principal, ganamos con 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 adicional (cambiar cosas, agregar nuevas características, etc.). Son defectos de software.

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

Un error no es una deuda técnica. La deuda técnica está escaseando la calidad, no la ausencia de ella. El software no debe entregarse con errores en primer lugar. Ya sabes, todo el software de trabajo sobre la documentación completa.

Los mayores delincuentes de la deuda técnica son las "correcciones de errores temporales", ya sabes las que pones para pasar la prueba y que la historia sea aceptada. Las que te prometiste a ti mismo refactorizarás más tarde, pero nunca lo harás. A medida que se acumulan estos arreglos temporales, parches y otras cosas, el código se vuelve desordenado innecesario, difícil de actualizar y probar y, en general, es una pesadilla, pero aún hace su trabajo.

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

Debate técnico sobre la deuda, con Ward Cunningham y Capers Jones

Otro artículo que vale la pena leer es 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 de WyCash

Una cita del artículo anterior:

Aunque el código inmaduro puede funcionar bien y ser completamente aceptable para el cliente , las cantidades excesivas harán que un programa sea invencible, lo que conducirá a una especialización extrema de los programadores y finalmente a un producto inflexible. El código de envío por primera vez es como endeudarse.

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

Estrictamente hablando, la respuesta a su pregunta es No.

La deuda técnica puede (y probablemente lo hará) generar errores, pero concluir que cualquier error es el resultado de una deuda técnica es interpretar dos hechos: hay un error y hay una deuda técnica (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, está cortando esquinas. Si está diciendo esto sobre errores específicos que siguen apareciendo, puede que tenga razón: no podemos ver la calidad del código desde aquí ;-)

También puede tener una queja en curso sobre 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.

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

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

La deuda técnica (como se usa típicamente la etiqueta) también representa un trabajo adicional que puede ser necesario realizar 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 realmente solo una cuestión de definiciones. Y dado que no existe una definición autorizada ¹ de "deuda técnica", toda la discusión no tiene sentido.

Como Lewis Carroll escribió:

"Cuando uso una palabra", dijo Humpty Dumpty, en un tono bastante despectivo, "significa exactamente 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 significan. Las definiciones de diccionario, etc., simplemente documentan la forma en que se usan las palabras, y no son necesariamente documentación precisa. Si su Scrum Master quiere referirse a los errores conocidos como deuda técnica, ¿quién puede decir que está "equivocado"?

^{1 - Citar a personas como Ward Cummingham y Caper Jones tampoco ayuda. En el mejor de los casos, nos dice lo que significan (o quieren decir) cuando usan (usan) la frase. No "poseen" la frase. Si bien sin duda son autoridades en estos temas, esta sigue siendo solo su opinión.}