Download as PDF, PPTX
Managing Technical Debt
- 1. Managing Technical Debt First Round Capital CTO Summit @sampullara Friday, December 7, 12
- 2. Startup CompanyMy background in a 2x2 Consumer Enterprise Friday, December 7, 12
- 3. Startup CompanyMy background in a 2x2 Consumer Enterprise Friday, December 7, 12
- 4. What is technicaldebt? "As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it." — Meir Manny Lehman, 1980 Ward Cunningham first coined the term Some debt you choose to incur, other debt happens through entropy, lastly you start in the hole Like normal debt, it usually must be repaid with interest or you go bankrupt Friday, December 7, 12
- 5. Common Technical Debts Developer Backup & disaster effectiveness recovery Observability Fault tolerance Scalability Security Architectural Backward flexibility compatibility Friday, December 7, 12
- 6. Developer effectiveness How long does it take to get a change to master? Then to production? Are you reviewing the code that is going into your codebase? Do you have extensive unit and integration test coverage? Are you closely tracking your dependencies? Friday, December 7, 12
- 7. Observability Do you produce and capture enough logs to reconstruct failures? Do you track runtime metrics and compare them every release to watch for regressions? Do you have an alerting system in place to notify you if things fail or are going to fail? Do you have redundant monitoring? Friday, December 7, 12
- 8. Scalability How far into the future, at the current growth rate, will your architecture work? Have you identified what the next bottleneck will be? Do you have time bombs in your data model? Does anything scale above linear with your business? Friday, December 7, 12
- 9. Fault tolerance /Backup / DR Do you have any single points of failure? If one of your SPFs fails, how long until you can be serving traffic again? Are you dependent on caching to serve normal traffic? Could a software bug destroy data permanently? How long would it take to notice data corruption? Friday, December 7, 12
- 10. Architectural Flexibility How often do you decide that a feature doesn’t fit into your current architecture? Is it easy to support backwards compatibility without compromising features? How long would it take to add a new field to one of the entities in your system? How difficult would it be to change hosting environments? To add another environment? Friday, December 7, 12
- 11.
- 12. High-interest debt: Security How do you store customer credentials? Does your system naturally defend against XSS attacks and other well known exploits? Do you limit access to production systems? Do you systematically install software updates on your servers? Does everyone at your company use two-factor authentication on Google Apps, AWS & Dropbox? Friday, December 7, 12
- 13.
- 14. 53-bit ints injavascript In HTML instead of data Text dates Never released to GA Friday, December 7, 12
- 15. Same data wrong order Data duplicated in this link Friday, December 7, 12
- 16. Choosing to takeon debt Great APIs rather than tight coupling and magic Sufficient testing to ensure that rewrites are successful Track your assumptions and borrowing Measure the impact of the debt Schedule time for refactoring and clean up Friday, December 7, 12
- 17. Conclusion Taking on technical debt is a manageable risk Measure and monitor for best results Leave time in the schedule just to make things better Friday, December 7, 12