Managing your technical debt - AgileBrazil 2011

1,642 views
1,556 views

Published on

Slides from my talk on Managing Technical Debt at AgileBrazil 2011 in Fortaleza

1 Comment
13 Likes
Statistics
Notes
No Downloads
Views
Total views
1,642
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
1
Likes
13
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • Imagine the app is a perfect brick tower block\nTechnical debt, is the bricks that are stacked slightly weirdly, at an angle, not perfectly placed\nThe more debt you accumulate, the more likely your tower becomes unstable and you have to fix it before building on height alone\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 1992 OOPSLA\n
  • 1992 OOPSLA\n
  • 1992 OOPSLA\n
  • 1992 OOPSLA\n
  • Outras metáforas financeiras:\n* deficit\n* inflação técnica\n* “caixa 2”\n
  • Exemplos?\nToo expensive to pay => replace (not in scope of this talk)\n
  • Exemplos?\nToo expensive to pay => replace (not in scope of this talk)\n
  • Exemplos?\nToo expensive to pay => replace (not in scope of this talk)\n
  • Exemplos?\nToo expensive to pay => replace (not in scope of this talk)\n
  • Jim Highsmith? Martin? Ward\nÉ o que previne você de ir tão rápido quanto você poderia\n
  • * Acúmulo\n* Mais difícil de pagar com o tempo\n* Afeta entrega de valor\n* Síndrome da versão 5\n
  • * Acúmulo\n* Mais difícil de pagar com o tempo\n* Afeta entrega de valor\n* Síndrome da versão 5\n
  • * Acúmulo\n* Mais difícil de pagar com o tempo\n* Afeta entrega de valor\n* Síndrome da versão 5\n
  • * Acúmulo\n* Mais difícil de pagar com o tempo\n* Afeta entrega de valor\n* Síndrome da versão 5\n
  • Israel Gat\n* Sempre começa com pouco / decisões pobres\n* Ninguém escreve código ruim de propósito\n* ctrl+c / ctrl+v\nUm pouco não faz mal\nPergunta: “Como gerenciar?”\n
  • Israel Gat\n* Sempre começa com pouco / decisões pobres\n* Ninguém escreve código ruim de propósito\n* ctrl+c / ctrl+v\nUm pouco não faz mal\nPergunta: “Como gerenciar?”\n
  • Israel Gat\n* Sempre começa com pouco / decisões pobres\n* Ninguém escreve código ruim de propósito\n* ctrl+c / ctrl+v\nUm pouco não faz mal\nPergunta: “Como gerenciar?”\n
  • Israel Gat\n* Sempre começa com pouco / decisões pobres\n* Ninguém escreve código ruim de propósito\n* ctrl+c / ctrl+v\nUm pouco não faz mal\nPergunta: “Como gerenciar?”\n
  • Israel Gat\n* Sempre começa com pouco / decisões pobres\n* Ninguém escreve código ruim de propósito\n* ctrl+c / ctrl+v\nUm pouco não faz mal\nPergunta: “Como gerenciar?”\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • * Cobertura de código\n* duplicação\n* tamanho vs. complexidade\n* “churn”\n* acoplamento\n
  • * Cobertura de código\n* duplicação\n* tamanho vs. complexidade\n* “churn”\n* acoplamento\n
  • \n
  • * Falhas comuns\n* Tempo de build\n* Testes ignorados/pendentes\n* Bugs\n
  • QA + Tech Lead + dev + arquitects\n
  • Root cause analysis (5 whys? post mortems; bug analysis; relatório de incidentes)\n
  • \n
  • \n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • PLANEJAMENTO:\n* priorização\n* comece a pagar a dívida!\n
  • \n
  • Buffer por iteração\nKanban => limite o número de cartões de dívida técnica em progresso\n
  • Buffer por iteração\nKanban => limite o número de cartões de dívida técnica em progresso\n
  • Buffer por iteração\nKanban => limite o número de cartões de dívida técnica em progresso\n
  • * enfatize os pay-offs\n
  • * enfatize os pay-offs\n
  • * enfatize os pay-offs\n
  • * enfatize os pay-offs\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • Exemplo\n
  • \n
  • \n
  • \n
  • Managing your technical debt - AgileBrazil 2011

    1. 1. GERENCIANDO SUA DÍVIDA TÉCNICA DANILO SATO - @DTSATO THOUGHTWORKS
    2. 2. INTRODUÇÃO
    3. 3. VISÍVEL INVISÍVEL+ VALOR- VALOR
    4. 4. VISÍVEL INVISÍVEL+ VALOR FUNCIONALIDADE- VALOR
    5. 5. VISÍVEL INVISÍVEL+ VALOR FUNCIONALIDADE ARQUITETURA- VALOR
    6. 6. VISÍVEL INVISÍVEL+ VALOR FUNCIONALIDADE ARQUITETURA- VALOR BUGS
    7. 7. VISÍVEL INVISÍVEL+ VALOR FUNCIONALIDADE ARQUITETURA- VALOR BUGS DÍVIDA TÉCNICA
    8. 8. “SHIPPING FIRST TIME CODE IS LIKEGOING INTO DEBT.”
    9. 9. “SHIPPING FIRST TIME CODE IS LIKEGOING INTO DEBT.” “A LITTLE DEBT SPEEDS DEVELOPMENT SO LONG AS IT IS PAID BACK PROMPTLY”
    10. 10. “SHIPPING FIRST TIME CODE IS LIKEGOING INTO DEBT.” “A LITTLE DEBT SPEEDS DEVELOPMENT SO LONG AS IT IS PAID BACK PROMPTLY”“THE DANGER OCCURS WHEN THEDEBT IS NOT REPAID”
    11. 11. “SHIPPING FIRST TIME CODE IS LIKEGOING INTO DEBT.” “A LITTLE DEBT SPEEDS DEVELOPMENT SO LONG AS IT IS PAID BACK PROMPTLY”“THE DANGER OCCURS WHEN THEDEBT IS NOT REPAID” “EVERY MINUTE SPENT ON NOT-QUITE-RIGHT CODE COUNTS AS INTEREST ON THAT DEBT”
    12. 12. DÍVIDA OU DÉBITO?
    13. 13. SEM DEQUERER PROPÓSITO IMPRUDENTE PRUDENTE
    14. 14. IMPRUDENTE PRUDENTEQUERER PROPÓSITO “NÃO TEMOS TEMPO DE PARA FAZER DESIGN” SEM
    15. 15. IMPRUDENTE PRUDENTEQUERER PROPÓSITO “PRECISAMOS ENTREGAR “NÃO TEMOS TEMPO DE E LIDAR COM AS PARA FAZER DESIGN” CONSEQUEÊNCIAS” SEM
    16. 16. IMPRUDENTE PRUDENTEQUERER PROPÓSITO “PRECISAMOS ENTREGAR “NÃO TEMOS TEMPO DE E LIDAR COM AS PARA FAZER DESIGN” CONSEQUEÊNCIAS” SEM “O QUE SÃO CAMADAS?”
    17. 17. IMPRUDENTE PRUDENTEQUERER PROPÓSITO “PRECISAMOS ENTREGAR “NÃO TEMOS TEMPO DE E LIDAR COM AS PARA FAZER DESIGN” CONSEQUEÊNCIAS” SEM “AGORA SABEMOS COMO “O QUE SÃO CAMADAS?” DEVERIA TER SIDO FEITO”
    18. 18. “DÍVIDA TÉCNICA É O QUEPREVINE VOCÊ DE IR TÃO RÁPIDO QUANTO VOCÊ PODERIA”
    19. 19. CUSTO DA MUDANÇA POR QUE É RUIM? CUSTO ÓTIMO TEMPO
    20. 20. CUSTO DA MUDANÇA POR QUE É RUIM? CUSTO REAL DÍVIDA TÉCNICA CUSTO ÓTIMO TEMPO
    21. 21. CUSTO DA MUDANÇA POR QUE É RUIM? CUSTO REAL DÍVIDA TÉCNICA CUSTO ÓTIMO TEMPO RELEASE
    22. 22. POR QUE É RUIM? RESPONSIVIDADE AO MERCADOCUSTO DA MUDANÇA CUSTO REAL DÍVIDA TÉCNICA CUSTO ÓTIMO TEMPO RELEASE
    23. 23. POR QUE ACONTECE? PRESSÃO
    24. 24. POR QUE ACONTECE? PRESSÃO DÍVIDA TÉCNICA
    25. 25. POR QUE ACONTECE? PRESSÃO DÍVIDA TÉCNICA NÃO PAGAR DÍVIDA
    26. 26. POR QUE ACONTECE? PRESSÃO DÍVIDA TÉCNICA DÍVIDA NÃO PAGAR ACUMULA DÍVIDA
    27. 27. POR QUE ACONTECE? PRESSÃO DIMINUI DÍVIDA TÉCNICAPRODUTIVIDADE DÍVIDA NÃO PAGAR ACUMULA DÍVIDA
    28. 28. POR QUE ACONTECE? PRESSÃO DIMINUI DÍVIDA TÉCNICAPRODUTIVIDADE DÍVIDA NÃO PAGAR ACUMULA DÍVIDA
    29. 29. COMO IDENTIFICAR?
    30. 30. MÚLTIPLAS DIMENSÕES
    31. 31. MÚLTIPLAS DIMENSÕES CÓDIGO
    32. 32. MÚLTIPLAS DIMENSÕES CÓDIGO TESTES
    33. 33. MÚLTIPLAS DIMENSÕES CÓDIGO TESTES INFRA-ESTRUTURA
    34. 34. MÚLTIPLAS DIMENSÕES CÓDIGO TESTES NFR INFRA-ESTRUTURA
    35. 35. MÚLTIPLAS DIMENSÕES CÓDIGOARQUITETURA TESTES NFR INFRA-ESTRUTURA
    36. 36. MÉTRICAS DE QUALIDADE
    37. 37. MÉTRICAS DE QUALIDADE
    38. 38. MÉTRICAS DE QUALIDADE
    39. 39. SEU CÓDIGO FALA// TO DO: REFACTOR THIS// FIX ME: THIS SHOULD NOT BEDUPLICATED// WTF! HAZARD! ALERT /!// DO NOT TOUCH!!!
    40. 40. TESTES
    41. 41. EQUIPERETROSPECTIVA TÉCNICA“ON-DEMAND”CONTADOR DE HISTÓRIAS
    42. 42. DEMANDA POR FALHABUGSOPSSUPORTEUSUÁRIOS
    43. 43. PROCESSO DE DEPLOYPASSOS MANUAISLOG DE PROBLEMAS POR DEPLOYMIGRAÇÃO DE DADOSPROCESSOS LONGOS
    44. 44. O QUE FAZER?
    45. 45. ESFORÇO DOR
    46. 46. ESFORÇO DOR
    47. 47. ONDE COMEÇAR?GANHOS RÁPIDOSDESIGN ESTRATÉGICOÁREAS QUE SÃO FREQUENTEMENTE ALTERADASCAUSAS COMUNS DE PROBLEMAS
    48. 48. MAS COMO EXPLICAR?
    49. 49. MAS COMO EXPLICAR?COMUNIQUE O VALOR E NÃO OS DETALHES TÉCNICOS
    50. 50. MAS COMO EXPLICAR?COMUNIQUE O VALOR E NÃO OS DETALHES TÉCNICOSNEGOCIE UM POUCO DA CAPACIDADE PARA PAGAMENTODA DÍVIDA
    51. 51. MAS COMO EXPLICAR?COMUNIQUE O VALOR E NÃO OS DETALHES TÉCNICOSNEGOCIE UM POUCO DA CAPACIDADE PARA PAGAMENTODA DÍVIDAADICIONE OS “JUROS” NAS ESTIMATIVAS FUTURAS
    52. 52. TRACKING
    53. 53. TRACKING✗ ✗ ✗ ✗
    54. 54. RATCHET
    55. 55. TRACKING
    56. 56. TRACKING bjet ivos O em as T arce las P
    57. 57. TRACKING bjet ivos✔ ✔ ✔ ✔ O em as✔ ✔ ✔ ✔ ✔ ✔ T✔ ✔ ✔ ✔ ✔ arce las P✔ ✔ ✔ ✔✔
    58. 58. EVITANDO O ACÚMULO
    59. 59. REFATORE SEMPRETDD (RED-GREEN-REFACTOR)CADA COMMIT DEIXA O CÓDIGO UM POUCO MELHORREFATORE QUANDO MEXER EM ÁREAS RUINSREFATORE SEUS TESTES
    60. 60. DESIGN “EM PROGRESSO”USE NOMES FEIOSABORDAGEM INCREMENTALPODE PIORAR TEMPORARIAMENTE
    61. 61. UMA HISTÓRIA APP
    62. 62. UMA HISTÓRIA APPSVC
    63. 63. UMA HISTÓRIA APPSVC
    64. 64. UMA HISTÓRIA APPSVC
    65. 65. A VERDADE APP MODEL VIEW CONTROLLER
    66. 66. A VERDADE APP MODEL VIEW CONTROLLER HELPER
    67. 67. A VERDADE APP MODEL VIEWSVC CONTROLLER HELPER
    68. 68. A VERDADE APP MODEL VIEWSVC CONTROLLER VAI QUEBRAR TUDO !!! HELPER
    69. 69. ARQUITETURA DE TRANSIÇÃO APP MODEL VIEW CONTROLLER SVC HELPER
    70. 70. ARQUITETURA DE TRANSIÇÃO APP MODEL VIEW CONTROLLER SVC HELPER
    71. 71. ARQUITETURA DE TRANSIÇÃO APP MODEL VIEW CONTROLLER SVC HELPER
    72. 72. ARQUITETURA DE TRANSIÇÃO APP MODEL VIEW CONTROLLER SVC HELPER
    73. 73. ARQUITETURA DE TRANSIÇÃO APP MODEL VIEW CONTROLLER SVC HELPER
    74. 74. ARQUITETURA DE TRANSIÇÃO APP MODEL VIEW CONTROLLER SVC HELPER
    75. 75. RESUMOO QUE É DÍVIDA TÉCNICA?POR QUE É RUIM E POR QUE ACONTECE?COMO IDENTIFICAR?FORMAS DE PLANEJAR E COMUNICAR O PAGAMENTO DADÍVIDAFORMAS DE EVITAR O ACÚMULO
    76. 76. CRÉDITOS / REFERÊNCIASMARTIN FOWLER: TECHNICAL DEBT QUADRANTPHILIP KRUCHTEN: MANAGING TECHNICAL DEBT IN SOFTWARE-RELIANT SYSTEMS HARD CHOICES GAMEJIM HIGHSMITH: THE FINANCIAL IMPLICATIONS OF TECHNICAL DEBTSTEVE MCCONNELL: NOTES ON TECHNICAL DEBTAARON ERICKSON: DON’T “ENRON” YOUR SOFTWARE PROJECTFLICKR: HTTP://WWW.FLICKR.COM/PHOTOS/ALANCLEAVER/4105722502/IN/PHOTOSTREAM/
    77. 77. GERENCIANDO SUA DÍVIDA TÉCNICA DANILO SATO - @DTSATO THOUGHTWORKS

    ×