Suspensão da Descrença

Um tempo atrás, o homem, o mito, a lenda Fabrício Buzeto fez esta esta interessante pergunta:

Isso me fez lembrar algumas coisas. Por alguns anos, fui responsável pelos portlets Liferay Calendar e Kaleo Designer. Eram aplicativos complexos, construídos em ritmo acelerado quando o conceito de SPAs ainda estava em evolução: muitas escolhas exigiam uma revisão.

Então comecei a escrever tíquetes do JIRA para débitos técnicos. Quando um desses problemas tornava uma demanda mais difícil, eu convertia esse tíquete em uma subtarefa da demanda. Como gosto de dizer, eu estava “faturando o débito na feature“.

Comentei isso e então ele me fez uma pergunta crucial:

De fato, por quê?

Bem, a princípio, nós tentamos! Eu apresentava as issues de débito técnico em nossas reuniões de priorização. Ter os problemas escritos ajudou muito a chamar a atenção dos gestores, aliás.

Débito técnicos são um peixe difćil de vender, no entanto. As pessoas são compreensivelmente cautelosas ao investir em algo cujo valor não é evidente. Ainda assim, as alterações demoravam cada vez mais para serem entregues e os bugs de regressão continuavam aparecendo. Precisávamos corrigir a raiz dos problemas.

É por isso que comecei a trabalhar em débitos como parte das tarefas que agregam valor. Quando consertávamos um débito para facilitar uma demanda, ficava evidente de que o trabalho extra valia a pena. Aquela refatoração não foi apenas uma ideia aleatória: ela nos trouxe valor.

Essa é a primeira razão para lidar com débito técnico como subtarefas de outras demandas: ao vincular a dívida a uma tarefa que entrega valor, é mais fácil justificar o esforço extra para as partes interessadas.

No início, esse “faturamento de débito” era apenas um dispositivo de comunicação. Mas houve um efeito colateral interessante: os problemas mais gritantes eram naturalmente resolvidos primeiro. Faz sentido: como trabalhávamos neles quando causam problemas, os que causassem mais problemas eram resolvidos primeiro. Como priorização é sempre um desafio (e priorizar débito técnico é ainda mais difícil), isso foi muito útil!

Ainda tínhamos uma pilha de tarefas de débito, mas muitas já não eram relevantes. Algumas, já haviam sido resolvidas. Outras eram ideias elegantes no passado, mas não faziam mais sentido. Em retrospectiva, boa parte do “débito” eram preferências pessoais, ou suposições que não eram mais verdadeiras após alguma evolução do produto.

Esta é a segunda razão para o faturamento da dívida: trabalhar na “saúde do código” como parte de demandas é uma maneira eficaz de priorizar em qual débito merece o esforço.

Veja que ótimo! Tivéssemos resolvido o débito técnico sozinho — por exemplo, em uma força-tarefa —, talvez fizéssemos mudanças que poderiam, de fato, dificultar a evolução futura. A cobrança de dívidas permitiu-nos confirmar que solicitações se adequavam aos nossos objetivos. E houve uma consequência mais sutil e importante.

Nós, desenvolvedores, temos opiniões fortes, e isso é bom. Geralmente tentamos transformar essas opiniões em um objetivo. Mas é difícil saber se um objetivo é o correto. Uma vez que usamos essas ideias para ajudar em algo mais claramente relevante, esse objetivo se transforma em uma ferramenta. Ferramentas são muito mais fáceis de avaliar!

Esse é um terceiro motivo para faturar o débito: quando o débito técnico está atrelada à entrega de valor, a força criativa da equipe se alinha com os objetivos da organização.

Nossa experiência com essa estratégia foi bastante eficaz. Todos sabiam que suas sugestões seriam avaliadas: as tarefas de saúde não seriam mais uma obrigação a priorizar, mas um conjunto de ferramentas que nossos colegas buscariam para ajudar em seus desafios O backlog de débito técnico não era mais apenas um poço dos desejos.

Os aplicativos também ficaram melhores. Quando comecei a trabalhar no Calendário, por exemplo, ele era visto como um portlet especialmente problemático. O primeiro lançamento não podia agendar eventos! Quando saí daquele time, o Calendário não tinha bug de prioridade 3 ou superior (níveis que temos que corrigir). E entregamos uma boa quantidade de recursos, mesmo alguns ausentes nos líderes da concorrência. Nada mal para um produto que fora um exemplo de como não funcionar!

Por tudo isso, sempre me pareceu bom pagar o débito técnico como parte das demandas, mas nunca pensei muito sobre por que. Então, obrigado pela pergunta, Fabricio! Foi uma prazer pensar nisso.

PS: Acabei de lembrar que Ron Jeffries escreveu um excelente post sobre quando refatorar. Ele na verdade é contra algo que defendi aqui, mas vi bastante semelhanças, e naturalmente ele explica muito melhor. Vale muito a leitura!

(Esta é uma tradução de Billing the Technical Debt, um post em Suspension of Disbelief.)