O débito técnico nunca será pago
No dinamismo do mercado, sempre somos cobrados por resultados e entregas — nunca por qualidade de código ou manutenabilidade. Isso não dá dinheiro para a empresa.
O produto precisa ter "cara" e funcionar. No fim, o que importa é apenas isso: funcionar.
Nós, desenvolvedores com conhecimento profundo do sistema e das regras de negócio, sabemos quando estamos gerando um débito técnico. Alguns avisam, outros seguem em silêncio. Mas, em reuniões e dailys, se você aponta isso, muitas vezes é mal visto — como se não tivesse pensado na solução ideal. Se você demora um pouco mais para pensar em algo com qualidade, vai ter que se explicar na daily.
Isso é uma faca de dois gumes.
Semana passada vi um post sobre um desenvolvedor que queria escrever testes e a empresa não permitiu — por falta de tempo. A realidade é: muitas empresas pequenas e médias não têm recursos para investir em testes, manutenibilidade e muito menos documentação.
A única coisa possível, às vezes, é deixar um #, // ou /**/ com um comentário no código. Alguns nem isso fazem. Preferem escrever uma função com camelCase do tamanho de uma frase como "resolveCasoQuandoUsuarioTemMaisDeUmaOpcaoSelecionada".
O meu ponto é:
Estou há mais de 10 anos na área, já passei por muitos freelancers e empresas de todos os portes: pequenas, médias e grandes.
As únicas que se preocuparam com qualidade foram as grandes, porque têm recursos para isso:
Elas tem dinheiro para: PO, QA, Tech Lead, Tech Manager, Frontend, Backend, Scrum Master...
Seguem Kanban, Sprints, cerimônias, escopo e demanda bem definidos.
Como ter isso numa empresa com apenas 2 ou 3 devs e vários clientes demandando novas features e correções? impossível.
Essa é a realidade do mercado.
Qual a sua opinião?
Como é na sua empresa?
Meus 2 cents,
Automacao, automacao, automacao.
Tem um artigo (infelizmente perdi o link, mas acho que foi no medium) que li onde o autor simula uma startup completa com o time de scrum/agile substituidos por agentes de IA.
Funciona 100% - claro que nao, mas funciona bem o bastante.
Tem o video do @lucasmontano de hoje falando um pouco sobre isso - o agente IA fazendo certas tarefas de PR.
Nao eh sobre substituir um DEV (jr/pl/sr) - mas delegar tarefas repetitivas que nao exijam imaginacao para um agente de IA.
https://www.youtube.com/watch?v=CbVy0JdUreM
Enfim, uma empresa pequena precisaria investir energia nisso - e eh ai que a porca torce o rabo: se a empresa ja nao tem este tipo de coisa (QA,etc...) e toca o barco assim mesmo, porque cargas d'agua vai investir grana e tempo nisso ? Simplesmente nao ve retorno neste tipo de investimento.
EXEMPLO DA VIDA REAL: Teve uma empresa que conheci que o registro de chamados (tickets) era feito por telefone e anotados por uma secretaria !!! O dono simplesmente nao via valor em fazer um sistema online (na epoca). Acabaram colocando - mas porque conseguiram um de graca e o team leader implantou quando o dono estava de ferias. Como ja estava funcionando, quando ele voltou - nao gostou muito, mas deixou. E isso faz pouco tempo, nao eh uma historia do seculo passado ! Empresa pequena - mas o dono ja comprou aptos, sitios e troca de carro com frequencia. Pois eh...
Outros artigos sobre o assunto:
https://prakash-raman.medium.com/rom-v-meet-your-new-scrum-team-member-an-ai-agent-4cbdb4e1b838
Na minha opinião isso é falta de um time de tecnologia forte. Provavelmente a galera de tec não tem força suficiente pra convencer a area de produto ou não se importa muito com isso também.
Pensa comigo, se você é médico tem a responsabilidade de dizer para o paciente o status da saúde dele e convencer ele a fazer exames/tratamento, certo? O mesmo serve para nós, não é só sair programando, temos que mostrar o que está errado e que precisamos corrigir, e impor isso.
Resolver débito técnico é uma responsabilidade exclusiva do time de tec, não de quem é de produto, o PO/PM nunca vai se importar com isso.
Mas como vc disse, uma empresa de 2 ou 3 devs dificilmente vai conseguir lutar contra a maré e a area de produto fica mais forte que a de tec
Coincidência (ou não), publicaram sobre automação de code review hoje:
E o mais interessante é ser uma empresa brasileira que esta a frente do projeto.
Parabéns e sucesso para eles !
Passei também mais de uma década zanzando por essa área de tecnologia, e até trabalehi um tempo para uma big tech com escritório em Mountain View. A qualidade lá importava, sim. Mas não por um ideal nobre de engenharia ou por amor ao código limpo. Importava porque alguém calculou que, no longo prazo, era mais barato. Alguém botou numa planilha que cada hora gasta em teste economizava dez horas de correção de bugs. Era uma decisão puramente econômica.
A virada de chave, a epifania que mudou tudo, não veio de lá. Veio quando troquei o mundo do software pelo mundo da engenharia. De verdade. Coisas que, se falharem, não geram um ticket no Jira, mas um inquérito judicial e investigação policial Aqui o conceito de "dívida técnica" muda de figura e simplesmente se torna inaceitável. Enquanto nosso ofício for tocado por "desenvolvedores", a dívida técnica vai crescer. No dia em que ele passar a ser dominado por "engenheiros de software", com a responsabilidade que a palavra "engenheiro" carrega, a coisa muda.
Software precisa ser tratado como uma disciplina de engenharia. Ponto. Como a civil, a mecânica, a elétrica. Até que nossa área seja regulada, até que tenhamos que assinar embaixo do que produzimos, a dívida vai continuar crescendo. Pense nisto, uma analogia simples: para levantar um prédio, ou mesmo uma casa, você precisa submeter o projeto estrutural e arquitetônico para a prefeitura. Um engenheiro civil assina, assume a responsabilidade técnica e um servidor público avalia se o projeto segue os mínimos padrões de qualidade. A verdadeira pergunta, que vale mais do que qualquer, é: por que não fazemos o mesmo com o software que hoje sustenta o mundo?
Como é que chama.... Go horse? 🐴
Nunca falha, nao é mesmo?