How should we build that? Evolving a development environment that's suitable for constructing...

Post on 19-Jun-2015

585 views 0 download

Tags:

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.