Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing Technical Debt

Presentation given by Sam Pullara to the First Round Capital CTO Summit in October 2012.

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Managing Technical Debt

  1. Managing Technical Debt First Round Capital CTO Summit @sampullaraFriday, December 7, 12
  2. Startup CompanyMy background in a 2x2 Consumer EnterpriseFriday, December 7, 12
  3. Startup CompanyMy background in a 2x2 Consumer EnterpriseFriday, December 7, 12
  4. What is technical debt? "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 bankruptFriday, December 7, 12
  5. Common Technical Debts Developer Backup & disaster effectiveness recovery Observability Fault tolerance Scalability Security Architectural Backward flexibility compatibilityFriday, 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. Friday, December 7, 12
  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. Friday, December 7, 12
  14. 53-bit ints in javascript In HTML instead of data Text dates Never released to GAFriday, December 7, 12
  15. Same data wrong order Data duplicated in this linkFriday, December 7, 12
  16. Choosing to take on 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 upFriday, 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 betterFriday, December 7, 12