Software Design and Technical Debts
0 likes281 views
The document discusses technical debt in software design, comparing it to financial debt and emphasizing the extra effort required for future development due to rushed design choices. It highlights the importance of simplicity and best practices in coding, such as avoiding duplication and maintaining clear intentions in code. Additionally, it notes the challenges of balancing quality with speed in software development and the need for effective problem-solving strategies.
Software Design and Technical Debts
- 1. Software Design and “Technical Debts”
- 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
- 9. Schedule pressure Trade-off By design Lack of knowledge Laziness; Unprofessionalism Techinical Debt Design Flaw Mess Software Structural Problems
- 13. Cost of Change
- 15. Tracking
- 16. Monetize
- 17. Schedule pressure Trade-off By design Lack of knowledge Laziness Unprofessionalism Techinical Debt Design Flaw Mess Software Structural Problems
- 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
- 31. Dependencies
- 32. Personas
- 33. Inputs/Outputs
- 34. Solution
- 36. SOC
- 38. SOLID
- 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
- 54. Expertise
- 55. THANKS!