Muito se fala por ai em Débito Técnico. Se você ainda não ouviu falar disso, não faça mais nada hoje até entender esse conceito.
A idéia é que quando é tomada uma decisão técnica que não é adequada ao software ou ao ambiente onde a produção do software se insere (equipa, tecnologias, etc…) isso gera uma dívida, um débito. Essa dívida gera juros. Ou seja, à medida que o tempo passa a dívida vai ficando maior. Esta metáfora é excelente para passar a idéia que um erro gera prejuízo e demanda para ser corrigido.
Algumas pessoas com o Robert Martin acham que existe uma diferença entre débito técnico e código porco , que código porco é simplesmente uma porcaria e débito técnico diz respeito a trade-offs infelizes (escolhas infelizes). Eu não concordo com isto. Dívida é dívida. Um trade-off não é necessariamente uma dívida e uma divida não nasce necessariamente de um trade-off. O Martin Fowller resume isto melhor ao introduzir a noção de tipos de débito e a tecnica dos quadrantes.
Até aqui nada de novo. Sabemos que o débito técnico é ruim e que não devemos introduzi-lo. O Martin Fowler adora este papo que produtividade não pode ser medida mas qualquer um que tenha feito mais do que um sprint na vida sabe que isso é mentira. Sim, não existe uma equação matemática ou unidade para a produtividade, mas olhando para vários burdown charts do projeto e de vários projetos você consegue ver onde a produtividade aumentou. Aliás fala-se até no estado hiper-produtivo (em que o fator de foco é maior que 100% ). Então, produtividade pode não ser medida, mas isso não nos inibe de a avaliar e reconhecer quando ela aumenta e diminui. Se você fica mais de um mês trabalhando na mesma funcionalidade isso é sinal de baixa produtividade.
Várias coisas convergem para criar débito tecnico. Não seguir boas práticas, não fazer código limpo, não usar formas de peer-review como pair-programing, não discutir problemas e soluções entre toda a equipa e assim vai… Mas se você ou sua equipa já estão no buraco com a água no pescoço introduzir essas práticas não vai ajudar a diminuir o débito.
Introduzir boas práticas e outros mecanismos de qualidade após a dívida existir não ajuda a pagá-la, apenas a não aumentar o juro. Para matar a divida o erro original tem que ser corrigido, junto com todos os outros feitos em cima desse com todas as suas derivações. E isto não é fácil.
A maior parte das vezes é simples. Uma refactoração maior ou menor e voilá. Contudo não é fácil. Vários fatores conspiram para isso. Primeiro o mais comum: falta de compreensão da gerencia e outros stakeholders. Se o carro deles faz um barulho estranho não exitam em mandá-lo para a oficina, mas se os desenvolvedores pedem tempo para arranjar o software os gerentes acham que estão sendo roubados -mais ou menos o que eles sentem quando pegam o carro na oficina de volta. A diferença é que eles viajam no carro e se o barulho for sinônimo de desastre e acidente isso é ruim para a vida deles, mas os defeitos do software não são perigosos para a sua vida, portanto não ha pressa. A pressa é “agradar ao cliente” (leia-se : agradar ao diretor que quer faturar).
O segundo entrave é a equipa em si mesma. Se a equipa é estática – ou seja, seus membros não mudam, primeiro a equipa não vê onde errou e segundo não vê como resolver o problema. Afinal isso implica numa maturação da equipa. Se a equipa muda temos o problema inverso. O novo membro demorará para ver os problemas ou mesmo que os detecte no primeiro dia demorará para convencer a equipa de que ha um debito técnico ali. Mesmo depois de todo o mundo saber que ha um debito técnico ainda tem que haver vontade para o pagar.
O problema do débito técnico é que o crédito técnico é difícil e raro. O código é um agiota. Qualquer mínima divida resultará em juros astronômicos que não poderão ser pagos em tempo útil. A diferença é que um agiota quebra as suas pernas, o código agiota quebra as pernas do seu cliente, o seu software e a sua credibilidade.
Incluir crédito técnico não pode ser uma operação pára-tudo. Os problemas devem ser analisados até chegar numa solução. Essa solução deve ser partida em várias partes independentes de forma que cada alteração possa ser feita atomicamente e delimitadamente. A equipa vai incluindo uma alteração destas a cada sprint.
Às vezes a escolha tem que ser entre ter um débito técnico com juro alto para um débito de juro baixo. É como você contrair uma dívida para pagar outra. Desde que o juro seja mais baixo é uma boa opção,mas se você comete o erro de contrair uma divida de juro maior, você não só não resolveu o problema , tornou-o pior. É o juro que afunda o projeto, não o débito principal em si mesmo.
Incluir crédito técnico é muito complexo e não é fácil. É necessário uma conjetura de fatores para que a equipa possa realizar o crédito, mas tem que ser obvio na cabeça de todos os profissionais que inserir crédito técnico é uma necessidade e que só é possível introduzi-lo aos poucos.
Post excelente, confesso que estava por fora desse assunto e os links que adicionou completaram bem seu ponto de vista. Parabéns.
Sergio,
Não entendi muito bem oq vc quis dizer com o termo “Crédito Técnico”. Levando em consideração que Débito Técnico ocorre quando alguma coisa é planejada de forma errada e/ou é feita por pessoas sem conhecimento técnico o suficiente para projetar um software estável (que dependendo do ponto de vista não podem sequer serem considerados juniors), eu assumo que o crédito técnico seria a união de todos essas coisas de um maneira inversa, como por exemplo, uma boa arquitetura, programadores capacitados e experientes, etc.
Ao contrário de vc, eu concordo com a opinião do Robert Martin. Tudo bem que Débito Técnico (como próprio nome diz) é um débito. Porém, código porco ou bagunçado não quer dizer que não funcione, e infelizmente, ele pode até funcionar. O problema é de quem tiver que fazer alguma coisa com esse código no futuro como adicionar uma funcionalidade ao sistema (coisa que pode não ocorrer). Fora isso eu tenho a mesma opinião que vc.
Parabéns pelo post.
Acho que vc entendeu corretamente.
O estado de funcionamento não influencia o debito. Aliás, esse é o problema. O software funciona para quem o usa, mas é uma desgraça para quem o modifica. O R.C Martin veja a palavra “técnico” ao pé da letra e portanto debito técnico seria uma falha exclusivamente técnica, ou seja, escolher o framework errado, a api errada, etc.. Eu não considero assim. A palavra “técnico” significa “dos técnicos” e nesse sentido toda a falta de cuidado e esmero do desenvolvedor em todos os niveis (arquitetura, design, codigo , documentação…) é debito técnico.
Sergio,
Não entendi muito bem oq vc quis dizer com o termo “Crédito Técnico”. Levando em consideração que Débito Técnico ocorre quando alguma coisa é planejada de forma errada e/ou é feita por pessoas sem conhecimento técnico o suficiente para projetar um software estável (que dependendo do ponto de vista não podem sequer serem considerados juniors), eu assumo que o crédito técnico seria a união de todos essas coisas de um maneira inversa, como por exemplo, uma boa arquitetura, programadores capacitados e experientes, etc.
Ao contrário de vc, eu concordo com a opinião do Robert Martin. Tudo bem que Débito Técnico (como próprio nome diz) é um débito. Porém, código porco ou bagunçado não quer dizer que não funcione, e infelizmente, ele pode até funcionar. O problema é de quem tiver que fazer alguma coisa com esse código no futuro como adicionar uma funcionalidade ao sistema (coisa que pode não ocorrer). Fora isso eu tenho a mesma opinião que vc.
Parabéns pelo post.
Michelle,
Débito Técnico não nasce apenas de profissionais sem experiencia. Infelizmente ele nasce principalmente dos que têm experiência. Quem é novato ainda acredita que é possivel construir o software perfeito (aliás, muitos entram com esse objetivo). Essa crença é mutilada quando os novatos assistem ao mais maduros cometer atrocidades ou quando sofrem a pressão das gerências. No caso, aqui, a pressão não gera diamantes, apenas carvão. Débito Técnico é toda e qualquer dívida que existe para com o software. Acontece sempre que o software sofre por causa de alguma escolha do desenvolvedor. Algumas são por incompetência tecnica , algumas são por escolhas erradas (o lado errado do trade-off foi escolhido) e outras acontecem simplesmente porque a equipa não tem como saber que está fazendo algo errado. Por exemplo, em 2000 usar o struts 1 era normal e considerado “bom”. Hoje é considerado um anti-pattern. Este é um exemplo de um Débito Técnico que poderia ter sido evitado se os envolvidos tivessem mais experiencia, mas não podemos dizer que foi uma escolha errada ( na época parecia certa a muita boa gente).
Portanto, Crédito Tecnico é sempre que você tira um tempinho para curar o software dos males que o assombram. É como podar uma arvore. Vc precisa fisicamente ferir a arvore, mas vc faz isso consciente de que isso irá melhorar a sua saude. O Crédito Tecnico é realmente o oposto do Débito Tecnico, como bem concluio, e é quase sempre esquecido.
O ponto do artigo é mostrar que o maior problema do Débito Tecnico é o juro que ele gera e portanto o custo que estáo sendo gerado apenas por deixar as coisas como estão. O Crédito Tecnico é a ação de diminuir esse juro de forma a diminuir o custo. Em particular essa ação pode ser feita à priori de forma a que o saldo seja positivo desde o começo do projeto.