StartupProduto
Tech Debt — Divida Tecnica
O que e divida tecnica, tipos (inadvertida, deliberada, rotten code), Tech Debt Quadrant de Martin Fowler e como gerenciar no backlog.
O que e?
Tech Debt (divida tecnica) e o custo de manutencao futura gerado por atalhos tecnicos tomados no presente. Assim como divida financeira, a divida tecnica acumula "juros" — quanto mais tempo sem pagar, mais caro fica.
O termo foi cunhado por Ward Cunningham em 1992:
"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring."
Divida tecnica nao e sempre ruim. As vezes, assumir divida deliberadamente faz sentido — desde que voce saiba que esta fazendo e planeje pagar.
Como funciona
Tech Debt Quadrant (Martin Fowler)
Martin Fowler classificou a divida tecnica em 4 quadrantes:
Deliberada Inadvertida
┌──────────────────┬──────────────────┐
Prudente │ "Sabemos que │ "Agora que │
│ nao e ideal, │ terminamos, │
│ mas precisamos │ percebemos como │
│ lancar agora" │ deveriamos ter │
│ │ feito" │
├──────────────────┼──────────────────┤
Imprudente │ "Nao temos tempo │ "O que sao │
│ para design" │ design patterns?" │
│ │ │
└──────────────────┴──────────────────┘
Prudente + Deliberada = Aceitavel (pague rapido)
Prudente + Inadvertida = Natural (refatore ao aprender)
Imprudente + Deliberada = Perigosa (corte de corners consciente)
Imprudente + Inadvertida = Toxica (falta de competencia)Tipos comuns de Tech Debt
| Tipo | Descricao | Exemplo |
|---|---|---|
| Code debt | Codigo mal estruturado, duplicado | Copy-paste de logica em 5 lugares |
| Architecture debt | Decisoes arquiteturais que nao escalam | Monolito que precisaria ser microsservicos |
| Test debt | Falta de testes automatizados | 0% de cobertura em modulo critico |
| Documentation debt | Falta de documentacao | Ninguem sabe como o sistema de pagamento funciona |
| Infrastructure debt | Infra defasada | Servidor com Ubuntu 16.04 sem suporte |
| Dependency debt | Libs desatualizadas | React 16 quando o ecossistema migrou para 18+ |
Sinais de Tech Debt acumulada
Sintomas:
├── Features simples demoram semanas para implementar
├── Bugs corrigidos reaparecem em outros lugares
├── Novos devs levam meses para serem produtivos
├── "So funciona na maquina do Joao"
├── Medo de mudar codigo — "nao mexe que esta funcionando"
├── Deploy manual com checklist de 47 passos
└── Incidents frequentes em producaoComo gerenciar no backlog
Estrategia 1: Regra dos 20%
├── Reserve 20% da capacidade do sprint para tech debt
├── Exemplo: sprint de 40 pts → 8 pts para tech debt
└── Negociavel conforme urgencia do negocio
Estrategia 2: Boy Scout Rule
├── "Deixe o codigo melhor do que encontrou"
├── Pequenas melhorias em cada PR
└── Nao precisa de ticket — faz parte da cultura
Estrategia 3: Tech Debt Sprints
├── 1 sprint inteiro dedicado a tech debt a cada 4-6 sprints
├── Util para refatoracoes grandes
└── Requer buy-in do Product Owner
Estrategia 4: Tech Debt Score
├── Classifique cada item de tech debt por impacto e esforco
├── Priorize junto com features no backlog
└── Use o mesmo framework RICE/ICEPor que importa?
Gerenciar tech debt e fundamental porque:
- Velocidade de desenvolvimento — tech debt alta torna tudo mais lento
- Qualidade — codigo fragil gera mais bugs e incidents
- Moral do time — devs se frustram com codigo legacy
- Custo de contratacao — ninguem quer trabalhar em codebase ruim
- Risco de negocio — em casos extremos, tech debt pode inviabilizar o produto
O paradoxo: startups que ignoram tech debt para "ir mais rapido" acabam indo mais devagar a medio prazo.
Exemplo pratico
Auditoria de Tech Debt de um SaaS
INVENTARIO DE TECH DEBT
ID | Item | Tipo | Impacto | Esforco | Score
-----|--------------------------------|---------------|---------|---------|------
TD-1 | Migrar de REST para GraphQL | Architecture | Alto | 13 pts | 5/10
TD-2 | Adicionar testes no checkout | Test | Critico | 8 pts | 9/10
TD-3 | Atualizar Node 16 → 20 | Dependency | Medio | 5 pts | 7/10
TD-4 | Remover codigo morto (40%) | Code | Medio | 3 pts | 6/10
TD-5 | Documentar API interna | Documentation | Baixo | 5 pts | 4/10
TD-6 | CI/CD: pipeline leva 45 min | Infrastructure| Alto | 8 pts | 8/10
Priorizacao:
1. TD-2 (score 9) → Checkout sem testes = risco de receita
2. TD-6 (score 8) → Pipeline lenta = devs improdutivos
3. TD-3 (score 7) → Node 16 perde suporte em 3 meses
4. TD-4 (score 6) → Codigo morto confunde novos devs
5. TD-1 (score 5) → Valido, mas grande — planejar para Q3
6. TD-5 (score 4) → Importante, mas nao urgente
Plano: TD-2 e TD-6 entram no proximo sprint (16 pts).
Restante no backlog com revisao mensal.Termos relacionados
- Sprint — onde a tech debt e gerenciada e paga
- Backlog — onde itens de tech debt sao priorizados junto com features
- Feature Flag — pode gerar tech debt se flags antigas nao forem removidas