How should we build that? Evolving a development environment that's suitable for constructing...
34
How should we build that? Evolving a development environment suitable for constructing today’s systems. Neil White September 2014
description
We are building ever more complex systems, and demanding of them ever higher standards of reliability, functionality, and safety. The development environment for the successful project you just delivered almost certainly needs enhancing for your next project. Maybe your team needs to use new tools, new methodologies, new architectural patterns, new process, or just a new language. You can analyse past projects, and research other people's work, but how do you choose what enhancements to make? And how do you deploy new process or tooling in an industrial context where time-to-market, margin, and success are everything? This talk will look at the key drivers behind the successful adoption of any new process or tool - from a small incremental update to a major shift in development philosophy. Along the way we will look at some real-world successes, and face up to a few challenges.
Transcript of How should we build that? Evolving a development environment that's suitable for constructing...
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.
