Despite our best efforts with Agile best practices -- CI, unit testing, design reviews, code reviews -- every few years we end up rewriting our software. This talk is about my personal experiences with project failure, improvement failure, patterns across the industry, and the key lessons that were critical to success. I had a great team. We were disciplined with best practices and spent tons of time working on improvements. Yet still, I watched my team slam into a brick wall. We brought down production three times in a row, then couldn't ship again for another year. We thought our problems were caused by technical debt building up in the code base, but we were wrong. We failed to improve, because we didn't solve the right problems. Eventually, we turned our project around, but with a lot of tough lessons along the way. When I started consulting, I saw the same patterns across the industry: Our problems are invisible. They're hard to measure, hard to explain. We rely primary on gut feel to make improvement decisions, and it's really easy to make improvements that don't make much difference. The relentless business pressure never lets up, and developers don't have control. Without visibility, management makes ill-informed decisions, train-wrecks our projects, and drives the development team to exhaustion. I turned the lessons I learned into the Idea Flow Learning Framework, a data-driven feedback loop for guiding improvements. By quantifying the impact of disruptions, test maintenance, confusing code, and collaboration problems, we can find our biggest problems, understand the causes, and align our development priorities with leadership.

1. Software Rewrite Cycle
How to Break
the
Start%
Over%
Unmaintainable%
So0ware%
CTO, New Iron
Janelle Klein
©2015 New Iron Group

2. My Career
Maintenance Team
My First Project
Rewrite Team
The Next Generation

3. My Career
Maintenance Team
My First Project
Rewrite Team
The Next Generation

4. My Career
My 2nd Project
Third Generation Rewrite

5. My Career
My 3rd Project
I Kicked Off the Rewrite!!

6. My Career
My 4th Project
3rd Generation Rewrite

7. Start%
Over%
Unmaintainable%
So0ware%
Consulting...
My Career
Does anyone not have this challenge?

8. We Start with the Best of Intentions
High Quality Code
Low Technical Debt
Easy to Maintain
Good Code Coverage

9. Stages of Escalating Project Risk
Product Owner: “We’ve got more important things to do.”
Deferring(
Problems(

10. Deferring(
Problems(
Painful(
Releases(
Manager: “Good job everyone! Keep up that great work ethic!”
Stages of Escalating Project Risk

11. Deferring(
Problems(
Painful(
Releases(
Thrashing)
Manager: “We need to go faster! Let’s hire more developers.”
Stages of Escalating Project Risk

12. Deferring(
Problems(
Painful(
Releases(
Thrashing)
Project(
Meltdown(
Developer: “I give up. I don’t care anymore if the project fails.”
Stages of Escalating Project Risk

13. The further down the path,
the more tempting it is...
With invisible problems and business pressure that doesn’t let up,
we just keep repeating the same cycle.
RESET

14. Start%
Over%
Unmaintainable%
So0ware%
Software Rewrite Cycle

15. RESET
“A description of the goal is not a strategy.”
-- Richard P. Rumelt
What’s wrong with our current strategy?

16. Our “Strategy” for Success
High Quality Code
Low Technical Debt
Easy to Maintain
Good Code Coverage

17. RESET
“A good strategy is a specific and coherent response to—
and approach for overcoming—the obstacles to progress.”
-- Richard P. Rumelt
The problem is we don’t have a strategy...

18. RESET
So what are the biggest obstacles that
cause the software rewrite cycle?
What specific approach are we going to take
to overcome the obstacles?

19. RESET
How I turned my project around...
We did all the “right” things.

20. RESET
How I turned my project around...
We did all the “right” things.
...and brought down production 3x in a row.

21. Technical Debt Mistakes
I thought the main obstacle was
Technical Debt

22. Mistakes
?
Most of our mistakes were in the
most well-written parts of the code.

23. We made significantly more mistakes
in code that we didn’t write ourselves.
Lower
Familiarity
More
Mistakes=
There had to be more to the story...

24. Complex(
So*ware(
...pain...
This is what I knew...
What made development feel painful?

25. Unexpected
Behavior
Problem
Resolved
Tracking Painful Interaction with the Code (Friction)
Troubleshooting
Progress
5 hours and 18 minutes of troubleshooting...
PAINFUL

26. The Amount of PAIN was Driven By...
Likeliness(of((
Unexpected(
Behavior(
Cost(to(Troubleshoot(and(Repair(
High(Frequency(
Low(Impact(
Low(Frequency(
Low(Impact(
Low(Frequency(
High(Impact(
PAIN(

27. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
What causes PAIN?
Familiarity Mistakes
Stale Memory Mistakes
Semantic Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Generation
Using Debugger

28. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
What causes PAIN?
Familiarity Mistakes
Stale Memory Mistakes
Semantic Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Generation
Using Debugger

29. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
What causes PAIN?
Familiarity Mistakes
Stale Memory Mistakes
Semantic Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Once we understood causes, most problems were avoidable.
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Generation
Using Debugger

30. An Avoidable Problem
7:01
Iterative Validation with Unit Tests
7:010:00
14:230:00
Skipping Tests and Validating at the End

31. 7:01
Iterative Validation with Unit Tests
7:010:00
14:230:00
Skipping Tests and Validating at the End
Urgency Leads to High-Risk Decisions
If I make no mistakes I save ~2 hours.
If I make several mistakes I lose ~8 hours.
An Avoidable Problem

32. Product(
Requirements( So1ware(Task(
Possible(Decision(Paths(
So1ware(
Software is a Reflection of our Decisions

33. Product(
Requirements( So1ware(Task(
High%Risk%
Decision%Habits%
So1ware(
(and(all(our(problems)(
(
RESET
Software is a Reflection of our Decisions

34. Product(
Requirements( So1ware(Task(
High%Risk%
Decision%Habits%
So1ware(
(and(all(our(problems)(
(
Technical Debt is just a Symptom of the Problem
Software is a Reflection of our Decisions

35. How much work does it take to mop the floor?

36. How much work does it take to mop the floor?

37. How much work does it take to mop the floor?

38. How much work does it take to
complete a software task?
=
Side-Effects from
Ignoring the Risk
Trade-off Decisions
Writing Unit Tests Troubleshooting Mistakes
Direct Cost Indirect Costs
or
We make high-risk decisions because the indirect costs are hard to quantify.
Likeliness of Event
Potential Impact
x=
Risk

39. Troubleshooting Learning Rework
Side-Effects in Software

40. Troubleshooting Risk
Likelihood)of))
Unexpected)
Behavior)
Cost)to)Troubleshoot)and)Repair)
High)Frequency)
Low)Impact)
Low)Frequency)
Low)Impact)
Low)Frequency)
High)Impact)
PAIN)

41. Learning Risk
Likelihood)of))
working)with)
Unfamiliar)
Code)
Cost)to)Learn)
High)Frequency)
Easy)to)Learn)
Low)Frequency)
Easy)to)Learn)
Low)Frequency)
Hard)to)Learn)
PAIN)

42. Rework Risk
Likelihood)of))
making)a))
Bad)Assump4on)
Cost)to)Correct)Decisions)
High)Uncertainty)
Low)Delay)
Low)Uncertainty)
Low)Delay)
Low)Uncertainty)
High)Delay)
PAIN)

43. Deferring(
Problems(
Painful(
Releases(
Thrashing)
Project(
Meltdown(
Stages of Escalating Project Risk

44. Ignore Tango
(risk not obvious)
Escala&ng)
Risk)
Time)
Pressure)
Defer)
Problems)
Increase)
Risk)&)Impact)
of)Extra)
Work)
More)Frequent)
Bugs)and)
Higher)
Task)Effort)
Cycle of
Escalating
Risk
Ignore
Risk

45. Tangos
Multiply
Escala&ng)
Risk)
Time)
Pressure)
Defer)
Problems)
Increase)
Risk)&)Impact)
of)Extra)
Work)
More)Frequent)
Bugs)and)
Higher)
Task)Effort)
Cycle of
Escalating
Risk
Ignore
Risk

46. More Mopping
Work
Escala&ng)
Risk)
Time)
Pressure)
Defer)
Problems)
Increase)
Risk)&)Impact)
of)Extra)
Work)
More)Frequent)
Bugs)and)
Higher)
Task)Effort)
Cycle of
Escalating
Risk
Ignore
Risk

47. Further Behind on
Deliverables
Escala&ng)
Risk)
Time)
Pressure)
Defer)
Problems)
Increase)
Risk)&)Impact)
of)Extra)
Work)
More)Frequent)
Bugs)and)
Higher)
Task)Effort)
Cycle of
Escalating
Risk
Productivity plummets because of the overwhelming side-effects
Ignore
Risk
I can’t go
any faster!

48. Case Study 1:
Healthy project about 10 months old
Troubleshooting
Progress
Learning
Rework10-20% friction
Effects of Escalating Risk

49. Case Study 2:
Thrashing project about 18 months old
Troubleshooting
Progress
Learning
Rework40-60% friction
0:00 28:15
12:230:00
Effects of Escalating Risk

50. Case Study 3:
Post-meltdown project about 12 years old
Troubleshooting
Progress
Learning
Rework60-90% friction
7:070:00
0:00 19:52
Effects of Escalating Risk

51. Case Study 1
Case Study 2
Case Study 3
1 day
2 days
1 day
3 days
1 day
3 days
We can’t see these effects by measuring velocity or task lead-time.
Effects of Escalating Risk

52. What specific approach are we going to take
to overcome the obstacles?

53. Obstacle: Business Pressure
“We aren’t given time to work on improvements!”
(nobody understands the problems)

54. Developers are stuck because they don’t have control.
What are we supposed to do?
Management is stuck because they don’t have visibility.
Organizational Deadlock

55. 1. Don’t ask for Permission
2. State your Goal
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Make the Decision to Lead

56. 1. Don’t ask for Permission
2. Make the Goal Clear to Your Team
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Make the Decision to Lead

57. 1. Don’t ask for Permission
2. Make the Goal Clear to Your Team
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Make the Decision to Lead

58. 1. Don’t ask for Permission
2. Make the Goal Clear to Your Team
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Make the Decision to Lead

59. Share the PAIN!
Over the last month,
we’ve spent ~50% of our time troubleshooting
Troubleshooting JavaScript Errors

60. Share the PAIN!
With 25 developers on the team, rushing to save a couple hours
caused over 1000 hours of developer downtime

61. Blame the System...
Developer(
Knowledge(of(
So0ware(Risks(
Product(Owner(
Actual(So0ware(Risks(
interacts((
with(
Actual(Customers(
interacts((
with(
Knowledge(of(
Customers(
Trade@off(
Decisions(
depend(on(depend(on(
The likelihood of mistakes
and the potential impact
is difficult to quantify
and explain.
The product owner
can’t help making
ill-informed decisions.

62. Blame the System...
Escala&ng)
Risk)
Time)
Pressure)
Defer)
Problems)
Increase)
Risk)&)Impact)
of)Extra)
Work)
More)Frequent)
Bugs)and)
Higher)
Task)Effort)
“...we keep deferring the problems and taking risks
because we get stuck in a cycle of urgency.”
Constant
Urgency

63. Blame the System...
Likelihood)of))
Mistakes)
Cost)to)Troubleshoot)and)Repair)the)Problems)
High)Frequency)
Low)Impact)
Low)Frequency)
Low)Impact)
Low)Frequency)
High)Impact)
Us)
“...now the problems are out of control.”

64. Take Responsibility
Dedicated resources (1 or 2 developers)
Control of all decisions for improvement work
Make a commitment to show results in 3 months
Ask for a 3-Month Trial

65. Now the challenge is getting results.
Obstacle: Knowing What to Fix

66. Idea Flow Learning Framework
“Idea Flow” is a metaphor for the
human interaction in software development
Idea Flow Map

67. Idea Flow Learning Framework
Troubleshooting Learning Rework
Strategy for improving software predictability
by optimizing developer experience.

68. Input:
Task + Constraints
Target: Optimal Idea Flow
Output: Actual Friction
Need a Feedback Loop...

69. Input:
Task + Constraints
Target: Optimal Idea Flow
Output: Actual Friction
1.
Visibility
2.
Clarity
3.
Awareness
Mentorship Process

70. Idea Flow Learning Framework
1. Make the Problems Visible
2. Understand the Problems
3. Improve Decision Habits
Strategy for improving software predictability
by optimizing developer experience.

71. 1. Make the Problems Visible
2. Understand the Problems
3. Improve Decision Habits
Idea Flow Learning Framework
Strategy for improving software predictability
by optimizing developer experience.

72. 2.#Record#an#Idea#Flow#Map#
So#ware(Task(
Strategy((
Talk(
Reflec3on(
Talk(
Iden3fy(Improvements(
1.#Clarify#the#Strategy#
So#ware(Task(
3.#Reflect#on#Decisions#
Lessons(Learned(
Mee3ng(
4.#Share#Lessons#Learned#
Visibility Framework
Visibility helps us Identify and the Problems

73. 2. Record an Idea Flow Map
Idea Flow Mapping Commands

74. Troubleshooting
Progress
Learning
Rework
2. Record an Idea Flow Map

75. Troubleshooting
Progress
Learning
Rework
2. Record an Idea Flow Map

76. Troubleshooting
Progress
Learning
Rework
2. Record an Idea Flow Map

77. Troubleshooting
Progress
Learning
Rework
2. Record an Idea Flow Map

78. 3. Reflect on Decisions
Learn to Read the Visual Indicators in Idea Flow Maps
Le#$Atrium$
Le#$Ventricle$
Right$Ventricle$
Right$Atrium$
What’s$causing$this$pa7ern?$
Similar to how an EKG helps doctors diagnose heart problems...

79. ...Idea Flow Maps help developers diagnose software problems.
Problem-Solving
Machine
Learn to Read the Visual Indicators in Idea Flow Maps
3. Reflect on Decisions

80. = Solution Strategy
The “Heart” of Software Development
(the problem-solving machine)

81. = Solution Strategy
The “Heart” of Software Development
(the problem-solving machine)

82. = Solution Strategy
The “Heart” of Software Development
(the problem-solving machine)

83. = Solution Strategy
The “Heart” of Software Development
(the problem-solving machine)

84. = Solution Strategy
The “Heart” of Software Development
(the problem-solving machine)

85. Depending on where the disruptions are in the process,
we see a different effect in Idea Flow.

86. "How did you evaluate the possible options and choose a strategy?"
"What was wrong with the different strategies you tried?"
"What was the discovery that made you choose a different direction?"
Problems with Evaluating Alternatives

87. "Were you working with something that you were unfamiliar with?"
"Did you run into code that was noisy, ambiguous, or misleading?"
"What do you think made it difficult to learn?"
Problems with Modeling

88. "Did your task involve changes to complex code or business rules?"
"Were there a lot of details that you had to keep in your head?"
"What was causing the complexity in the validation cycles?"
Problems with Refining

89. "What experiments did you run to troubleshoot the problem?"
"How many times did you run the experiment?"
"How long did it take to get through each experiment cycle?"
Problems with the Validation Cycle

90. "Was there something in the code that made these changes especially mistake-prone?"
"How familiar were you with the language and tools you were working with?"
"Were you tired or distracted when you did the work?"
Problems with Execution

91. 1. Make the Problems Visible
The goal of visibility is to ask the right questions
so we can identify problems with our strategy.

92. 2.#Record#an#Idea#Flow#Map#
So#ware(Task(
Strategy((
Talk(
Reflec3on(
Talk(
Iden3fy(Improvements(
1.#Clarify#the#Strategy#
So#ware(Task(
3.#Reflect#on#Decisions#
Lessons(Learned(
Mee3ng(
4.#Share#Lessons#Learned#
Visibility Framework
Visibility helps us Identify and the Problems

93. Idea Flow Learning Framework
1. Make the Problems Visible
2. Understand the Problems
3. Improve Decision Habits
Strategy for improving software predictability
by optimizing developer experience.

94. Brainstorming a List
“Technical Debt” Backlog
Our improvements don’t make much difference

95. Clarity Framework
Understand what’s Causing your Biggest Problems
Failed'
Experiments'
1. Choose(a(Focus( 3.(Run(Strategy(
Experiments(
4.(Learn(What(Works(
Successful'
Experiments'
Repeat'
Weekly'
Focus'Mee:ng'
2.(Breakdown(the(PaCerns(

96. Failed'
Experiments'
1. Choose(a(Focus( 3.(Run(Strategy(
Experiments(
4.(Learn(What(Works(
Successful'
Experiments'
Repeat'
Weekly'
Focus'Mee:ng'
2.(Breakdown(the(PaCerns(
Understand what’s Causing your Biggest Problems
Clarity Framework

97. 1. Choose a Focus
Highest
Impact Optimal
Focus
Highest
Uncertainty
Fastest
Feedback

98. Categorize the problem by type to see the impact
Focus on the problem with the highest friction
1. Choose a Focus

99. Tags: #problemtag
Categorize the problem by type
1. Choose a Focus

100. “But what problem categories do we use?”

101. The Ten Pains of Software Development

102. The Ten Pains of Software Development
Design-Fit Pain - When the new feature doesn’t
fit well into the existing design.

103. The Ten Pains of Software Development
Requirements Pain - Bad assumptions about
what functionality to build

104. The Ten Pains of Software Development
Collaboration Pain - Challenges collaborating with
other developers on the team.

105. The Ten Pains of Software Development
Modeling Pain - When it’s difficult to build a
conceptual model of the existing software.

106. The Ten Pains of Software Development
Cognitive Pain - Challenges with complexity
and intense thinking

107. The Ten Pains of Software Development
Alarm Pain - Challenges with false alarms and
test maintenance

108. The Ten Pains of Software Development
Experiment Pain - Challenges with getting
feedback by running experiments

109. The Ten Pains of Software Development
Execution Pain - When changing the code is
highly mistake-prone

110. The Ten Pains of Software Development
Have an amplifying effect on other problems

111. Add up Friction by Pain Type
100 hours
50 hours
Troubleshooting
Learning
Rework
Focused Improvements Visible Feedback

112. Failed'
Experiments'
1. Choose(a(Focus( 3.(Run(Strategy(
Experiments(
4.(Learn(What(Works(
Successful'
Experiments'
Repeat'
Weekly'
Focus'Mee:ng'
2.(Breakdown(the(PaCerns(
Understand what’s Causing your Biggest Problems
Clarity Framework

113. Failed'
Experiments'
1. Choose(a(Focus( 3.(Run(Strategy(
Experiments(
4.(Learn(What(Works(
Successful'
Experiments'
Repeat'
Weekly'
Focus'Mee:ng'
2.(Breakdown(the(PaCerns(
Understand what’s Causing your Biggest Problems
Clarity Framework

114. Create a Vocabulary of Patterns
Pain
Types
Problem
Types
Strategy
Types
Symptoms Causes Fixes
2. Breakdown the Patterns

115. 2. Breakdown the Patterns
What Causes Experiment Pain?
100 hours
50 hours
Create a Vocabulary of Patterns

116. Why did it take an hour
to find a typo?
Slow Feedback Loop - Ran experiments by firing up application and sending email
Numerous Feedback Loops - Problem was tricky to trackdown, sent 23 emails
Tags: #ExperimentPain
What Causes Experiment Pain?

117. Experiment*Pain*
!Numerous!Feedback!Loops!
Itera&ve(Narrowing(
Ambiguous(Clue(
Non6determinis&c(
Lots(of(Test(Cases(
Lots(of(Bugs(
Bad(Input(Assump&on(
Uncertainty(
Difficult(to(Interpret(
Experiment*Pain*
!Slow!Feedback!Loops!
Long%Execu+on%
Noisy%Output%
Limited%Output%
Complex%Behavior%
Non<determinis+c%Behavior%
Lots%of%Code%Changes%
Difficult%to%Interpret%
Test%Input%Genera+on%
Environment%Setup%
Environment%Cleanup%
Have%to%significantly%modify%a%test%
Debugger%
What Causes Experiment Pain?

118. What Strategies Do We Use?
Iterative Unit Testing
Vertical Slices
Talk to the Familiar
Incremental Integration Test
Intelligent Logging
Isolate Hard-to-Test Code
Tight Control
State Controller
Front Load the Risk

119. Failed'
Experiments'
1. Choose(a(Focus( 3.(Run(Strategy(
Experiments(
4.(Learn(What(Works(
Successful'
Experiments'
Repeat'
Weekly'
Focus'Mee:ng'
2.(Breakdown(the(PaCerns(
Understand what’s Causing your Biggest Problems
Clarity Framework

120. Failed'
Experiments'
1. Choose(a(Focus( 3.(Run(Strategy(
Experiments(
4.(Learn(What(Works(
Successful'
Experiments'
Repeat'
Weekly'
Focus'Mee:ng'
2.(Breakdown(the(PaCerns(
Understand what’s Causing your Biggest Problems
Clarity Framework

121. How do we know if we’re making things better?

122. What does “better” really mean?
“Better” following best practices
“Better” solving the problems
Best Practices
(solution-focused)
Decision Principles
(problem-focused)

123. What’s a “Decision Principle”?
Answers two questions:
How do we evaluate our situation?
What are we trying to optimize for?

124. Decision Principles
“You know that thing that happens when you make too many changes at once
and it's really hard to troubleshoot problems? We want to avoid that.”
“If I decide to skip the unit tests, how will that affect my haystack size?”
Haystack Effect
The number of unvalidated changes
has a huge impact on the
difficulty of tracking down a problem.

125. “You know when you run an experiment and it’s really hard to figure out what’s
going on? We want to avoid that.”
“How can I design my code sandwich to make this easier to troubleshoot?”
Setup the Inputs
Interpret the Outputs
Code Sandwich
By reducing the
thickness of my code sandwich
I can reduce diagnostic difficulty.
Decision Principles

126. We can learn what works by running
“Strategy Experiments”

127. 3. Run Strategy Experiments
1.
2.3.
1. Decide on a Strategy
2. Predict the effects in Idea Flow
3. Explain the results
Strategy(
Predic-on(Explana-on(

128. 3. Run Strategy Experiments
“I’m going to use Iterative Unit Testing to mitigate the risk of a big haystack."
Prediction: My strategy of #IterativeUnitTesting seemed successful,
troubleshooting should take <15m

129. 3. Run Strategy Experiments
Prediction: My strategy of #IterativeUnitTesting seemed successful,
troubleshooting should take <15m
Explain Why? Situation Pattern:
#HeavyIntegrationLogic
“I’m going to use Iterative Unit Testing to mitigate the risk of a big haystack."

130. Failed'
Experiments'
1. Choose(a(Focus( 3.(Run(Strategy(
Experiments(
4.(Learn(What(Works(
Successful'
Experiments'
Repeat'
Weekly'
Focus'Mee:ng'
2.(Breakdown(the(PaCerns(
Understand what’s Causing your Biggest Problems
Clarity Framework

131. 2. Understand the Problems
The goal of understanding the problems
is to identify the “critical few”
that will make the biggest difference.
Pareto’s Law - (80/20 Rule)

132. Idea Flow Learning Framework
1. Make the Problems Visible
2. Understand the Problems
3. Improve Decision Habits
Strategy for improving software predictability
by optimizing developer experience.

133. Clarity without Awareness...
“Well that was a stupid thing to do. Clearly, I shouldn’t have created a big
haystack because troubleshooting would obviously be difficult.”
We have to
be aware in the moment
we make the decision.

135. Stop and Think
Practice asking the right question at the right time
“What does your code sandwich look like for this experiment?”
“What are you planning to observe in order to understand the behavior?”
“What parts of the system are you trying to manipulate in order to see
variations in behavior?”
Situation
Developer struggling with an experiment
(poke the developer)
Ask Questions

136. Awareness Framework
So#ware(Task(
So#ware(Task(Strategy((
Talk(
Thinking(checklists(in((
key(situa5onal(contexts(
Evaluate(Decision(Principles(
!(
!(
!(
!(
!(
!(
!(
!(
!(
Reflec5on(
Talk(
!(
!(
Refine(
Thinking(
Checklists(
Thinking(checklist(
to(mi5gate(risk(
+(
!(
!(
!(
Think: What questions could I ask my future self to
recognize this problem in the future?
Ask the right question at the right time

137. 3. Improve Decision Habits
The goal of improving decision habits is to
make the improvements permanent.

138. Input:
Task + Constraints
Target: Optimal Idea Flow
Output: Actual Friction
1.
Visibility
2.
Clarity
3.
Awareness
Idea Flow Learning Framework
(Software Control = Predictability)

139. So how do we break the software rewrite cycle?
Start%
Over%
Unmaintainable%
So0ware%
We Learn.

140. Thank you!
If you liked the talk,
please tweet about #ideaflow!
Free e-book if you sign up
by July 15th!
@janellekz
janelle@newiron.com
Twitter:
Email: