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

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 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 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. 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 GA
Friday, December 7, 12

15. Same data
wrong order
Data duplicated
in this link
Friday, 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 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