Talking about what is a technical debt (and what it isn't) . Some techniques and practises to deal with the technical debts.

1. Software Design
and “Technical Debts”

2. “TECHNICAL DEBT”

4. “With borrowed money you can do something sooner than
you might otherwise, but then until you pay back that money
you'll be paying interest.”
-- Ward Cunningham
“Like a financial debt, the technical debt incurs interest
payments, which come in the form of the extra effort that
we have to do in future development because of the quick
and dirty design choice.”
-- Martin Fowler

5. “A Mess is not a Technical Debt!”
-- Robert C. Martin

6. SOFTWARE QUALITY
WHAT IS WRONG WITH

7. The distance ...

8. Structural Problem/Defect

9. Schedule pressure
Trade-off
By design
Lack of knowledge
Laziness;
Unprofessionalism
Techinical Debt Design Flaw Mess
Software Structural Problems

11. Development speed
Predictability
Customer satisfaction

13. Cost of Change

14. VIOLATIONS MONETIZE

15. Tracking

16. Monetize

17. Schedule pressure
Trade-off
By design
Lack of knowledge
Laziness
Unprofessionalism
Techinical Debt Design Flaw Mess
Software Structural Problems

18. HOW
AND
WHEN
Repayment Plan

19. Budgeting

20. Schedule pressure
Trade-off
By design
Lack of knowledge
Laziness
Unprofessionalism
Techinical Debt Design Flaw Mess
Software Structural Problems

25. Schedule pressure
Trade-off
By design
Lack of knowledge
Laziness
Unprofessionalism
Techinical Debt Design Flaw Mess
Software Structural Problems

27. If I had an hour to solve a problem, I’d spend 55 minutes
thinking about the problem and 5 minutes thinking about
solutions.
Problem (Context)

29. Requirements

30. Information (Nature)

31. Dependencies

32. Personas

33. Inputs/Outputs

34. Solution

36. SOC

38. SOLID

39. Package Principles

40. Algorithm

42. Compositions

43. Design Patterns

45. 1. Runs all the tests;
2 . Has no duplicated logic. Be wary of hidden duplication
like parallel class hierarchies;
3. States every intention important to the
programmer;
4. Has the fewest possible classes and methods.
Simplicity Rules

46. 1. Passes the tests;
2. Reveals intention;
3. No duplication;
4. Fewest elements.
Simplicity Rules

48. WAY
OF
CHANGE

49. Rigidity, Fragility, Immobility,
Viscosity, Opacity,
Nedless Complexity,
Needless Repetition

50. Design Session

51. Just Enough

52. Who asked knows what was asked
I know what was asked
The constraints are known
Definition of done

53. Conceptual integrity
Constraints
Technology choices
SoC
Simplicity Rules

54. Expertise

55. THANKS!

56. Rafael Souza
rafaelsouza.eng.br
rafael_psouza
rafaelpsouza