Download - Wandering Through Software
Wandering Through SoftwareHow to benefit from changing requirements
and unpredictability
Name this country….
26 autonomous regions
4 official languages
Any citizen may challenge any law at any time
New president every year
How does this sound?
Switzerland
Stable Over Time
98th percentile in Government Effectiveness and Political Stability
Benefits from Volatility
Never invaded or attacked during either WW
GDP rose 5% each year following WWII
Switzerland is Agile
Switzerland is Agile
local autonomy
Switzerland is Agile
local autonomy self-organizing teams
Switzerland is Agile
local autonomy
empowered citizens
self-organizing teams
Switzerland is Agile
local autonomy
empowered citizens
self-organizing teams
continuous integration
Switzerland is Agile
local autonomy
empowered citizens
1 year presidents
self-organizing teams
continuous integration
Switzerland is Agile
local autonomy
empowered citizens
1 year presidents
self-organizing teams
continuous integration
short iterations
Switzerland is Agile
local autonomy
empowered citizens
1 year presidents
4 languages
self-organizing teams
continuous integration
short iterations
Switzerland is Agile
local autonomy
empowered citizens
1 year presidents
4 languages
self-organizing teams
continuous integration
short iterations
collaboration
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
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
Opposite of Fragile
Fragile
HANDLE WITH CARE
Robust
Opposite of Fragile
PLEASEMISHANDLE
How do we help our agile process improve when things are mishandled?
Process depends on people
Uncertainty Avoidance
Russia: 95
Switzerland: 58
How do we handle uncertainty as individuals?
Tourist vs Flaneur
Tourist vs Flaneur
● predicted path ● unpredictable path
Tourist vs Flaneur
● predicted path● hard-to-revise plan
● unpredictable path● opportunistic
Tourist vs Flaneur
● predicted path● hard-to-revise plan● no options
● unpredictable path● opportunistic● many options
Process
Time
Process
Time
Tourist vs Flaneur
Gets worse with randomness Gets better with randomness
How to be a software flaneur
Key Activities
● Testing● Iteration and Refactoring● Estimation and Design● Policy making
Testing
Why do we write tests?
Redundancy
Redundancy is aggressive
Redundancy in the human body
Redundancy seems like a waste if nothing unusual happens
The tourist optimizes
“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.”
The flaneur relies on redundancy
“I know my code works.”
<boredom>
“Should we write this test, too? It’s just gonna pass.”
</boredom>
Estimation and Design
75% of software projects encounter effort and/or schedule overruns
“More planning!”
Planning Fallacy
We can’t estimate risk and randomness
We can estimate fragility
Nonlinearity
Estimate Error
Impact
Error
An estimate error of 5 days has 5x the impact of an estimate error of 1 day
Quality Error
Impact
Error
A quality error 10x greater than a small error hurts you more than 10 small errors
Quality is more fragile than budget…
focus on the most fragile part of the process
Design vs. Creating in Context
“The craftsmen had done further, deeper thinking about light than the designers.”
“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
“It doesn’t matter where you start, as long as you start.”
The tourist estimates and designs outcomes…
and is usually wrong
“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.”
The flaneur estimates fragility…
and limits exposure to nonlinearity
“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?”
Iteration and Refactoring
Optionality
You don’t have to be right that often
Changes in Value
Time
Small Errors
Big Discovery
Negative Knowledge
Knowing what doesn’t work is more effective than trying to figure out what does work
Are our retros just check-ins along the map?
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
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
The tourist stays on the bus
“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.”
The flaneur takes the path that makes future change easier
“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.”
Policy making
Intervention Bias Iatrogenics
Top-down policies and actions in which:
benefits are small and visible
side effects potentially severe and invisible
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.”
Top-down is hard to reverse, mistakes tend to stick
Bottom-up is noisy, gradual, and incremental
Top down code policies and metrics
Visible Benefits
Metrics improve
Defined course of action for most events
Tests for all acceptance criteria
Top down code policies and metrics
Side Effects
Rule beating?
Policy resistance, disengagement?
Tests outside the acceptance criteria?
The tourist intervenes from the top-down
“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.”
The flaneur organizes from the bottom up
“@%#!$%!”
“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.”
How to Wander
● Redundancy● Non-prediction● Non-intervention● Optionality
Wandering is Good
“The best way to verify that you are
alive is by checking if you like variations.”
Are you a wanderer or a tourist?
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
