Wandering Through Software
-
Upload
kevbuchanan -
Category
Software
-
view
114 -
download
0
Transcript of Wandering Through Software
Benefits from Volatility
Never invaded or attacked during either WW
GDP rose 5% each year following WWII
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
Tourist vs Flaneur
● predicted path● hard-to-revise plan● no options
● unpredictable path● opportunistic● many options
“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.”
“I know my code works.”
<boredom>
“Should we write this test, too? It’s just gonna pass.”
</boredom>
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
“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.”
“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?”
Negative Knowledge
Knowing what doesn’t work is more effective than trying to figure out what does work
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
“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.”
“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.”
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 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?
“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.”
“@%#!$%!”
“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.”
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