Jackson Mafra discute a relação entre dívida técnica e compatibilidade retroativa no desenvolvimento de software, enfatizando que a dívida técnica resulta de decisões de design que visam soluções rápidas a curto prazo, mas que causam problemas a longo prazo. O texto sugere a importância de manter a compatibilidade retroativa para evitar complicações futuras, além de apresentar abordagens práticas para gerenciar e mitigar a dívida técnica. Conclui que a dívida técnica deve ser evitada e que decisões informadas podem prevenir problemas recorrentes no desenvolvimento de software.

1. Jackson Mafra
A eterna luta:
compatibilidade
retroativa vs. dívida
técnica

2. Desenvolvedor e Consultor WordPress
Desenvolvedor há mais de 20 anos com background em
projetos de e-commerce e mercado imobiliário, desde 2009
com interesses focados para o desenvolvimento de
interfaces móveis e aplicações corporativas.
Me chama lá...
http://about.me/jacksonfdam
http://linkedin.com/in/jacksonfdam
@jacksonfdam
Jackson Mafra

3. AGENDA
02
05
03
06
Como eles se relacionam?
Principais conclusões
O que é dívida técnica?
01
O que isso significa para o
WordPress?
04
O que é Compatibilidade
Retroativa?
Como podemos melhorar isso ?

4. Prelúdio
Uma breve introdução
00

5. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
O Mítico Homem-Mês: Ensaios Sobre Engenharia de
Software (The Mythical Man-Month: Essays on Software
Engineering)
O argumento central de O Mítico Homem-Mês é o de que
grandes projetos de programação sofrem de problemas de
gestão cuja natureza difere dos projetos pequenos em
função da divisão das tarefas; a integridade conceitual de
um produto é um fator crítico em seu desenvolvimento; e
que é difícil, mas possível, atingir tal integridade.

6. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
Seu ensaio seminal de 1986, "Não existe bala de prata"
também está aqui, complementado por um novo texto da
edição de 1995, onde Brooks afirma que "Não haverá
nenhuma bala de prata no intervalo de dez anos".
Estes dez anos já se passaram e Brooks continua atual.

7. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
Apesar de ser uma obra que teve alguma relevância no
passado a edição, mesmo atualizada, não representa nem
de perto o modelo atual de gestão.
Os exemplos utilizados tem mais de 40 anos, algumas
práticas já foram substituídas por métodos ágeis.
Talvez num contexto estritamente acadêmico e conceitual
faça sentido, mas no dia-a-dia a obra é incapaz de
endereçar os problemas de gestão em um ambiente de
transformação digital.

8. O Mítico Homem-Mês: EnsaiosSobre Engenhariade Software
Em mapas mind/mentais.

9. Torre de Pisa
Como você pode ver, esse é um monumento super
conhecido que fica na Itália, mais especificamente em
Pisa por isso o nome: Torre de Pisa.
Essa torre tem uma história super interessante, ela foi
construída no século 12 e, por motivos de o solo não ter
sustentação suficiente para aguentar seu peso, ela
começou a tombar.
A estrutura foi então estabilizada só em 2001 após 8
anos de "retrabalho".

10. Torre de Pisa
Na verdade, uma das correções feita durante o
retrabalho tornou inclinação ainda pior! Assim né, quem
aqui nunca fez uma refatoração que na real tornou o
problema pior, né? Não podemos culpar eles…
Tudo provavelmente começou com alguns erros e
problemas, mas a construtora decidiu ignorá-los e
continuou aumentando a obra em cima desses
problemas.

11. Torre de Pisa
A torre foi erguida tão rapidamente que esses pequenos
“bugs” na construção acabaram comprometendo toda a
estrutura.
E o mesmo acontecer com softwares.
A diferença é que esses bugs são mais visíveis durante
o processo de desenvolvimento, porque, depois de
algum tempo, tudo começa a ser mais difícil de entregar
até que os bugs sejam resolvidos.

12. Produto

13. Quem é responsável?
Se pensar, somos levados a pensar que isso é um problema do time de pessoas
técnicas, ou seja, de pessoas desenvolvedoras, que foram responsáveis por escrever o
código que causou tudo isso.

14. Um software é o resultado da estrutura e dos
processos da empresa inteira.

15. Quem é responsável?
Algumas vezes os gargalos e problemas vêm de diferentes partes da sua empresa.
- Time de Gerência vs Velocidade do Time de Desenvolvimento
- Time de Produto pode não ter um plano a longo prazo
- Time de UI/UX pode estar muito distante das pessoas desenvolvedoras
E também não podemos esquecer que às vezes nós precisamos nos culpar pelas má
decisões.
- Nossas má-decisões contam
- Síntomas de Frameworks
- Baixa cobertura de testes

16. O que é dívida
técnica?01
Descreve a dívida que a equipe de
desenvolvimento assume quando escolhe
um design ou abordagem fácil de
implementar no curto prazo mas com
grande impacto negativo no longo prazo.

17. O que é dívida técnica?
O que você tem no seu software é DÍVIDA TÉCNICA!
Não existe débito técnico!

18. O que é dívida técnica?
Dívida Técnica (DT) / Technical Debt (TD)
Ward Cunningan e a alegoria do empréstimo bancário
Ward Cunningham desenvolvedor da primeira wiki, criou esta metáfora chamada Debt
Metaphor.
Introduzida em um relato de experiência no OOPSLA 1992 onde o débito técnico de um
projeto é como se endividar, decisão que pode acelerar o desenvolvimento e entregas
em determinados momentos, mas que deve ser seguido de resgates e quitação.

19. O que é dívida técnica?
Sem executar os devidos refatoramentos para reduzir o endividamento, podemos
perder o controle e esta dívida não mitigada pode acumular, dívida sobre dívida,
colocando em risco todo o projeto.

20. Debt Metaphor

21. O que é dívida técnica?
Steve McConnell classificou a dívida técnica em dois tipos,
Sem querer – Desenvolvedores junior escrevem código de baixa qualidade por conta de
sua inexperiência técnica.
Intencional - A equipe faz uma decisão consciente para otimizar para o momento atual
e não para o futuro, fazendo algumas escolhas de design que podem ser uma maneira
rápida e de baixa qualidade para resolver a situação.

22. O que é dívida técnica?
Alejandro Olchik e a alegoria do Restaurante
Débito técnico equivale a um restaurante optar por ser mais “ágil” abrindo mão de
perder tempo em lavar a louça que suja na cozinha e durante o atendimento, vai chegar
uma hora em que não terá mais louça para fazer os pratos ou atender os clientes.
Se não tomar o cuidado de manter a cozinha, louça e instalações limpas, esta decisão
oportunista começará a gerar problemas de forma cumulativa e chegará uma hora em
que sua operação será paralisada porque de tanto acumular chega-se à inflexão.

23. O que é dívida técnica?
Uncle Bob, adiciona que muitas vezes um código bagunçado é considerada dívida
técnica. Mas isso está errado. Segundo ele,bagunça não é dívida técnica.
Bagunça é só bagunça.
Decisões que geram dívidas técnicas se baseiam em restrições do projeto. Elas são
arriscadas, mas podem trazer benefícios.
A decisão de fazer uma bagunça no código nunca é racional; é sempre baseada na
preguiça e na falta de profissionalismo e não têm chances de ser pagas no futuro. A
bagunça é sempre uma perda.

24. O que é dívida técnica?
Martin Fowler e seu canvas da dívida técnica
Uma canvas de mapeamento e planejamento de riscos, quando sob controle é o mesmo
canvas – Probabilidade x Impacto.
Mas Martin Fowler propõe uma nova perspectiva visual – Domínio (conhecimento
prévio) x Risco (prudência).
Fowler propôs uma canvas para diagnosticar dívida técnica que busca explicitar os
fundamentos ou explicações racionais acordadas que o originam, explicitando ser
aconteceu(rá) por pressa ou conveniência, um risco calculado ou desconhecido.

25. 4 tipos de Dívida Técnica
Irresponsável Prudente
Sem querer
Proposital
O time não tem tempo para o design e
utiliza uma solução rápida e com
pouca preocupação com a qualidade.
O time precisa entregar o produto
agora com todas as limitações
conhecidas e assume de maneira pró-
ativa as consequências.
O time não tem consciência dos
princípios básico de design e então
nem sequer imagina a bagunça que
estão adicionando.
Isso é verdade para times com
excelentes arquitetos. Eles fornecem
uma solução que agrega valor ao
negócio, mas depois de completar a
solução, eles entendem que a
abordagem de design poderia ter sido
melhor.
Confira em martinfowler.com/bliki/TechnicalDebtQuadrant.html

26. Design LinhaPayoff
Confira em martinfowler.com/bliki/DesignStaminaHypothesis.html

27. O que é
Compatibilidade
Retroativa?
Um produto que este possui compatibilidade
reversa, compatibilidade descendente ou
retrocompatibilidade quando é capaz de assumir o
lugar de um produto mais antigo, interagindo com
outros produtos que foram desenhados para
funcionar com a versão anterior
02

28. CompatibilidadeRetroativa (CR)
Interoperabilidade baseada no tempo
- Manter-se interoperável com um sistema legado mais antigo, geralmente uma versão
mais antiga de si mesmo
Quebrando mudanças
- Mudanças que quebram a cadeia de compatibilidade

29. CompatibilidadeRetroativa (CR)- É sobrea interface
Mudanças de interface são mudanças significativas (Breaking Changes)
- Você pára de cumprir o contrato que tinha com seus usuários
O código por trás das interfaces é uma caixa preta
- As mudanças de implementação estão corretas se as interfaces permanecerem
intactas

30. Por que issoé importante?
Mais fácil de desenvolver contra
- Evita a sensação de estar codificando contra um alvo em movimento
Aumenta a confiança
- As pessoas confiam no projeto por um tempo sem quebrar aleatoriamente
Ideal para usuários finais
- Migrar em uma mudança significativa requer proficiência técnica

31. Por que nem tudo é completamente CR?
Compatibilidade com versões anteriores impede a inovação
- Não há lugar para "mudança perturbadora" se as coisas precisarem permanecer as
mesmas
Compatibilidade com versões anteriores é difícil
- Cada mudança requer consideração cuidadosa e testes extensivos
Compatibilidade com versões anteriores bloqueia você do novo brilho
- Adotar mudanças importantes, não importa o quão benéfico seja, não é uma opção

32. Como eles se
relacionam?03
É inevitável que tenhamos que
decidir como chegar nos tais prazos
e essas decisões geralmente giram
em torno de sacrifícios...

33. O que queremos?
Para nossos usuários
Queremos maximizar a compatibilidade com versões anteriores
Para nossos desenvolvedores
Queremos minimizar a dívida técnica

34. CR causaDT
Mudanças se transformam em adições
Se você introduzir um novo método, você precisa manter o antigo por perto, que se
transforma em pura dívida
Exclusões se transformam em mudanças
Em vez de remover um método não utilizado, você precisa descontinuá-lo (depreciá-lo)
Bugs se transformam em recursos
Em vez de corrigir um bug, pode ser necessário documentar e mantê-lo, pois o código
de terceiros pode depender dele

35. CompatibilidadeFutura
Mudança é inevitável
Ao planejar um projeto, os requisitos devem sempre incluir a dimensão "tempo"
Antecipar necessidades futuras
Planejar com antecedência e incluir pontos de extensão necessários no futuro evita DT

36. VersãoSemântica
3.1.7
<major> . <minor> . <patch>

37. VersãoSemântica
– 3 (Major) – controle de compatibilidade. Informa que existem funcionalidades/códigos
incompatíveis com as versões anteriores.
– 1 (Minor) – controle de funcionalidade. Informa que novas funcionalidades foram
adicionadas ao código.
– 7 (Patch) – controle de correção de bugs. Informa que um ou mais erros foram
identificados e corrigidos.
– Pré-release – versão candidata. É uma versão com algumas instabilidades pois pode
ter incompatibilidades no pacote.

38. Efeito do versionamentosemântico

39. O que isso
significa para o
WordPress? 04

40. WP acumulaalgumas DT

41. WP acumulaalgumas DT

42. Asinterfaces WP não sãoexplícitas
O WordPress geralmente não define uma API estrita
Uma grande quantidade de código está disponível, e os desenvolvedores fazem uso
desse código
Interface implícita
Quando nenhuma Interface explícita é definida, todo o código se torna a interface
implícita
Conclusão:
Qualquer mudança no código é uma mudança radical

43. Os requisitos do WP estão crescendo
As necessidades de compatibilidade com versões anteriores são requisitos
Eles precisam ser levados em consideração ao discutir mudanças ou recursos de
planejamento
Escala enorme
- Base de código de 15 anos com suporte para 12 anos de versões PHP e múltiplas
iterações da linguagem JavaScript
- Todos os patches de segurança com backport em 13 versões principais

44. Conflitosde requisitos

45. O relógio está
correndo!
Cada mudança está se tornando cada vez mais cara.
Dívida técnica descontrolada eventualmente leva a
→ Falência Técnica!

46. Como podemos
melhorar isso ?05

47. Soluçõessustentáveis
I.M.P.A.C.T
O IMPACT é um processo de:
Identificar
Marcar
Planejar
Agir
Testar

48. Soluçõessustentáveis
I.M.P.A.C.T
Como podemos ver, o primeiro passo é sobre encontrar os pontos de débito dívida
técnica e, no segundo passo, precisamos ter certeza que esses pontos estão visíveis
para todo o time.
Podemos fazer isso através da criação tarefas marcadas como Débito Técnico Dívida
Técnica, por exemplo.

49. Soluçõessustentáveis
I.M.P.A.C.T
E nós também podemos escolher prioridades nessas tarefas baseados na relevância.
Ferramentas como o Jira têm mecanismos para aumentar essa prioridade de acordo
com o tempo, o que é incrível pois, como vimos anteriormente, o custo do débito técnico
da dívida técnica também aumenta ao longo o tempo.

50. Soluçõessustentáveis
Você pode encontrar informações mais detalhadas
no livro "Refactoring for Software Design Smells
Managing Technical Debt".

51. Soluçõessustentáveis
Princípio de Pareto
Para caso você não saiba quantas tarefas deve
ter a cada iteração do time.
Nós podemos usar o princípio de Pareto, no qual
20% da produtividade do time é destinada para
as tarefas de débito e o resto dos 80% pode ser
usado para tarefas normais como novos
recursos, correção de bugs e tudo mais.

52. É lucrativo?
Para este ponto, vou usar uma palestra de
J.B. Rainsberger.
Nela, Rainsberger explica o custo do
próximo novo recurso do seu software e
como você pode diminuir a incerteza de
calcular esse custo.

53. É lucrativo?
Nesse gráfico ele faz uma comparação dos dois custos ao longo do tempo do projeto.
Apesar de que a proposta de se começar pensando em design de arquitetura e tudo
mais tenha um custo bem mais alto no início, podemos ver que esse custo é mitigado ao
longo do tempo se comparado com a outra abordagem.
Ao longo do tempo o custo do próximo recurso sem se pensar em design se torna tão
grande que se a gente parasse tudo e fosse refazer tudo do zero valeria mais a pena.

54. É lucrativo?
Se você atualmente está escrevendo seu software dessa forma, você está apostando
que o projeto vai acabar antes da linha pontilhada chegar.
E a parte mais difícil disso tudo é que nós não temos idéia de quando esse momento vai
chegar, ele pode ser em 3 meses, um ano, 10 anos… Nós não sabemos.

55. Softwares de baixa qualidade tornou-se um
dos tópicos mais caros da história da
humanidade.

56. 2.84 Trilhões de Dólares
- Custo de baixa qualidade de software
CISQ divulgou um relatório sobre os custos de software nos EUA

57. Além do Lucro
Além do gasto excessivo de dinheiro e das entregas mais lentas existem várias outros
problemas que podemos identificar que são causados apenas por trabalhar com um
nível alto de débito.
O débito técnico traz muito peso às nossas vidas. Se você está constantemente lidando
com códigos problemáticos, uma tarefa que parece fácil de se concluir pode se
transformar em um verdadeiro monstro.

58. Ansiedade e Depressão
É comum ter receios em fazer mudanças, ainda mais se você é novo no projeto. As
reuniões de planejamento podem se tornar intermináveis uma vez que a equipe de
desenvolvimento precisa discutir com a equipe de gerência do projeto para explicar o
quão difícil é entregar as novas coisas agora.
Começamos a ficar ansiosos porque não sabemos se algo vai surgir com o tempo, algum
grande problema ou um bug difícil de se encontrar no meio de uma sprint.
Quem aqui nunca teve ou ainda tem algum código com algo desatualizado ou não
mantido mais?

59. Atrofiadashabilidadestécnicas
É um cenário comum para pessoas desenvolvedoras. E é bem complicado de se lidar,
porque nós precisamos aceitar todas as consequências e os problemas que vêm com
isso.
Geralmente o que acontece é que você começa a copiar e colar código de uma
biblioteca ou framework desatualizado e a corrigir os problemas você mesmo. Ou até, às
vezes, você só faz uma cópia do projeto e começa a usar o seu clone.

60. Atrofiadashabilidadestécnicas
Imagine só como deve ser difícil pra alguma pessoa desenvolvedora ser realocada no
mercado de trabalho depois de passar cinco anos em um framework javascript que não
é mais mantido e então precisa mudar para trabalhar com React ou Vue.js por exemplo.
Muitos conceitos que nós já estamos acostumados a trabalhar podem nem existir numa
ferramenta velha.

61. Crescimentoproblemático
Não faz sentido a empresa que você trabalha crescer 300% ou 400% ao ano se o seu
time não tiver saúde mental e tempo para trabalhar da melhor forma num tamanho
maior. É bem comum esse cenário em startups que glamourizam horas excessivas
trabalhadas por alguma meta irreal. Aquele pico de vendas do produto no meio da noite
em que você precisou acordar pra levantar algum serviço da aplicação que caiu pela
quantidade de acessos.
Em um mundo realista e respeitável, as máquinas deveriam tomar conta dessas
situações ao invés de colocar toda a pressão nas pessoas envolvidas.

62. Principais
conclusões 06
Concluindo o que
concluímos.

63. Dívida Técnica
deve ser evitada

64. Dívida Técnica
precisa ser "paga"

65. Compatibilidade Retroativa
deve ser mantida

66. Compatibilidade Retroativa
cría dívida técnica

67. Apenas Breaking Changes
podem reduzir substancialmente
Dívida Técnica

68. → reduz Dívida Técnica
→ reduz mudanças significativas
Compatibilidade Futura

69. Pense antes de codificar!
porque cada erro torna seu futuro trabalho mais difícil

70. Depois de conversar sobre tudo isso.
A Torre de Pisa está sustentável.

71. Na real essa é uma das raras situações
onde um bug vira feature :)

72. Palestra inspiradaem uma palestra de AlainSchlesser
Alain Schlesser.
@schlessera
www.alainschlesser.com
Software Engineer
- @WPCLI Maintainer
- @WordPress Core Contributor
- @GoogleDevExpert in Web
Technologies

73. Obrigado!
Qualquer dúvida, crítica ou sugestão só me
procurar:
@jacksonfdam
jacksonfdam@gmail.com

74. CRÉDITOS
É aqui que você dá crédito a quem faz parte deste projeto.
Gostou dos recursos deste modelo? Obtenha-os gratuitamente em nossos outros sites.
◂ Presentation template by Slidesgo
◂ Icons by Flaticon
◂ Infographics by Freepik
◂ Images created by Freepik - Freepik
◂ Author introduction slide photo created by Freepik
◂ Text & Image slide photo created by Freepik.com