how to break the software rewrite cycle

Presentado por:Janelle Klein

How to Break the

Software Rewrite Cycle

Software Rewrite CycleHow to Break

the

Start%Over%

Unmaintainable%So0ware%

CTO, New IronJanelle Klein

©2015 New Iron Group

Tuesday, May 12, 15

We Start with the Best of Intentions

High Quality Code

Low Technical Debt

Easy to Maintain

Good Code Coverage

Tuesday, May 12, 15

Stages of Escalating Project Risk

Deferring(Problems(

Tuesday, May 12, 15


Product Owner: “We’ve got more important things to do.”

Deferring(Problems(

Tuesday, May 12, 15

Deferring(Problems(

Painful(Releases(


Tuesday, May 12, 15

Deferring(Problems(

Painful(Releases(

Manager: “Good job everyone! Keep up that great work ethic!”


Tuesday, May 12, 15

Deferring(Problems(

Painful(Releases(

Thrashing)


Tuesday, May 12, 15

Deferring(Problems(

Painful(Releases(

Thrashing)

Manager: “We need to go faster! Let’s hire more developers.”


Tuesday, May 12, 15

Deferring(Problems(

Painful(Releases(

Thrashing) Project(Meltdown(


Tuesday, May 12, 15

Deferring(Problems(

Painful(Releases(


Developer: “I give up. I don’t care anymore if the project fails.”


Tuesday, May 12, 15

The further down the path,the more tempting it is...

RESET

Tuesday, May 12, 15

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

Tuesday, May 12, 15

Start%Over%


Software Rewrite Cycle

Tuesday, May 12, 15

RESET

What’s wrong with our current strategy?

Tuesday, May 12, 15

RESET

“A description of the goal is not a strategy.”

-- Richard P. Rumelt

What’s wrong with our current strategy?

Tuesday, May 12, 15

Our “Strategy” for Success

High Quality Code

Low Technical Debt

Easy to Maintain

Good Code Coverage

Tuesday, May 12, 15

RESET

The problem is we don’t have a strategy...

Tuesday, May 12, 15

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...

Tuesday, May 12, 15

RESET

So what are the obstacles that cause the software rewrite cycle?

Tuesday, May 12, 15

RESET

So what are the obstacles that cause the software rewrite cycle?

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

Tuesday, May 12, 15

RESET

My Project...

We did all the “right” things.

Tuesday, May 12, 15

RESET

My Project...

We did all the “right” things.

then we brought down production 3x in a row.

Tuesday, May 12, 15

Technical Debt Mistakes

I thought the main obstacle wasTechnical Debt

Tuesday, May 12, 15

Mistakes?

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

Tuesday, May 12, 15

We made significantly more mistakesin code that we didn’t write ourselves.

LowerFamiliarity

MoreMistakes=

Tuesday, May 12, 15

We made significantly more mistakesin code that we didn’t write ourselves.

LowerFamiliarity

MoreMistakes=

There had to be more to the story...

Tuesday, May 12, 15

Complex(So*ware(

...pain...

This is what I knew...

Tuesday, May 12, 15

Complex(So*ware(

...pain...

This is what I knew...

What made development feel painful?

Tuesday, May 12, 15

Tracking Painful Interaction with the Code (Friction)

Troubleshooting

Progress

Tuesday, May 12, 15

UnexpectedBehavior


Troubleshooting

Progress

Tuesday, May 12, 15

UnexpectedBehavior

ProblemResolved


Troubleshooting

Progress

Tuesday, May 12, 15

UnexpectedBehavior

ProblemResolved


Troubleshooting

Progress

5 hours and 18 minutes of troubleshooting...

PAINFUL

Tuesday, May 12, 15

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(

Tuesday, May 12, 15

What Causes UnexpectedBehavior (likeliness)?

What Makes TroubleshootingTime-Consuming (impact)?

What causes PAIN?

Tuesday, May 12, 15



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

Ambiguous Clues

Non-Deterministic Behavior

Lots of Code Changes

Noisy Output

Cryptic Output

Long Execution Time

Environment Cleanup

Test Data Generation

Using Debugger

Tuesday, May 12, 15



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

Ambiguous Clues

Non-Deterministic Behavior

Lots of Code Changes

Noisy Output

Cryptic Output

Long Execution Time

Environment Cleanup

Test Data Generation

Using Debugger

Most of the problems were easy to avoid.Tuesday, May 12, 15

An Avoidable Problem

7:01

Iterative Validation with Unit Tests7:010:00

Tuesday, May 12, 15


7:01


14:230:00

Skipping Tests and Validating at the End

Tuesday, May 12, 15

7:01


14:230:00


Urgency Leads to High-Risk Decisions


Tuesday, May 12, 15

7:01


14:230:00



If I make no mistakes I save ~2 hours.


Tuesday, May 12, 15

7:01


14:230:00



If I make no mistakes I save ~2 hours.

If I make several mistakes I lose ~8 hours.


Tuesday, May 12, 15

Product(Requirements( So1ware(Task(

Possible(Decision(Paths(

So1ware(

Software is a Reflection of our Decisions

Tuesday, May 12, 15


High%Risk%Decision%Habits%

So1ware((and(all(our(problems)(

(


Tuesday, May 12, 15




(

RESET


Tuesday, May 12, 15




(


Tuesday, May 12, 15




(

Technical Debt is just a Symptom of the Problem


Tuesday, May 12, 15

Tuesday, May 12, 15

How much work does it take to mop the floor?

Tuesday, May 12, 15

How much work does it take to complete a software task?

Tuesday, May 12, 15


Likeliness of Event

Potential Impactx=

Risk

Tuesday, May 12, 15


= Side-Effects fromIgnoring the Risk

Likeliness of Event

Potential Impactx=

Risk

Tuesday, May 12, 15



Trade-off Decisions

Writing Unit Tests Troubleshooting MistakesDirect Cost Indirect Costs

or

Likeliness of Event

Potential Impactx=

Risk

Tuesday, May 12, 15



Trade-off Decisions

Writing Unit Tests Troubleshooting MistakesDirect Cost Indirect Costs

or

We make high-risk decisions because the indirect costs are hard to quantify.

Likeliness of Event

Potential Impactx=

Risk

Tuesday, May 12, 15

Troubleshooting Learning Rework

Side-Effects in Software

Tuesday, May 12, 15

Troubleshooting Risk

Likelihood)of))Unexpected)Behavior)

Cost)to)Troubleshoot)and)Repair)

High)Frequency)Low)Impact)

Low)Frequency)Low)Impact)

Low)Frequency)High)Impact)

PAIN)

Tuesday, May 12, 15

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)

Tuesday, May 12, 15

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)

Tuesday, May 12, 15

Deferring(Problems(

Painful(Releases(



Tuesday, May 12, 15

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 ofEscalating

Risk

IgnoreRisk

Tuesday, May 12, 15

TangosMultiply

Escala&ng)Risk)

Time)Pressure)

Defer)Problems)


of)Extra)Work)


Task)Effort)

Cycle ofEscalating

Risk

IgnoreRisk

Tuesday, May 12, 15

More MoppingWork

Escala&ng)Risk)

Time)Pressure)

Defer)Problems)


of)Extra)Work)


Task)Effort)

Cycle ofEscalating

Risk

IgnoreRisk

Tuesday, May 12, 15

Further Behind on Deliverables

Escala&ng)Risk)

Time)Pressure)

Defer)Problems)


of)Extra)Work)


Task)Effort)

Cycle ofEscalating

Risk

IgnoreRisk

I can’t go any faster!

Tuesday, May 12, 15

Further Behind on Deliverables

Escala&ng)Risk)

Time)Pressure)

Defer)Problems)


of)Extra)Work)


Task)Effort)

Cycle ofEscalating

Risk

Productivity plummets because of the overwhelming side-effects

IgnoreRisk

I can’t go any faster!

Tuesday, May 12, 15

Case Study 1: Healthy project about 10 months old

Troubleshooting

Progress

Learning

Rework10-20% friction

Effects of Escalating Risk

Tuesday, May 12, 15

Case Study 2: Thrashing project about 18 months old

Troubleshooting

Progress

Learning


0:00 28:15

12:230:00


Tuesday, May 12, 15

Case Study 3: Post-meltdown project about 12 years old

Troubleshooting

Progress

Learning


7:070:00

0:00 19:52


Tuesday, May 12, 15

Case Study 1

Case Study 2

Case Study 3

1 day

2 days

1 day

3 days

1 day

3 days


Tuesday, May 12, 15

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.


Tuesday, May 12, 15

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

Tuesday, May 12, 15

Idea Flow Learning Framework

“Idea Flow” is a metaphor for the human interaction in software development

Idea Flow Map

Tuesday, May 12, 15

Idea Flow Learning FrameworkStrategy for improving software predictability

by optimizing developer experience.

Tuesday, May 12, 15


Troubleshooting Learning Rework

Strategy for improving software predictability by optimizing developer experience.

Tuesday, May 12, 15

The First Obstacle“We aren’t given time to work on improvements!”

(nobody understands the problems)

Tuesday, May 12, 15

Developers are stuck because they don’t have control.

Tuesday, May 12, 15


Management is stuck because they don’t have visibility.

Tuesday, May 12, 15



Organizational Deadlock

Tuesday, May 12, 15


If we want things to change, we have to step outside the bounds of our role.


Organizational Deadlock

Tuesday, May 12, 15

Make the Decision to Lead

Tuesday, May 12, 15

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?”


Tuesday, May 12, 15


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."




Tuesday, May 12, 15


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."




Tuesday, May 12, 15

Next, Make the CaseChange is a safer decision than staying the course.

Tuesday, May 12, 15


Focus on the Risks

Tuesday, May 12, 15


The project is more likely to fail if you stay on the current path.

Focus on the Risks

Tuesday, May 12, 15


The project is more likely to fail if you stay on the current path.

Focus on the Risks

The indirect costs are more expensivethan mitigating the risk.

is safer than

Tuesday, May 12, 15

Take Responsibility

Tuesday, May 12, 15

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

Tuesday, May 12, 15

The next challenge is getting results.

Tuesday, May 12, 15


1. Make the Problems Visible

2. Understand the Problems

3. Improve Decision Habits


Tuesday, May 12, 15




Idea Flow Learning FrameworkStrategy for improving software predictability

by optimizing developer experience.

Tuesday, May 12, 15

Reflection FrameworkVisibility helps us Identify the Problems

2.#Record#what#Happens#

So#ware(Task(Strategy((Talk(

Reflec3on(Talk(

Iden3fy(Problems(

1.#Clarify#the#Strategy#

So#ware(Task(

3.#Ask#Ques?ons#

Tuesday, May 12, 15

1. Clarify the StrategyDraw a “solution strategy” diagram

Tuesday, May 12, 15

1. Clarify the StrategyDraw a “solution strategy” diagram

1. Talk through the strategy with a peer

2. Reflect on the strategy when we finish

It’s Easier to...

Tuesday, May 12, 15

2. Record What HappensCreate an Idea Flow Map

Tuesday, May 12, 15

Troubleshooting

Progress

Learning

Rework

2. Record What HappensCreate an Idea Flow Map

Tuesday, May 12, 15

3. Ask QuestionsLearn to Read the Visual Indicators in Idea Flow Maps

Tuesday, May 12, 15

3. Ask QuestionsLearn 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...

Tuesday, May 12, 15

...Idea Flow Maps help developers diagnose software problems.

Problem-SolvingMachine

Learn to Read the Visual Indicators in Idea Flow Maps

3. Ask Questions

Tuesday, May 12, 15

= Solution Strategy

The “Heart” of Software Development(the problem-solving machine)

Tuesday, May 12, 15

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

Tuesday, May 12, 15

Problems with Evaluating Alternatives

Tuesday, May 12, 15

"How did you evaluate the possible options and choose a strategy?"


Tuesday, May 12, 15


"What was wrong with the different strategies you tried?"


Tuesday, May 12, 15


"What was wrong with the different strategies you tried?"

"What was the discovery that made you choose a different direction?"


Tuesday, May 12, 15

Problems with Modeling

Tuesday, May 12, 15

"Were you working with something that you were unfamiliar with?"


Tuesday, May 12, 15


"Did you run into code that was noisy, ambiguous, or misleading?"


Tuesday, May 12, 15


"Did you run into code that was noisy, ambiguous, or misleading?"

"What do you think made it difficult to learn?"


Tuesday, May 12, 15

Problems with Refining

Tuesday, May 12, 15

"Did your task involve changes to complex code or business rules?"


Tuesday, May 12, 15


"Were there a lot of details that you had to keep in your head?"


Tuesday, May 12, 15


"Were there a lot of details that you had to keep in your head?"

"What was causing the complexity in the validation cycles?"


Tuesday, May 12, 15

Problems with the Validation Cycle

Tuesday, May 12, 15

"What experiments did you run to troubleshoot the problem?"


Tuesday, May 12, 15


"How many times did you run the experiment?"


Tuesday, May 12, 15


"How many times did you run the experiment?"

"How long did it take to get through each experiment cycle?"


Tuesday, May 12, 15

Problems with Execution

Tuesday, May 12, 15

"Was there something in the code that made these changes especially mistake-prone?"


Tuesday, May 12, 15


"How familiar were you with the language and tools you were working with?"


Tuesday, May 12, 15


"How familiar were you with the language and tools you were working with?"

"Were you tired or distracted when you did the work?"


Tuesday, May 12, 15


The goal of visibility is to ask the right questions so we can identify problems with our strategy.

Tuesday, May 12, 15

Reflection Framework

2.#Record#what#Happens#


Reflec3on(Talk(

Iden3fy(Problems(

1.#Clarify#the#Strategy#

So#ware(Task(

3.#Ask#Ques?ons#

Visibility helps us Identify the Problems

Tuesday, May 12, 15






Tuesday, May 12, 15

Brainstorming a List

Tuesday, May 12, 15


“Technical Debt” Backlog

Tuesday, May 12, 15


“Technical Debt” Backlog

Our improvements don’t make much difference

Tuesday, May 12, 15

Modeling Framework

Failed'Experiments'

1.   Find'the'biggest''problem'

3.'Run'experiments'to'test'understanding'

4.'Clarify'Decision'Principles'

Successful'Experiments'

Repeat'Weekly'

Focus'Mee:ng'

2.'Model'the'causes'of'the'problem'

Understand what’s Causing your Biggest Problems

Tuesday, May 12, 15

1. Find the Biggest ProblemCategorize the problem by type

Focus on the problem with the highest friction

Tuesday, May 12, 15

Tags: #problemtag

1. Find the Biggest ProblemCategorize the problem by type

Tuesday, May 12, 15

“But what problem categories do we use?”

Tuesday, May 12, 15

The Ten Pains of Software Development

Tuesday, May 12, 15


Design-Fit Pain - When the new feature doesn’t fit well into the existing design.

Tuesday, May 12, 15


Requirements Pain - Bad assumptions about what functionality to build

Tuesday, May 12, 15


Collaboration Pain - Challenges collaborating with other developers on the team.

Tuesday, May 12, 15


Modeling Pain - When it’s difficult to build a conceptual model of the existing software.

Tuesday, May 12, 15


Cognitive Pain - Challenges with complexity and intense thinking

Tuesday, May 12, 15


Alarm Pain - Challenges with false alarms and test maintenance

Tuesday, May 12, 15


Experiment Pain - Challenges with getting feedback by running experiments

Tuesday, May 12, 15


Execution Pain - When changing the code is highly mistake-prone

Tuesday, May 12, 15


Have an amplifying effect on other problems

Tuesday, May 12, 15

Add up Friction by Pain Type

100 hours

50 hours

Troubleshooting

Learning

Rework

Tuesday, May 12, 15

Add up Friction by Pain Type

100 hours

50 hours

Troubleshooting

Learning

Rework

Focused Improvements Visible Feedback

Tuesday, May 12, 15

High Resistance to Change

Software(start)

Software(end)

friction

Tuesday, May 12, 15


Software(start)

Software(end)

friction

Friction is always relative to the movement of the system.

Tuesday, May 12, 15


Software(start)

Software(end)

friction


If there is no movement, there is no friction.

Tuesday, May 12, 15


Software(start)

Software(end)

friction


If there is no movement, there is no friction.

Different areas of code will move in different ways.

Tuesday, May 12, 15

Last 3 Months of Friction by Functional Area

What’s going on with theReporting Engine?

Troubleshooting

Progress

Learning

Rework

Tuesday, May 12, 15

% Friction versus Upcoming Demand

The Reporting Engine isn’t moving.

Troubleshooting

Progress

Learning

Rework

Tuesday, May 12, 15

% Friction Grouped by Functional Area Familiar versus Unfamiliar

Lack of Familiarity(amplifier)

Especially Painful toUnfamiliar Developers

Tuesday, May 12, 15

WARNING:

This does not mean you improved!!!

Before

After

Tuesday, May 12, 15

Instead, Focus on the Biggest Problem-Solving Pain

100 hours

50 hours

Tuesday, May 12, 15

Instead, Focus on the Biggest Problem-Solving Pain

100 hours

50 hours

We can compare examples of the same pain type between tasks

Tuesday, May 12, 15

Modeling Framework

Failed'Experiments'





Repeat'Weekly'

Focus'Mee:ng'



Tuesday, May 12, 15

2. Model the Causes of the Problem

What Causes Experiment Pain?

100 hours

50 hours

Tuesday, May 12, 15

Tags: #ExperimentPain


Tuesday, May 12, 15

Why did it take an hourto find a typo?



Tuesday, May 12, 15


Slow Feedback Loop - Ran experiments by firing up application and sending email



Tuesday, May 12, 15


Slow Feedback Loop - Ran experiments by firing up application and sending email

Numerous Feedback Loops - Problem was tricky to trackdown, sent 23 emails



Tuesday, May 12, 15

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%


Tuesday, May 12, 15

Modeling Framework

Failed'Experiments'





Repeat'Weekly'

Focus'Mee:ng'



Tuesday, May 12, 15

3. Run Experiments to Test Understanding

Tuesday, May 12, 15


Decision(

Predic,on(Experiment(

1.

2.3.

Tuesday, May 12, 15


Decision(


1.

2.3.

1. Make a decision

Tuesday, May 12, 15


Decision(


1.

2.3.

1. Make a decision

2. Predict the effects in Idea Flow

Tuesday, May 12, 15


Decision(


1.

2.3.

1. Make a decision

2. Predict the effects in Idea Flow

3. See if you get the result you were expecting... ask why.

Tuesday, May 12, 15

“I’m going to run final testing by firing up the app. I’ve written good unit tests along the way,

so I predict that troubleshooting will be quick.”

Example Experiments

Tuesday, May 12, 15



Example Experiments

Troubleshooting took 4 hours... why?

Tuesday, May 12, 15



“I’m going to skip writing unit tests and run the report manually.Since it’s a slow feedback loop,

I predict that troubleshooting will take a long time.”

Example Experiments


Tuesday, May 12, 15





Example Experiments


All troubleshooting took 2 minutes or less... why?

Tuesday, May 12, 15





Example Experiments

Experiments help us correct bad assumptions about what is a “better” decision


All troubleshooting took 2 minutes or less... why?

Tuesday, May 12, 15

Modeling Framework

Failed'Experiments'





Repeat'Weekly'

Focus'Mee:ng'



Tuesday, May 12, 15

What does “better” really mean?

Tuesday, May 12, 15


“Better” following best practices

Tuesday, May 12, 15



“Better” solving the problems

Tuesday, May 12, 15



“Better” solving the problems

Best Practices(solution-focused)

Decision Principles(problem-focused)

Tuesday, May 12, 15

What’s a “Decision Principle”?

Answers two questions:

Tuesday, May 12, 15



How do we evaluate our situation?

Tuesday, May 12, 15



How do we evaluate our situation?

What are we trying to optimize for?

Tuesday, May 12, 15

4. Clarify Decision Principles

Tuesday, May 12, 15


“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.”

Tuesday, May 12, 15



Haystack Effect

The number of unvalidated changeshas a huge impact on the

difficulty of tracking down a problem.

Tuesday, May 12, 15



“If I decide to skip the unit tests, how will that affect my haystack size?”

Haystack Effect

The number of unvalidated changeshas a huge impact on the

difficulty of tracking down a problem.

Tuesday, May 12, 15


“You know when you run an experiment and it’s really hard to figure out what’s going on? We want to avoid that.”

Tuesday, May 12, 15



Setup the Inputs

Interpret the Outputs

Code Sandwich

Tuesday, May 12, 15



Setup the Inputs


Code Sandwich

By reducing thethickness of my code sandwichI can reduce diagnostic difficulty.

Tuesday, May 12, 15



“How can I design my code sandwich to make this easier to troubleshoot?”

Setup the Inputs


Code Sandwich

By reducing thethickness of my code sandwichI can reduce diagnostic difficulty.

Tuesday, May 12, 15

Modeling FrameworkUnderstand what’s Causing your Biggest Problems

Failed'Experiments'





Repeat'Weekly'

Focus'Mee:ng'


Tuesday, May 12, 15


The goal of understanding the problems is to identify the “critical few”

that will make the biggest difference.

Pareto’s Law - (80/20 Rule)

Tuesday, May 12, 15






Tuesday, May 12, 15

Decision(Habits(

Pa#erns(Across(Developer(Experiences(

Tasks(Tasks(Tasks(

Observe(&(Adjust(

High-Risk Decisions are the Root Cause of our Problems

Improve Decision Habits

Tuesday, May 12, 15

Decision(Habits(

Pa#erns(Across(Developer(Experiences(

Tasks(Tasks(Tasks(

Observe(&(Adjust(

High-Risk Decisions are the Root Cause of our Problems

Improve Decision Habits

“But how do we change decision habits?”

Tuesday, May 12, 15

Tuesday, May 12, 15

Stop and ThinkPractice asking the right question at the right time

Tuesday, May 12, 15


Situation

Developer struggling with an experiment(poke the developer)

Tuesday, May 12, 15


Situation


Ask Questions

Tuesday, May 12, 15


“What aspects of the behavior are you trying to observe?”

Situation


Ask Questions

Tuesday, May 12, 15



“What aspects of the behavior are you trying to manipulate?”

Situation


Ask Questions

Tuesday, May 12, 15


“How can you reduce the thickness of your code sandwich?”


“What aspects of the behavior are you trying to manipulate?”

Situation


Ask Questions

Tuesday, May 12, 15

Stop and Think Framework

So#ware(Task(


Thinking(checklists(in((key(situa5onal(contexts(

Evaluate(Decision(Principles(

!(!(!( !(!(

!( !(!(!(

Reflec5on(Talk(

!(!(

Refine(Thinking(

Checklists(

Thinking(checklist(to(mi5gate(risk(

+(!(!(!(

Training Wheels for Improving Decision-Habits

Tuesday, May 12, 15

Stop and Think Framework

So#ware(Task(


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?

Training Wheels for Improving Decision-Habits

Tuesday, May 12, 15


The goal of improving decision habits is tomake the improvements permanent.

Tuesday, May 12, 15






Tuesday, May 12, 15

Work our Way to Software Happiness!

Start%Over%


Software Happiness!

Tuesday, May 12, 15

Free e-book! (summer)

Thank you!If you liked the talk, please tweet about #ideaflow!

Interested? Send me an email!

Tuesday, May 12, 15

Free e-book! (summer)

Thank you!

[email protected] @janellekz

If you liked the talk, please tweet about #ideaflow!

Interested? Send me an email!

Tuesday, May 12, 15

mailto:[email protected]

mailto:[email protected]

how to break the software rewrite cycle

Technology

resetmy project

current strategy

reseta good strategy

mistakesin code

software rewrite cycletuesday

technical debt mistakesi

resetwhats wrong

overcomingthe obstacles