How should we build that?
Evolving a development environment suitable for constructing today’s systems.
Neil White September 2014
// Contents The complexity of every day life Some principles Expanding the principles Conclusions
// Contents The complexity of every day life Some principles Expanding the principles Conclusions
This is my toaster
4
Toaster component materials
5
1. Copper: the pins of the electric plug and internal wires.
2. Iron: the steel grilling apparatus, and the spring to pop up the toast.
3. Nickel: heating element.
4. Mica (a mineral a bit like slate): heating element core.
5. Plastic: the plug and cord insulation, and for the sleek looking casing.
But:
In some cases you need to first create the materials;
In all cases you need to process the materials into components.
6
7
8
9
10
// Contents The complexity of every day life Some principles Expanding the principles Conclusions
Principles
12
1.Try new things.
Some will fail.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
3.Make any failure survivable.
// Contents The complexity of every day life Some principles Expanding the principles Conclusions
Principles
14
1.Try new things.
Some will fail.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
3.Make any failure survivable.
15
16
Evolution or Revolution?
17
Evolution or Revolution?
18
Evolution or Revolution?
19
Principles
20
1.Try new things.
Some will fail.
Use a balance of evolution and revolution.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
3.Make any failure survivable.
Principles
21
1.Try new things.
Some will fail.
Use a balance of evolution and revolution.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
3.Make any failure survivable.
Data Based Decisions
22
1. Data is the only way to make scientific decisions.
We have no space for “I think” or “Apparently” or “My boss says”.
2. Use a structured decision process:
Define success up front
Pick data-based metrics
Continually assess progress against what success looks like
Keep a record of what you have done.
Use Metrics
23
Good metrics …
… are relevant to the team, project and/or business
… intuitive and easy to count
… unambiguous
Example: Z specification change
=> leads code size
Example: Review comments per document page
=> Measures quality going into review.
Use good metrics when making commitments!
24
0
500
1000
1500
2000
2500
0 200 400 600 800 1000 1200
Ho
urs
to
De
sig
n &
Co
de
Lines of change in Z specification.
Correlation between input (lines of change in Z spec) and output (hours to design and code)
Use Metrics
25
Less good metrics …
… sound precise, but aren’t. (So results can’t be reproduced or interpreted)
… are not relevant to progress.
Example: Number of Requirements
=> At what level of abstraction?
Example: Lines of code
=> Can be made good: SLOC with a specific tool on a defined
coding standard is OK.
Principles
26
1.Try new things.
Some will fail.
Use a balance of evolution and revolution.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
Make structured, defensible, decisions.
Use good metrics.
3.Make any failure survivable.
Principles
27
1.Try new things.
Some will fail.
Use a balance of evolution and revolution.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
Make structured, defensible, decisions.
Use good metrics.
3.Make any failure survivable.
Survival Tips
28
1. Plan in advance
2. Structured Risk Management
What could go wrong?
How likely is it to go wrong?
If it happens, how bad is it?
Do I want to try to mitigate in advance?
Do I want to hold a reserve of cash or time?
3. Plan your fallbacks in advance.
If there is no fallback, is it too risky?
4. Monitor continuously
5. Don’t ignore the data if it says something you don’t like!
Principles
29
1.Try new things.
Some will fail.
Use a balance of evolution and revolution.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
Make structured, defensible, decisions.
Use good metrics.
3.Make any failure survivable.
Plan, Plan, then Plan again
// Contents The complexity of every day life Some principles Expanding the principles Conclusions
Conclusions for the Management
31
1. Foster an environment where
trying and failing and surviving is safe (not career threatening); and
not trying at all is considered worse than trying and failing
2. Make structured decisions based on data
listen to arguments presented with data
reject arguments presented with “waving arms”
3. Don’t make demands that the data doesn’t support.
4. Allow experimentation … when risks are assessed and fallbacks well
defined.
Conclusions for people selling me tools or process…
32
1. My default position? I want to try it …
2. Bring data (case studies?) to convince me that your new tool / process /
technique is going to work better / faster / cheaper.
3. Make sure I know how to monitor progress
4. Make sure I can design a fall back
If your tool requires me to throw away everything I know (ie it’s
revolutionary) then expect to be talking about trials or parallel running.
Conclusion
33
1.Try new things.
Some will fail.
Use a balance of evolution and revolution.
2.Know when something is working, and when it is failing.
Stop when it’s failing.
Make structured, defensible, decisions.
Use good metrics.
3.Make any failure survivable.
Plan, Plan, then Plan again
Try, Monitor, Survive.