Os erros são parte da dívida técnica?

Acho que a resposta aqui é bastante simples - a principal característica da dívida técnica é que é algo que incorremos por escolha.

Optamos por tomar decisões de arquitetura, design ou implementação que esperamos que nos causem problemas mais tarde, a fim de alcançar objetivos específicos mais rapidamente.

Um bug não é algo que escolhemos ter em nosso código - então, de fato, não é uma dívida técnica.

É claro que é possível fazer todos os tipos de argumentos interessantes (e possivelmente válidos) sobre escolhas feitas após a descoberta, mas fundamentalmente (e particularmente no contexto da questão) não, bugs não são dívidas técnicas - soa mais como abuso de bingo buzzword para mim.

Como um pós-escrito - não concordo com a afirmação de que é um dado que a dívida técnica levará a bugs em si, o que faz com que muitas suposições sobre a natureza das escolhas sejam feitas. Por exemplo, você pode ter um código coberto bem testado e bem estruturado, que ainda faz - digamos - compromissos arquitetônicos para entrega antecipada. Da mesma forma, você pode optar por não automatizar seus processos de implantação, o que não resultará em bugs, mas provavelmente causará muito estresse e dor. É claro que se a dívida é que você escreveu um código que não é SOLID (ou qualquer outro), então sim ... mas isso não é sempre o caso.

Sim.

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase.

Fonte: Wikipedia

Leia a dívida técnica como algo que você poderia ter evitado ao ter um fluxo de trabalho melhor (por exemplo, fazendo arquitetura apropriadamente antes de pular para codificação, fazendo TDD etc.), melhores práticas de codificação, etc.

A maioria dos bugs poderia ter sido evitada por uma revisão adicional ou pelo uso de métodos mais formais. Ao não fazer tudo o que pode para não ter bugs em primeiro lugar, você reduz o custo imediato / curto prazo do projeto, mas aumenta a dívida técnica.

Depois de ler a resposta de BЈовић , vejo que pode não ser tão fácil quanto eu pensava.

• Por exemplo Os bugs são parte da dívida técnica? artigo alega que apenas bugs que você conhece, mas decidiu não corrigir, fazem parte da dívida técnica.

• Outro exemplo, Pensamentos de Christopher sobre a dívida técnica qualifica os bugs como o resultado da dívida técnica, não parte dela. Dito isto, muitos dos resultados listados, como "custo para implementar novo recurso", são influenciados pelo número de bugs.

• Finalmente, ao criar o modelo ABCDE-T de dívida técnica , incluí os erros como um dos seis fatores, mas eles são considerado diferentemente. O foco não está nos próprios bugs, mas nas maneiras como eles são coletados, priorizados e resolvidos. Os próprios insetos aparecem como resultado da dívida técnica (como no exemplo anterior), mas nunca aparecem como um fator de dívida técnica.

Dito isto, ainda estou inclinado a responder que os erros - quaisquer erros - fazem parte da dívida técnica.

Primeiro argumento:

Ao ler a citação de Jeff Atwood, a maioria dos bugs se qualificaria como:

the extra effort that we have to do in future development because of the quick and dirty design choice

Em aplicativos de negócios, quase todos os erros vêm de escolhas de design rápidas ou sujas ou práticas ruins (seria a falta de testes, o uso de tecnologias que os desenvolvedores não conhecem o suficiente, falta de comunicação, falta de compreensão o domínio, etc.) Isso significa que "refatorando o design rápido e sujo no melhor design" e adaptando as práticas recomendadas, as empresas poderiam resolver a maioria de seus bugs.

Segundo argumento:

Se fizermos um paralelo entre a dívida comum de uma empresa que é importante levar em conta quando uma empresa é vendida para outra, e a dívida técnica, que é igualmente importante levar em conta quando um projeto é vendido para outro empresa ou dado a outra equipe, podemos ver facilmente que os bugs fazem parte da dívida técnica, já que a nova equipe iria:

• Você precisa lidar com esses erros antes de criar novos recursos (ponto 5 do Joel Test: você conserta erros antes de escrever um novo código?)

• Ou mantenha os bugs, preservando / aumentando assim a dívida técnica.

Jeff Atwood em seu artigo Pagamento da dívida técnica dá uma boa resposta sobre o que é dívida técnica:

the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

Estritamente falando, os bugs não fazem parte da dívida técnica, se não retardarem o desenvolvimento de software (mudanças, adição de novos recursos, etc). Eles são defeitos de software.

No entanto, quando é muito caro consertar um bug, ou forçar você a contorná-lo (e introduzir ainda mais dívida técnica), ele se torna parte de uma dívida técnica.

Um bug não é dívida técnica. A dívida técnica está diminuindo a qualidade, não a ausência dela. O software não deve ser entregue com bugs em primeiro lugar. Você sabe, todo esse software funcionando sobre uma coisa abrangente de documentação.

Os maiores ofensores de dívida técnica são "correções temporárias de bugs", você sabe o que você coloca para passar no teste e aceita a história. Aqueles que você prometeu a si mesmo, refatorará mais tarde, mas nunca o fará. À medida que essas correções temporárias, patches e outras coisas se acumulam, o código se torna desnecessário e confuso, difícil de atualizar e testar e, em geral, é um pesadelo, mas ainda faz o trabalho dele.

Para apoiar esta opinião, fui direto para a fonte, Ward Cunningham. Com relação a isso, Ward fez uma boa entrevista há algum tempo com Capers Jones, vale a pena assistir.

Debate sobre a dívida técnica, com Ward Cunningham & Alcaparras Jones

Outro artigo que vale a pena ler é de Martin Fowler

Martin Fowler sobre dívida técnica

Dentro do artigo de Martin, por favor, encontre o link para a menção original da dívida técnica de Ward Cunningham, do OOPSLA92:

O sistema de gerenciamento de portfólio WyCash

Uma citação do artigo acima:

Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt.

No final, a Dívida Técnica pode ter incluído bugs para algumas pessoas, e acho que está tudo bem. Eu não acho que essa tenha sido a intenção original.

Na minha opinião, não importa se você diz que os erros fazem parte da dívida técnica ... ou não.

O fato é que bugs existentes representam trabalho extra que pode precisar ser executado no futuro, seja para corrigi-los ou para contorná-los.

A dívida técnica (como o rótulo é tipicamente usado) também representa trabalho extra que pode precisar ser realizado no futuro ... de uma forma ou de outra.

Então, se você diz que bugs conhecidos (ou desconhecidos) são dívida técnica ... ou não ... é realmente apenas uma questão de definições. E como não existe definição autoritária ¹ de "débito técnico", toda a discussão é meio que sem sentido.

Como Lewis Carroll escreveu:

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'.

Isso é realmente como funciona a linguagem natural. Palavras significam o que as pessoas pensam que elas significam. As definições de dicionário e assim por diante meramente documentam o modo como as palavras são usadas, e elas não são necessariamente documentação precisa. Se o seu Scrum Master quer referir-se a erros conhecidos como dívida técnica, quem pode dizer que ele está "errado"?

^{1 - Citar pessoas como Ward Cummingham e Caper Jones também não ajuda. Na melhor das hipóteses, nos diz o que eles significam (ou quis dizer) quando usam (usados) a frase. Eles não "possuem" a frase. Enquanto eles são, sem dúvida, autoridades sobre estas questões, esta ainda é apenas a sua opinião.}

Estritamente falando, a resposta para sua pergunta é Não.

A dívida técnica pode (e provavelmente irá) levar a bugs, mas concluir que qualquer bug é o resultado da dívida técnica está colocando uma interpretação entre dois fatos: há um bug e há detalhes técnicos dívida (assumindo que pode ser concluído como fato).

Se o seu Scrum Master está afirmando 'como uma teoria' que erros são o resultado de dívida técnica, ele está perdendo espaço. Se ele está dizendo isso sobre bugs específicos que continuam reaparecendo, ele pode estar certo - não podemos ver a qualidade do código daqui; -)

Ele também pode ter uma queixa contínua sobre pessoas que não o ouvem sobre a dívida técnica e, portanto, rotular cada bug como dívida técnica, mas agora estou especulando.