Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Wandering Through Software
Similar to Wandering Through Software (20)
Recently uploaded
Recently uploaded (20)
Wandering Through Software
- 1. Wandering Through Software How to benefit from changing requirements and unpredictability
- 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
- 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
- 24. Robust
- 26. How do we help our agile process improve when things are mishandled?
- 27. Process depends on people
- 29. How do we handle uncertainty as individuals?
- 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
- 44. Redundancy in the human body
- 45. Redundancy seems like a waste if nothing unusual happens
- 47. “I don’t expect a problem with this code, it’s pretty straightforward.” “We could be more productive if we didn’t write unit tests.” “I hope I didn’t break something.”
- 48. The flaneur relies on redundancy
- 49. “I know my code works.” <boredom> “Should we write this test, too? It’s just gonna pass.” </boredom>
- 51. 75% of software projects encounter effort and/or schedule overruns
- 52. “More planning!”
- 53. Planning Fallacy
- 54. We can’t estimate risk and randomness
- 55. We can estimate fragility
- 56. Nonlinearity
- 58. An estimate error of 5 days has 5x the impact of an estimate error of 1 day
- 60. A quality error 10x greater than a small error hurts you more than 10 small errors
- 61. Quality is more fragile than budget… focus on the most fragile part of the process
- 62. Design vs. Creating in Context “The craftsmen had done further, deeper thinking about light than the designers.”
- 63. “Like our endless quest to explain the origins of things, we’re prone to seeking magic in beginnings… It’s this desire that leads otherwise bright minds to research Michael Jordan’s breakfast, da Vinci’s or Einstein’s napping habits, or Linus Torvalds’ chosen style of underwear.” - Scott Berkun, The Myths of Innovation
- 64. “It doesn’t matter where you start, as long as you start.”
- 65. The tourist estimates and designs outcomes… and is usually wrong
- 66. “Let’s get better with our estimates.” “Let’s 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.”
- 67. The flaneur estimates fragility… and limits exposure to nonlinearity
- 68. “What’s the next story?” “Can we break this up into smaller, less complex pieces?” “What requirements do we not understand?” “What’s the simplest way to solve this problem?”
- 70. Optionality You don’t have to be right that often
- 71. Changes in Value Time Small Errors Big Discovery
- 72. Negative Knowledge Knowing what doesn’t work is more effective than trying to figure out what does work
- 73. Are our retros just check-ins along the map?
- 74. 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
- 75. 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
- 76. The tourist stays on the bus
- 77. “But we committed to doing it this way.” “I’ve already spent too much time on this code to delete it.” “Let’s just keep going and see if it gets better.”
- 78. The flaneur takes the path that makes future change easier
- 79. “That class isn’t very extensible, let’s 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.”
- 80. Policy making
- 82. Top-down policies and actions in which: benefits are small and visible side effects potentially severe and invisible
- 83. 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.”
- 84. Top-down is hard to reverse, mistakes tend to stick Bottom-up is noisy, gradual, and incremental
- 85. Top down code policies and metrics Visible Benefits Metrics improve Defined course of action for most events Tests for all acceptance criteria
- 86. Top down code policies and metrics Side Effects Rule beating? Policy resistance, disengagement? Tests outside the acceptance criteria?
- 87. The tourist intervenes from the top-down
- 88. “It’s just the way we do it.” “Look at the data, things are going great!” “We can’t change now, there would be too much overhead.”
- 89. The flaneur organizes from the bottom up
- 90. “@%#!$%!” “Let’s change our process now that we’ve picked up our pace.” “Thanks for the feedback. You were right, I should have paid closer attention to my code.”
- 91. How to Wander ● Redundancy ● Non-prediction ● Non-intervention ● Optionality
- 93. “The best way to verify that you are alive is by checking if you like variations.”
- 94. Are you a wanderer or a tourist?
- 96. 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