Learning to Fail

Transcript

1. Learning to Fail Friday, January 27, 2012

2. Open source software to improve the lives of people living

   in poverty. Friday, January 27, 2012

3. — Friday, January 27, 2012

4. Africa 1 billion people 500 million phones Friday, January 27,

   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, January 27, 2012

6. Friday, January 27, 2012

7. FAIL Friday, January 27, 2012

8. Hindsight is a luxury. Friday, January 27, 2012

9. 5 years of growing pains. Friday, January 27, 2012

10. 0 6 12 18 24 30 36 Patients Not Returning

    Before After Friday, January 27, 2012

11. How hard can it be? Friday, January 27, 2012

12. Deceptively simple. Lack of ownership. Being too clever. Friday, January

    27, 2012

13. What is it we’re building? Friday, January 27, 2012

14. Friday, January 27, 2012

15. One hammer to rule them all. Friday, January 27, 2012

16. Hit scaling issues hard & fast. Friday, January 27, 2012

17. Commitment issues. Friday, January 27, 2012

18. 800,000+ Uniques Friday, January 27, 2012

19. 0 25000 50000 75000 100000 June 2010 October 2010 May

    July Sept Nov Friday, January 27, 2012

20. Architecture prevented efficient caching. Friday, January 27, 2012

21. Metrics killed the site. Friday, January 27, 2012

22. Mild tunnel vision. Slight frameworkitis. Friday, January 27, 2012

23. Everything breaks at scale. Friday, January 27, 2012

24. Team Culture Implications Friday, January 27, 2012

25. You reproduce what you are. Friday, January 27, 2012

26. “Organizations which design systems are constrained to produce designs which

    are copies of the communication structures of these organizations” – Melvin Conway Friday, January 27, 2012

27. A software system will reflect the social structure of the

    organization that produced it. Friday, January 27, 2012

28. Failures are to be expected. Friday, January 27, 2012

29. Focus on small teams, few organizational layers. Friday, January 27,

    2012

30. Introduce small changes. Minimize risk. Friday, January 27, 2012

31. Ship all the time. Friday, January 27, 2012

32. Avoid organizational silos, reduce bus factors. Friday, January 27, 2012

33. Trust, Cooperation & Transparency. Friday, January 27, 2012

34. Emphasize learning, code reviews & shared responsibility Friday, January 27,

    2012

35. Team communication tools are vital. Friday, January 27, 2012

36. Kill your darlings. Embrace change. Friday, January 27, 2012

37. Broken gets fixed but shitty lasts forever. Friday, January 27,

    2012

38. Technical Implications Friday, January 27, 2012

39. Queue everything and delight everyone. Friday, January 27, 2012

40. Automate everything. Friday, January 27, 2012

41. Continuous Integration Friday, January 27, 2012

42. Code reviews. Friday, January 27, 2012

43. Make deploys easy. Friday, January 27, 2012

44. Metrics should be cheap. Friday, January 27, 2012

45. Failing adds value. Friday, January 27, 2012

46. Thanks. Friday, January 27, 2012

47. Thanks. Friday, January 27, 2012

48. @smn http://github.com/praekelt Friday, January 27, 2012