# O que é a dívida técnica e porque destrói projetos que pareciam sólidos Source: https://baqueiro.es/pt/ingenieria-sin-atajos/o-que-e-divida-tecnica-destroi-projetos/ Published: 2025-06-18T08:07:00+00:00 Updated: 2025-06-18T08:07:00+00:00 Author: Baqueiro Desarrollo Web Language: pt-PT Usage: Attribution required: quoting allowed with a visible link back --- **TL;DR** - A dívida técnica são os atalhos que se tomam hoje e se pagam depois, com juros. - Não aparece em nenhum balanço: cresce em silêncio até o sistema começar a ranger. - Acumula-se por prazos apertados, falta de documentação, mudanças de programador e excesso de plugins. - Vista de fora é difícil de detetar; a forma mais fiável de a apanhar a tempo é uma revisão técnica independente. Há uma metáfora no desenvolvimento de software que descreve com precisão algo que acontece em quase todos os projetos web: a dívida técnica. Foi criada pelo programador Ward Cunningham no início dos anos 90, e continua a ser a melhor forma de explicar este problema a quem não programa. A ideia é simples. Tomas um atalho: uma solução rápida que funciona agora, mas que não é a melhor maneira de resolver o problema. Nesse momento contrais uma dívida. Tal como uma dívida financeira, essa decisão tem um custo diferido. Não o pagas hoje. Pagas depois, com juros. O problema é que a dívida técnica não aparece em nenhum balanço. Não gera alertas nem tem uma data de vencimento visível. Cresce sozinha, em silêncio, até o sistema começar a ranger e ninguém perceber porquê. ## Como se acumula sem que ninguém o decida A dívida técnica raramente é o resultado de uma decisão consciente de fazer as coisas mal. Quase sempre se acumula por razões que, na altura, pareciam sensatas. O prazo aperta e é preciso entregar. Escolhe-se a solução que funciona agora, com a intenção de a melhorar depois. Esse depois nunca chega, porque o projeto seguinte já está à espera. O programador que construiu uma parte do sistema já não está, e não deixou nada escrito. O novo não percebe as decisões que foram tomadas, por isso constrói por cima sem mexer no que existe. Alterá-lo implica um risco e um tempo que não estão no orçamento. Instala-se um plugin para resolver algo depressa. Funciona. Instalam-se mais 5. Cada um acrescenta a sua própria camada de lógica, as suas atualizações e os seus possíveis conflitos, e quase nunca se [revê um plugin antes de o instalar](https://baqueiro.es/pt/ingenieria-sin-atajos/como-auditar-plugin-wordpress-pt/). O sistema cresce em complexidade sem que ninguém o tenha planeado. Nenhuma destas decisões, por si só, é um desastre. O desastre chega quando se acumulam durante meses ou anos sem que ninguém faça limpeza. ## As 3 formas como a dívida técnica destrói um projeto A dívida técnica não destrói os projetos de uma vez. Desgasta-os. Ao início é incómoda. Com o tempo, torna-se bloqueante. **Primeiro, abranda o desenvolvimento.** Quanto mais dívida tem um projeto, mais tempo demora qualquer alteração. O que devia ser uma alteração de 2 horas transforma-se numa investigação de 2 dias. Ninguém percebe totalmente como o sistema está construído e cada decisão pode ter consequências imprevistas. Os orçamentos disparam, os prazos alargam-se e o cliente fica frustrado sem perceber porque é que algo simples demora tanto. **Depois, multiplica os erros.** Num sistema com muita dívida técnica, os erros têm uma característica particular: corrigir um gera outro. O código está tão entrelaçado que é difícil mexer em algo sem que isso tenha efeito noutra parte. Os erros em produção tornam-se mais frequentes e as atualizações deixam de ser melhorias de rotina para passarem a ser operações de risco. **Por fim, bloqueia o crescimento.** Chega-se a um ponto em que acrescentar funcionalidades novas sobre uma base com muita dívida técnica é mais caro do que refazer tudo de raiz. O projeto que começou bem torna-se uma armadilha: demasiado caro de manter, demasiado arriscado de alterar e demasiado emaranhado para o passar a outro programador sem semanas de análise. É nesse momento que o cliente descobre que o investimento que fez há 3 anos já não admite melhorias graduais. É preciso começar de novo. E essa conversa é sempre difícil. ## Porque é tão difícil de detetar de fora Se a dívida técnica fosse visível, seria fácil de gerir. O problema é que, visto de fora, um projeto com muita dívida pode parecer perfeitamente saudável. O site funciona. As páginas carregam. Os formulários enviam. O cliente atualiza conteúdos sem problemas. Tudo parece em ordem. O que não se vê a partir do painel de administração é a qualidade do código que sustenta tudo isso. Se está estruturado para crescer sem atritos ou se é um castelo de cartas que aguenta enquanto ninguém lhe mexer. Se os plugins instalados são os mínimos necessários ou uma acumulação de soluções parciais que interagem de formas que ninguém controla. Ainda assim, há sinais que qualquer pessoa pode notar sem ler uma linha de código: - Cada pequena alteração demora mais e custa mais do que a anterior. - As atualizações vão sendo adiadas “não vá partir alguma coisa”. - Só uma pessoa se atreve a mexer em certas partes do sistema. - Os mesmos erros voltam a aparecer depois de cada correção. - Ninguém sabe explicar para que serve metade dos plugins instalados. Se reconheces 2 ou 3 destes sinais, é provável que haja dívida acumulada. Para saber quanta e onde, a forma mais fiável é uma revisão técnica feita por alguém com critério suficiente para avaliar não só se o sistema funciona, mas como está construído e o que implica mantê-lo e fazê-lo crescer. ## A diferença entre dívida técnica inevitável e evitável Nem toda a dívida técnica é igual, e perceber a diferença muda a forma de a gerir. **Há dívida técnica inevitável.** Todos os projetos tomam decisões com informação incompleta. O que hoje parece a melhor solução pode não o ser daqui a 2 anos, quando o negócio tiver mudado, tiverem surgido ferramentas novas ou o volume de dados for 10 vezes maior. Essa dívida é o custo normal de construir software em condições reais. Gere-se com revisões periódicas que modernizem o sistema de forma controlada. **E há dívida técnica evitável.** A que nasce de não fazer as perguntas certas no início. De escolher a solução mais rápida sem pensar no custo a longo prazo. De trabalhar com fornecedores que otimizam para entregar depressa e não para o que vem depois, que é exatamente o que explica [o custo real de um site barato](https://baqueiro.es/pt/ingenieria-sin-atajos/custo-real-de-um-site-barato/). Essa dívida não é inevitável. É uma escolha, ainda que nem sempre consciente. A diferença importa porque determina o que se pode fazer com ela. A dívida inevitável gere-se. A evitável previne-se, e para isso é preciso que alguém no projeto faça as perguntas difíceis desde o início. ## O que distingue um programador que pensa a longo prazo Um programador que trabalha a pensar no longo prazo toma decisões diferentes das de quem só otimiza para entregar depressa. Não instala um plugin quando pode escrever 50 linhas de código que resolvem exatamente o problema sem acrescentar dependências. Não copia uma solução de um tutorial sem perceber o que ela implica no contexto concreto do projeto. E não entrega sem documentar, porque sabe que quem vier depois (ou ele próprio daqui a 6 meses) vai precisar de perceber o que foi construído e porquê. É para isso que serve [documentar as decisões técnicas](https://baqueiro.es/pt/ingenieria-sin-atajos/como-documentar-decisoes-tecnicas/), e não só o código. Essas decisões levam mais tempo a curto prazo e às vezes são difíceis de justificar num orçamento apertado. Mas são exatamente as que determinam se um projeto continua a ser fácil de manter e de escalar daqui a 3 anos ou se se transforma numa bomba-relógio. A dívida técnica não é um problema técnico. É um problema de critério. E o critério [não se compra à hora](https://baqueiro.es/pt/la-sala-de-maquinas/parceiro-tecnico-vs-fornecedor-horas/): reconhece-se na forma como alguém toma decisões quando ninguém está a ver. Na Baqueiro construímos a pensar na próxima entrega, não só no prazo de hoje. Se o teu projeto tem sintomas de dívida técnica acumulada (desenvolvimento cada vez mais lento, erros frequentes, orçamentos que disparam), [conta-nos o que se passa](https://baqueiro.es/pt/contacto/): fazemos uma revisão e dizemos-te com clareza o que vemos.