Continous Delivery Sounds Great - Jez Humble

( https://www.youtube.com/watch?v=SjVV3xuYKJs )

Model: software = design + delivery

design= unpredictable

delivery = predictable

lean 6 sigma doesn't fit on software ; because software is 2 things

6 sigma tries to get all variability out of a system

great for delivery, not great for design

xp

lean software development

unix

inventor of unix pipe

(2) = microservices

(3) = deliver early & often

(4) = automate, tool based

not new ideas

---

1) "We're regulated"

1a amazon

2011

amazon is heavily regulated

- credit cards

- public trading company

1b) US government: 8-14 months from code complete to live

got cloud.gov certified, only 55 security controls left

fully reproduce system from version control

all info needed for auditing is there:

- which tests were run

- who authorised a run

2 throughput metrics

2 stability metrics

high performers do better on both

no tradeoff between stability and throughput

all different domains

all company sized (startup to mega corps)

---

2) "We're not building websites"

anecdote: hp team was going really slowly

they were critical path for all new releases

this is really bad, but typical in the industry

anecdote: airline needed more time to change a booking system for new seats than to change the seats in the planes

allows single

"how do you do automated tests?"

"we build a simulator"

"you did WHAT?"

into trunc only after automated tests

overnight regression test

not deploying anyway

why would we do continuous delivery?

it changes the dynamics

lean is not about cutting costs

lean is about investing to remove waste

in medium and long term, drives down transaction cost of making changes, so that you can move faster

continuous delivery

NOT about releasing multiple times/day

IS about changing the economics of the software delivery process to work in small batches

• faster feedback

• • build quality in

  • • reduce cost

    • increase quality

    • reduce time to market

---

3) "Too much legacy"

anecdote / demo "gui tests"

test harness

too much legacy == too much complexity

reduce complexity => allows us to go faster

complexity is everywhere

it took amazon 4 years to go to architecture that allowed ...

in that time they did not deliver much new stuff

pattern: strangler application

drive incremental evolutionary architecture change through building new stuff

- don't rebuild the old stuff

evolutionary architecture is never done

goal = reducing complexity

complexity of your operational environment makes it hard to add new features

[ ] Steve Yegge's Platform Rant

he worked at amazon during the 4 year transition to SOA

memo from CEO 'Bezos'

enables:

---

4) our people are too stupid

anecdote: Adrian Cocraft cloud architect for netflix

netflix were biggest users of internet, took 6-7 years to go to cloud

CIO of a random stodgy company comes up to him and asks "Adrian where do you get all these amazing people from?"

Adrian replied: "I get them from you"

It's not the people that are the problem

someone is being stupid, but not the people you think

anecdote: famous story about lean NUMMI (new united motor manufacturing incorporated)

Tesla factory was recent, used to be GM factory, the worst factory, shut down the plant

NUMMI joint venture GM + Toyota

- Toyota wants plant in US (trade barriers)

- GM wanted to learn to build small cars profitably

union leaders convinced Toyota to rehire the employees

training course in Japan

within a year, higher quality cars than any GM plants

the problem are not the people

the system of work, system of leadership and management

lines on ground = timing

anecdote: toyota

non-toyota:

try to put a seat in, bolt it down, don't make it in time, whatever, next

ends up at quality control: "nobody can drive that, rejected"

toyota:

you get 3/4 of the way and notice you won't make it

pull Andon cord, manager comes, helps you

still don't make it? pull Andon cord again, assembly line stops

fix the problem, assembly line continues

later on, reflect how to improve

workers make suggestions, and you get to implement it

you have the power to change your own system of work to make it better

Support engineer group to make / change tools for you

build quality in

as a worker your responsibility is to make sure that when the work product leaves you, everything is great

and you have the tools, the power and the responsibility to build quality in

[ ] this americal life episode about that anecdote

[ ]

machine are in charge of finding problems

humans are in charge of solving problems

exact analogy in software delivery: continuous integration

something goes wrong -> notify

continuous integration certification

- all developers check in to trunc at least daily

- when your tests fail, you get them fixed within 10 minutes

devops research

less rework (proxy metric for quality)

---

continuous delivery = continuous improvement

high performing companies

always working to get better, they never stop

it's part of everyone's daily work

How can I make things more awesome for the people around me.