wandering through software

Download Wandering Through Software

Post on 30-Jul-2015




0 download

Embed Size (px)


1. Wandering Through Software How to benefit from changing requirements and unpredictability 2. Name this country. 3. 26 autonomous regions 4. 4 official languages 5. Any citizen may challenge any law at any time 6. New president every year 7. How does this sound? 8. Switzerland 9. Stable Over Time 98th percentile in Government Effectiveness and Political Stability 10. Benefits from Volatility Never invaded or attacked during either WW GDP rose 5% each year following WWII 11. Switzerland is Agile 12. Switzerland is Agile local autonomy 13. Switzerland is Agile local autonomy self-organizing teams 14. Switzerland is Agile local autonomy empowered citizens self-organizing teams 15. Switzerland is Agile local autonomy empowered citizens self-organizing teams continuous integration 16. Switzerland is Agile local autonomy empowered citizens 1 year presidents self-organizing teams continuous integration 17. Switzerland is Agile local autonomy empowered citizens 1 year presidents self-organizing teams continuous integration short iterations 18. Switzerland is Agile local autonomy empowered citizens 1 year presidents 4 languages self-organizing teams continuous integration short iterations 19. Switzerland is Agile local autonomy empowered citizens 1 year presidents 4 languages self-organizing teams continuous integration short iterations collaboration 20. Little central planning Loose political process Plenty small conflicts at local level No large conflicts at the system level Little harm, large benefits from political volatility Switzerland 21. Little upfront planning Loosely defined processes Plenty small changes at each iteration No large changes at the end of the project Little harm, large benefits from changing requirements Agile 22. Opposite of Fragile 23. Fragile HANDLE WITH CARE 24. Robust 25. Opposite of Fragile PLEASE MISHANDLE 26. How do we help our agile process improve when things are mishandled? 27. Process depends on people 28. Uncertainty Avoidance Russia: 95 Switzerland: 58 29. How do we handle uncertainty as individuals? 30. Tourist vs Flaneur 31. Tourist vs Flaneur predicted path unpredictable path 32. Tourist vs Flaneur predicted path hard-to-revise plan unpredictable path opportunistic 33. Tourist vs Flaneur predicted path hard-to-revise plan no options unpredictable path opportunistic many options 34. Process Time 35. Process Time 36. Tourist vs Flaneur Gets worse with randomness Gets better with randomness 37. How to be a software flaneur 38. Key Activities Testing Iteration and Refactoring Estimation and Design Policy making 39. Testing 40. Why do we write tests? 41. Redundancy 42. Redundancy is aggressive 43. Redundancy in the human body 44. Redundancy seems like a waste if nothing unusual happens 45. The tourist optimizes 46. I dont expect a problem with this code, its pretty straightforward. We could be more productive if we didnt write unit tests. I hope I didnt break something. 47. The flaneur relies on redundancy 48. I know my code works. Should we write this test, too? Its just gonna pass. 49. Estimation and Design 50. 75% of software projects encounter effort and/or schedule overruns 51. More planning! 52. Planning Fallacy 53. We cant estimate risk and randomness 54. We can estimate fragility 55. Nonlinearity 56. Estimate Error Impact Error 57. An estimate error of 5 days has 5x the impact of an estimate error of 1 day 58. Quality Error Impact Error 59. A quality error 10x greater than a small error hurts you more than 10 small errors 60. Quality is more fragile than budget focus on the most fragile part of the process 61. Design vs. Creating in Context The craftsmen had done further, deeper thinking about light than the designers. 62. Like our endless quest to explain the origins of things, were prone to seeking magic in beginnings Its this desire that leads otherwise bright minds to research Michael Jordans breakfast, da Vincis or Einsteins napping habits, or Linus Torvalds chosen style of underwear. - Scott Berkun, The Myths of Innovation 63. It doesnt matter where you start, as long as you start. 64. The tourist estimates and designs outcomes and is usually wrong 65. Lets get better with our estimates. Lets put this on hold until we get the design right. We completed 40 points last week, so we should be able to do 40 points this week. 66. The flaneur estimates fragility and limits exposure to nonlinearity 67. Whats the next story? Can we break this up into smaller, less complex pieces? What requirements do we not understand? Whats the simplest way to solve this problem? 68. Iteration and Refactoring 69. Optionality You dont have to be right that often 70. Changes in Value Time Small Errors Big Discovery 71. Negative Knowledge Knowing what doesnt work is more effective than trying to figure out what does work 72. Are our retros just check-ins along the map? 73. Negative Knowledge in Refactoring When you find that yesterday's decision doesn't make sense today, you change the decision. Now you can do today's work. Tomorrow, some of your understanding as of today will seem naive, so you'll change that, too. - Kent Beck 74. Unplanned Refactoring as Optionality In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts. You don't decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing. - Martin Fowler 75. The tourist stays on the bus 76. But we committed to doing it this way. Ive already spent too much time on this code to delete it. Lets just keep going and see if it gets better. 77. The flaneur takes the path that makes future change easier 78. That class isnt very extensible, lets refactor it while we implement this feature. I think we should start over on this story. This code is rigid, and I know how to improve it based on my mistakes so far. 79. Policy making 80. Intervention Bias Iatrogenics 81. Top-down policies and actions in which: benefits are small and visible side effects potentially severe and invisible 82. Self-Organization ... is such a common property, particularly of living systems, that we take it for granted. ... often sacrificed for purposes of short-term productivity and stability. ... requires freedom and experimentation, and a certain amount of disorder. 83. Top-down is hard to reverse, mistakes tend to stick Bottom-up is noisy, gradual, and incremental 84. Top down code policies and metrics Visible Benefits Metrics improve Defined course of action for most events Tests for all acceptance criteria 85. Top down code policies and metrics Side Effects Rule beating? Policy resistance, disengagement? Tests outside the acceptance criteria? 86. The tourist intervenes from the top-down 87. Its just the way we do it. Look at the data, things are going great! We cant change now, there would be too much overhead. 88. The flaneur organizes from the bottom up 89. @%#!$%! Lets change our process now that weve picked up our pace. Thanks for the feedback. You were right, I should have paid closer attention to my code. 90. How to Wander Redundancy Non-prediction Non-intervention Optionality 91. Wandering is Good 92. The best way to verify that you are alive is by checking if you like variations. 93. Are you a wanderer or a tourist? 94. Thank You Kevin Buchanan @kevinbuch_ kbuchanan@8thlight.com 95. References Nassim Nicholas Taleb. Antifragile: Things that Gain from Disorder Kent Beck. Ease at Work. http://www.infoq.com/presentations/self-image Robert C. Martin. Agile Software Development: Principles, Patterns, and Practices Daniel Kahneman. Thinking Fast and Slow Matthew Stewart. The Management Myth: Why the Experts Keep Getting it Wrong Donnella Meadows. Thinking in Systems Richard Sennet. The Craftsman