Learning to Fail

Transcript

1. Learning to Fail Friday, October 5, 2012
2. Open source software to improve the lives of people living in poverty. Friday, October 5, 2012
3. — Friday, October 5, 2012
4. Africa 1 billion people 500 million phones Friday, October 5, 2012
5. 25 Botswana 26 Zwaziland 18 South Africa 24 Lesotho Africa People hardest hit by HIV/AIDS are also those least likely to have access to relevant information. Friday, October 5, 2012
6. Friday, October 5, 2012
7. FAIL Friday, October 5, 2012
8. Hindsight is a luxury. Friday, October 5, 2012
9. 5 years of growing pains. Friday, October 5, 2012
10. 0 6 12 18 24 30 36 Patients Not Returning Before After Friday, October 5, 2012
11. How hard can it be? Friday, October 5, 2012
12. Deceptively simple. Lack of ownership. Being too clever. Friday, October 5, 2012
13. What is it we’re building? Friday, October 5, 2012
14. Friday, October 5, 2012
15. One hammer to rule them all. Friday, October 5, 2012
16. Hit scaling issues hard & fast. Friday, October 5, 2012
17. Commitment issues. Friday, October 5, 2012
18. 800,000+ Uniques Friday, October 5, 2012
19. 0 25000 50000 75000 100000 June 2010 October 2010 May July Sept Nov Friday, October 5, 2012
20. Architecture prevented efficient caching. Friday, October 5, 2012
21. Metrics killed the site. Friday, October 5, 2012
22. Mild tunnel vision. Slight frameworkitis. Friday, October 5, 2012
23. Everything breaks at scale. Friday, October 5, 2012
24. Team Culture Implications Friday, October 5, 2012
25. You reproduce what you are. Friday, October 5, 2012
26. “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations” – Melvin Conway Friday, October 5, 2012
27. A software system will reflect the social structure of the organization that produced it. Friday, October 5, 2012
28. Failures are to be expected. Friday, October 5, 2012
29. Focus on small teams, few organizational layers. Friday, October 5, 2012
30. Introduce small changes. Minimize risk. Friday, October 5, 2012
31. Ship all the time. Friday, October 5, 2012
32. Avoid organizational silos, reduce bus factors. Friday, October 5, 2012
33. Trust, Cooperation & Transparency. Friday, October 5, 2012
34. Emphasize learning, code reviews & shared responsibility Friday, October 5, 2012
35. Team communication tools are vital. Friday, October 5, 2012
36. Kill your darlings. Embrace change. Friday, October 5, 2012
37. Broken gets fixed but shitty lasts forever. Friday, October 5, 2012
38. Technical Implications Friday, October 5, 2012
39. Queue everything and delight everyone. Friday, October 5, 2012
40. Automate everything. Friday, October 5, 2012
41. Continuous Integration Friday, October 5, 2012
42. Code reviews. Friday, October 5, 2012
43. Make deploys easy. Friday, October 5, 2012
44. Metrics should be cheap. Friday, October 5, 2012
45. Failing adds value. Friday, October 5, 2012
46. Thanks. Friday, October 5, 2012
47. Thanks. Friday, October 5, 2012
48. @smn http://github.com/praekelt Friday, October 5, 2012