Software, Faster

Dan North

Recorded at GOTO 2016

oh you're all lovely and you can all
stay um hello good afternoon so if if
you weren't in Molly's talk in the last
session you missed a fantastic talk she
was talking about the agile manifesto
and the difference between being agile
A and all those kind of things which is
great because that means I don't need to
spend the first ten minutes of my talk
doing the same thing
mm although I will briefly so I worked
out for works
um for eight years 2002 I joined left in
2009 and while I was there you know
these guys are pioneers of a lot of
agile stuff really really a fun place to
work had a great time there and and then
I left there in a 2009 and and this is
what happened next
so um so I came out of there thinking
pretty good at software and and teaching
software and coaching and doing all
these agile stuff and and then I went
off and worked with a very good friend
of mine
his name is Joe wolves he's my favorite
programmer he's the best programmer I
know I know lots of programmers he's the
best one and the reason he's the best
one is he manages to write very very
little code okay he writes tiny tiny
bits of code and what he does is I look
at this problem I got a problem here and
he goes what you seen that problem it's
really just that isn't it and you go how
did you do that and he says I can make
that go away with some code you know did
it again right he has this habit of
being able to keep doing that I've known
Joe ferrand in nearly 20 years a long
time and we were each other's weddings
we go back a long way anyway so I'm
leaving thought work so I'm thinking
what am I going to do next and he said
I'm I'm putting together a little team
in a trading firm in London and you want
to come and play and I was like I
haven't coded with Joe for years and
it's gonna be great fun so I went and
coded with Joe and it terrified me and
it reminded me now I know nothing about
software at all and so I'm in this team
the three of us I was the third person
some really unusual things they were
building I mean this is like full-stack
electronic high frequency trading
software so very algorithmically you
know so that the technical complexity in
there is quite deep and you have a user
interface which is a browser that
traders are looking at and traders need
to be looking at correct information so
the UX is very very important
these things are connecting to
electronic trading exchanges so lots of
integration all this kind of stuff and
these guys were able to put together
all right things that even a good team
of people in that company would take
months these guys could do this in weeks
this isn't mad and I went in there I
joined this team and and basically they
were doing it all wrong I never doing
any of the agile stuff you know and I
talk I need to fix them right because
they're clearly they did they're wrong
and and that was sort of one one option
I had another option I had was this is
just a fluke it's going to be an amazing
trip just to watch these guys doing cool
stuff and being part of this team and
and it will be great and then another
part of me said one what if they're
doing something that I could show other
people what if they just by instinct
just because they're good at what they
do have found themselves have happened
across have developed techniques
patterns ways of doing stuff and that I
could show other people and so I spent a
year in this team and I had a bit of a
crisis I've really really struggled with
kind of because my superpower is going
into teams and organizations and making
them faster helping them move and these
guys were really fast and I was like
super powers don't work what am I going
to do and so so then anyway so that led
over the last few years which is and
I've realized I've basically made a 15
year career out of trying to tell people
what Joe does which is fine because he
keeps doing really cool stuff and he
finds it amusing he doesn't go and speak
at conferences and every now then I say
Joe I just noticed this thing that you
do and he goes I guess I do he finds it
quite amusing I'm so fascinated by it
anyway so I started calling this stuff
patterns of effective delivery and um so
Dave Thomas who was speaking earlier
actually I'm going to invoke Davey I
didn't know he was going to be here but
I hope he's not in the room oh I'm in
trouble but now he said he's a wonderful
thing he gets quite passionate about how
badly we've we've we've misunderstood
agile in the agile movement and he says
a dog's about getting started from zero
he says it's been deified diluted and
distorted and I thought that was a
really really good description of what's
happened and this is this is the big a
agile this is the doing rather than
being and all of that stuff so why do I
care about this I care about the fact
that we talk about people over process
but we end up with process over people
okay so new team day one and they get
together and they say right so scrum or
Kanban one or two or three week
iteration Sprint's tooling JIRA
confluence that is it up by the way
what's your name right right we jump
straight in with process and tools and
we forget that these human beings
building software and that makes me sad
and then back in the nineties in fact
when scrum was invented early 90s Jeff
Sutherland talks about hyper performing
teams now a hyper performing team in the
90s is a team that can deliver something
in a season they were aiming for you did
a six-week sprint and then paused and
then you six weeks and then a release 12
weeks that was impossible in 1993 or
very very hard at is very uncommon in
large organizations and so when they're
talking about hyper performing they're
months and that was revolutionary it did
change the industry it happened 20 years
ago right I'm talking about going from
months two weeks two days two hours to
minutes right so I've seen these guys
build of monitoring thing so they said
okay we want to build monitoring um we
should start thinking about monitoring
and we're gonna have a meeting about
monitoring there's at eight people going
to be in this meeting and Joe's like
don't like meetings I'm going to use
that time differently I'm going to
mock-up in HTML what I would like a
monitoring dashboard to look like so
he's mocked it off and it's pretty good
it's got some stuff these like actually
JavaScript callbacks that when they
receive a message they could just update
stuff in this mocked up UI hmm I could
attach a website
to that and have a little server by the
time they finish the meeting Joad
written the monitoring stack okay and
and you know it was only a sketch of a
monitoring stack but it was pretty good
and from there an entire monitoring team
went off and built some pretty good
stuff so this is what I mean he thinks
like that so each of these words I
thought this was quite an easy thing to
describe these patterns of effective
delivery and people go what do you mean
by that patterns patterns is all a
pattern is a repeatable strategy and the
thing that makes a pattern different
from a best practice is the patterns
depend on context a best practice is
context phrases go do this thing your
life will be better if you go do this
thing we all know that doesn't exist but
we also all know that it's a pretty good
way to get started okay so we all know
that when we learn to drive we feed the
wheel through the hands like this yeah
and because that's how we learn to drive
it's a best practice okay and then we
all know that when we drive now we're
like that and I leaned over the knee
hang on just changing the right and and
then policemen behold hang on hello feed
the wheel feed the wheel and so what
happens is best practices are fantastic
for novices for beginners to get people
out the gate but then over time as they
gain context then they're ready for
patterns we tend to give patterns to
juniors to beginners and they go oh
that's the best practice because that's
what they're looking for looking for
rules so go oh I don't use this rule
Andy Hunt one of the pragmatic
programmer authors tells this lovely
story he did of Lee used to run a
patterns workshop and design patterns
workshops they had this book with these
21 design patterns in and they're not
patterns by the way okay the design
patents book isn't patterns it's where
it's idioms for getting by in how crap
C++ is as a language okay that's what
the design patterns book is so they have
a pattern called an iterator right every
other language
has four right well I mean C++ has four
as well I don't know why you'd need a
patent for anyway so lots of those
startups for those patterns us or don't
exist or aren't problems in other places
but so a natural pattern
it has a name so patents originated as a
chat with Christopher Alexander who's an
architect and he wanted to describe
architecture he wanted non architects to
be able to talk about architecture and
talk about designing buildings and
public spaces and he figured that there
was a pattern language that you could
use to describe spaces and buildings and
so then a bunch of West Coast hippies in
the early 90s when this expand tastic we
should I wonder if there's a patent
language for software and they were
people like ward cunningham and kent
beck and linda rising and so it's a
really really wonderful wonderful evil
and so they started doing this and then
a bunch of jokers release the book
called design patterns and kill the
whole movement which is a shame it's
still going there's still people still
talk about patents so a pattern has a
name because then we can talk about it
it has some kind of context where it
works more importantly it should come
with a warning thing where it doesn't
work if someone can't tell you where
something doesn't apply
they don't understand it yet or they're
selling you something or both okay so
when someone yeah so when I talk about
these patterns I say they are neither
necessary nor sufficient they may be
useful I've seen teams trying to fly
these things wholesale and and like by
the book I'm not really thinking about
it and it didn't work for them I've seen
teams doing really well with none of
this stuff so back to Andy Hunt he's
some I haven't started my talk here by
the way um so he's got this class and
he's got these 21 design patterns that
students didn't take any breaks and so
during the first break he's coding away
comes back coding away by the end of
like the second day and is of what you
doing it's really concerned about this
guy and he looks and this guy has
managed to get 17 of the design patterns
into one piece of code so let's see I
got you're nearly there I've got a
iterative flywheel memento collection in
further vivir what right because clearly
more patterns is better right and this
is what happens when people with no
context to get hold of a pattern they
use it like a blunt instrument so Linda
ricing has my favorite description of a
pattern she says if you go up to someone
to say
hey I've got this pattern and it's
really good idea let me show you it and
they show you it and you go that's a
really good idea then it's not a pattern
it's a really good idea okay if you go
up to someone you say hey I've got this
pattern and it's like this and they say
I thought everyone did that then it
might be a pattern you're naming things
that you see okay so I'm effective then
effect is interesting because effective
suggests that you have some kind of goal
effective at what hey this morning I was
talking about the idea of effectiveness
being about lead time to get in some
kind of business impact a lead time to
delivery I care about lead time I don't
care about making lots of software I
quickly that's my purpose what are you
optimizing for are we optimizing for
time to market are we optimizing for
quality maybe optimizing for learning
okay well let's take a look at what we
do let's take a look at our behaviors
because our behaviors will tell us what
we're optimizing for now behaviors or
iterations and sprints and time boxes or
estimation planning poker right those
are the things that we do those are
things that we fill up our days with
network right and all of those things
exist because we're optimizing for
predictability we're optimizing for
planning which is ironic because that's
the thing that worth you know adapting
to change over the thing we spend a lot
time doing right and why we're not
because we're idiots because we're smart
coming up with scrum and XP and crystal
and dsdm and feature driven development
methods most of which some of you know
heard of when we were coming up with
those things that was what was missing
we didn't have predictability we were
just IT was a just a bin that you poured
money into and then some years later
nothing came out right and so then a guy
says this is dreadful we need to get a
new CIO and UCI will come in get rid of
all those not bringing a new lot right
so I've seen what they've done wrong I
figured it out and we can fix it it's
going to take about three years and cost
loads of money what No
so okay so effective then what are we
optimizing for and when we're optimizing
for that what are we trading off again
well he talked about trade-offs in I
talked and it's really really important
to understand there is no free lunch
okay anything we're doing we're trading
off so what I want to do with this talk
is show you a number of patterns um
there's four or five I'm going to try
and talk about today and they cover
different areas of software delivery so
we're going to look at things like
architecture programming habits of
programming team dynamics learning so
those kind of things
okay there's lots of patterns from lots
of different kinds of things um and then
what do we mean by delivery yeah so why
do we write software there's a lovely
quote by a chap called Ted Ted Levitt
professor Theodore Levitt have a
business call says people don't want a
quarter inch drill they want a quarter
inch hole yeah now look at this trail
it's amazing I designed you this drill
it has all these other I don't care I
want a hole in a wall that's what I want
if you can give me a hole in a wall an
easier way I don't need a drill yeah we
obsess about the things we build rather
than the purpose they're being built for
so we want to focus on the business
capability okay so does anyone recognize
this then one know what that's from have
you very happy very impressed if any
others and say it's a nautical chart
kinda kinda it's actually turned 90
degrees so it fits this it's the
treasure map from Treasure Island in
that gorgeous illustration and free oh
so what I wanted was some way of laying
out these patterns in a way that you
could you could read it makes sense so I
have two axes effectiveness going across
and difficult going up so affecting this
how much of a differentiator this will
be how much more effective this will
make you in my completely unscientific
totally biased opinion and on the up and
down axis how hard it is to get good at
this pattern and just again to reiterate
these are not patents for beginners the
bottom left the origin point here is
quite hard okay the bottom of the
vertical axis is quite hard and the
bottom left of the effectiveness is
if okay so go some quite to very and
reasonably to remarkably okay so then
let's take a look at some patterns first
what I want to look about is a pattern
called spike and stabilize so I'm just
just to get slightly ahead of myself
here what I'm expecting to happen is
during the course of the next time in
half an hour or so people are going to
be tweeting dan said it's okay to copy
and paste code and then it's also going
to saying dan said it's okay to hack
code and put it into production and the
slightly scary thing is I'm going to say
both those things okay with caveats
right which is that sometimes it doesn't
work so spike and stabilize then um this
morning I was talking about a short
software half-life the idea that I want
to keep the half-life of my codebase
short that means code in it is either
very new or it's already very stable
there isn't code that's that kind of
awkward middle aged between kind of new
new enough that someone knows how it
works and or well enough established and
documented and tested and all that that
everyone knows how it works there's that
awkward code that sits in the middle gap
where it's just old enough that we can't
quite remember what it does or why it's
there or anyway the way we're using it
has changed over time and and if I go in
to change this thing do I have to also
change that thing and where's the
dependence here with it why does it even
use one of those and what the hell who
plugged maven in over here you know
those kind of things and and so spike
and stabilize is a technique for very
deliberately deciding that code is going
to go from young to old that should be a
deliberate choice so in other words I
write code I start off with a code
that's new if it's going to stick around
I have a way of reasoning about sticking
around so spike and stabilize then
what's the spike it's like this like
question you cannot you can say things
now it's it starts with a mock up yet so
what is a spike anyone talking about a
spike is in agile terms Kent Beck coined
this phrase it's an experiment okay and
it's an experiment in code so that the
- for is that you've got a spike and you
try and drive a spike through a piece of
wood yeah
so all I care about is just can I get
through to the other side it doesn't
matter if splinters fly out and it makes
a mess I can go back and do it properly
time box very good it's time boxed what
else I promise I'll throw it away
scouts honor any code I generate in a
spike gets thrown away promise right
lots of people are shaking their heads
oh you don't keep code to you that's
very naughty right um the point of a
spike is to learn something and so once
I've learned that thing I throw the code
away and then I start again with my
test-driven development and my test
coverage and my pair programming and all
that good things and then I build
production quote code and so building
process than spiking so I'm a huge fan
of real options so real options is the
idea of applying options theory from
trading to real life so in in trade so
an option in finance is a financial
instrument it's the right but not the
obligation to do something in the future
okay so I buy an options like buying an
insurance policy if you like so say I
owe you a bunch of euros and I've got a
bunch of pounds um I can I can well make
me and I'm out and I need to pay you in
September okay so come September the
pounds really weak against the euro
because we've left Europe because we're
and so things going on in the UK at the
moment it's not very interesting it
basically involves loaded politicians
lying to each other and the public and
it's basically business as usual but um
anyway so so I'm worried that in
September I'm going to have to find a
load of money and pay you in Euros so so
what I can do is I take out an option
and I buy an option an option means in
this case is that someone is obliged to
sell me euros at a fixed rate at a rate
that we agree so come September if the
pounds really weak I go ha ha I have
this piece of paper that means that
you're obliged to sell me euros at this
paper at this rate if the pounds really
strong I just throw the paper away I
just buy some euros and pay my debt and
so that's how we use options so when you
look at an option
there's three things you can see about
it the first thing is options have value
okay that contract has a value and the
value changes with time the closer we
get to September if the pounds really
weak this piece of paper is worth a lot
of money if the pounds really strong
it's worthless
and as the currencies change against
each other this piece of papers worth
different amounts of money okay so it
has value options expire so come
September in October I have a piece of
paper this is a month ago I could do a
thing it's pointless
okay and so because of those things the
advice the trading advice is don't
commit early never commit an option
early unless you have a really good
reason okay and and really this kind of
ties in very nicely with the idea of
deferring decisions because you have
better information later and that kind
of thing so I think of the choice to
make a something a spike or production
code that's an option that's a choice
and we make that option right before we
have any working code at all so they go
right before i hatch any code at all I'm
going to choose that this is production
code or Spike that seems odd to me so
spike and stabilize as a pattern says
this it says treat any code as a spike
all code starts out as a spike all code
is an experiment it doesn't mean we
write rubbish it means it would still
overthink it the chances are this code
is likely to get thrown away I'm going
to act as though this code is likely to
get thrown away so I build it and I
build an okay code but there's certain
things I'm going to cut corners and I'm
going to do it very deliberately I'm
gonna make choices about cutting corners
and the way I cut corners is I go to do
okay to do remove hard-coded password oh
that's bad well it's actually not bad
cuz I had a chat with the security guys
and it's a read-only password that goes
into active directory it's a list of
users and I just populate a drop-down
with it and it's just hard coded in
there and they change it every month
anyway so it doesn't matter okay so
remove hard-coded password so what
should I do
of course what I should do is I should
um I should read the password from a
file the file should be write protected
and it should be read only for that user
file with the code and then so to read
the finally to open the file read the
password remove the newline remember to
the file probably put that in a finally
block because her admin admin is what
I'm supposed to do okay it doesn't add
anything to the value of the thing it's
just is just better practice it's just
better hygiene to have passwords in
external places yeah so I put a to do
there that says yeah we know we know but
we want to get this experiment out and
then anyway so I deploy this thing and
again so I'm writing code that I'm
confident to deploy but maybe it doesn't
have amazing test coverage and isn't
brilliantly documented again it's an
experiment okay and then so we run with
this code and then a little bit later
I'm sitting with key term where and
we're pairing on something and then we
do the review of shame okay so we look
through the code we look at all the to
do's yeah and get to that you'll have
two hard-coded password and I tell her
the story because our k4 I get it but
anyway what should we do and so in the
time since I wrote that thing there's
been a bunch of people that wanted that
list of user names and so the the admin
guys have now just exposed it as a rest
service somewhere yeah so it's all I
just replaced all of that stuff with a
get so one-line HTTP GET that's pretty
cool yeah so to fix my to do in this
case I didn't need to do all that admin
I told you about aren't I lucky that I
didn't yeah and so now we go back and we
change the code we put this thing in
there and we get rid of the two do's and
so some of the to do is we go through
and we go we're never going to bother
with that just to don't yeah forget it
and so now what we're doing is we're now
the second time through pays for the
quality okay we're going back to do
something in this code and so we write
some tests around the code and the tests
aren't test driving it to say this is
what we think it's going to be used for
the tests our characterization test my
close calls them these are tests that
say how we are actually using it so they
work as better documentation so we write
these tests and it turns out that to
write these tests we need to move the
code around a bit so we've got this like
the the nested kind of if with a while
and a little for loop in the middle
there and we want to put them in really
that should have a test so we pull it
out and we probably make give it its own
method name and and let's make it its
own class and so as we're writing these
tests we're pulling the code into a
shape that looks a lot like it was test
tell no one right I call this
test-driven testing right right what
happens is and you only get to do this
if you've written loads of TDD code
otherwise you don't have that aesthetic
yet you don't know what that means if I
say it looks like it's test driven a
bunch of people with loads of TV the
experience go oh yeah I know what you
mean so it's going to be fairly small
really clear consistent naming single
responsibilities very readable and I
know what test-driven code looks like so
we move it towards that so we end up
with you know and then Gita starts
getting a reputation right cuz what's
happening now is people gradually notice
that she doesn't write that many tests
but she all of the code that she writes
the tests around that ends up being the
code that we keep how does she do that
right if what she's doing she's firing
arrows and then she's painting a target
around them she gets lots of bull's-eyes
that one yeah and and so and so this is
what we do so it only works if spiked
and stabilized only works if you promise
to stabilize that's your table stakes
okay spike and stabilized is a high
discipline pattern otherwise it spikes
bike hack hack hack hack hack right
there is nothing sustainable in that
yeah so there's I have two rules for
when I go and stabilize something the
first rule is second time back so the
second time back if I go back into this
code to do something with it I start
writing tests around it I document it so
we clearly care about this thing and I'm
going to make it do something else now
anyway and so we pay for the cleanup
then and it's probably not much more
expensive than if we'd done it properly
in the first place we're just deferring
that cost okay the other thing I'll do
is I'll set a timer so I'll say right
okay we've written this thing in six
weeks we're going to come back and
review this thing in case I haven't gone
back to it and so that means that code
doesn't accidentally get older because
remember that's that funny middle zone
code that we want to avoid so I go back
and six weeks time we look at this thing
I said you know what it's just quietly
thrumming away and happily working
that's great
so now let's pay down the debt let's do
what we supposed to do and so again
document it clean it up rights and tests
so over time we end up with either code
that's very recent and spiky or code
tested we're deliberately choosing which
code gets to survive okay like us
these are not patterns for beginners
because as a beginner I don't know what
constitutes good code it's not that I'm
an idiot I just don't have that
experience yet it's not an elitist thing
it's just right loads of code right load
to carry pair with people who write good
code and get a sense of what good code
looks like
make sure 10,000 hours so so yes a spy
can stabilize then is the the governance
if you like that it's the due diligence
around being allowed to put this stuff
into production okay so let's take a
look at another pattern so it's a hair
trigger a hair trigger it's a
deliberately what's the word it should
be to make you slightly uneasy same time
a hair trigger should make you uneasy
and it should so a hair trigger
is the ability of a team to deploy its
own code to push its own code into
production that's a hair trigger hair
trigger like anything else right hair
a hair trigger it should also have a
safety catch the safety cap should
mostly be on this is exactly the same
sort of metaphor so hair trigger is with
great power comes great responsibility
but a team can go very quickly if it can
deploy its own code in fact let's invert
that if the team can't deploy its own
code it will never be able to go fast
you are putting deliberately an obstacle
in its way and a lot of people
particularly in finance go oh
sarbanes-oxley Oh compliance it turns
out messes sarbanes-oxley are actually
quite smart people and Simon's Oxley
occurred and post Enron and people doing
crazy things and mostly illegal crazy
things and what they said was we don't
want to have any lone operators able to
do stuff that makes sense okay and so
you can be sarbanes-oxley compliant by
having multiple pairs of eyes on a piece
of code by having someone else in the
team deploying something that someone
else in the team wrote that's fine you
don't need a massive silo in between
Devon ops right to be Sox compliant
that's not a thing
can have a hair trigger
and with a hair trigger it means the
team can deploy stuff
quickly it means the team can screw up
again this is about being careful right
so when you first start cycling you have
the little stabilizer wheels and that
means that you can't and then as you go
far you know you get better cycling you
take the little things off and you can
cycle now and then you decide you want
to get the carbon bike with the really
thin wheels going to film like this okay
you don't start doing that yeah but you
also you should be able to do that if
you feel safe doing that okay so it's a
confidence thing and it's an experience
thing again so in order for this to work
the team needs to understand the risks
as we move towards a more componentized
world with lots of little pieces
understanding the impact of little
pieces we had in one trading system I
was working on we had a very very simple
bit of code and what the simple bit of
code did was this it connected to a
trading exchange and it said and it's
listened so there's a firehose of
trading messages these trading messages
are super simple messages they basically
have an instrument like an Apple or IBM
or something like the thing you're
buying and they have a side to buy or
sell right whether you're buying or
selling they have an amount and they
have a quantity sorry an amount in the
price yes how many other thing and how
much it cost that's it that's the better
market data message right there and so
what this thing does is it listens to
all these market data messages this
firehose of me thousands these things a
second and it just keeps them in a map
that's all it does all it does is keeps
them in a maps so that at any point I
can say what's the current value of IBM
and it says is this okay great thanks
really simple bit of code it turns out
though that a lot of exchanges if you
disconnect from the exchange and then
connect again you don't know what's
going on and it won't tell you some
exchanges will give you a snapshot you
can catch up some of them down what that
meant was with this bit of code if you
disconnected from the exchange during
the day you were basically done trading
for the day you couldn't now reconnect
there's no point reconnecting because
you don't know what the market looks
like so you can't trade and so that
meant this really simple obvious looking
bit of code if you happened to deploy it
during the day you just kill the day's
trading or
good don't do that yeah and so the team
needed to know that that bit of code you
just don't deploy during the day and
that's a hard thing to remember when
there's lots and lots of bits of code
and so we put a safety catch on that
hair-trigger if you try to deploy that I
said BRR are you aware that did a digit
and because we only had a few of those
it didn't read like a you late yes of
course right so all all end-user license
agreements should have a whatever button
yeah so yeah whatever although I don't
care now I'm just gonna press I'm going
to press ok I'm a liar I'm a liar I
haven't read your I haven't read it but
you can't prove it ok so um so because
we had very few of these actual warning
warnings people would read them so I
guess ah you're about to release this
thing and it has those implications you
know Oh Gladys didn't that'd be really
stupid oh yeah I know but we have to try
this thing out okay so um it means the
safety catch is off ok so it means be
careful so and again so you see there's
patterns for so spike and stabilizes a
programming pattern it's a pattern of
behavior of programmers hair-trigger is
a deployment operations pattern ok um
this is one of my favourite pans ginger
cake so this is a story I heard and I
thought I heard it from one of the
pragmatic programmers at a conference
many years ago and I've asked them both
and they both said nope wasn't me so I
have no idea whose story this is I'm
going to tell you but it's someone's
story and the story goes like this it's
about the Dreyfus model there's a
question I'm sorry I'm speaking very
quickly ok I do this I'm English and I
speak quickly yes I can slow down of it
okay thank you it's a useful feedback so
if I'm if I'm still speaking too quickly
you must tell me okay so the story is
this is a lady who's an expert Baker um
and as an expert Baker she just kind of
she thinks in patterns now well she
doesn't think in rules anymore she
thinks in solutions and so she has this
wonderful she has an index full of index
card recipes and she reads these and
these recipes so this is her recipe for
a chocolate cake this is this is a real
recipe for a chocolate cake that I found
on the internet so please go and make
this cake and
if it tastes nice okay real chocolate
cake let's so you mix the ingredients
together and this is the Unitas says
this in home and then a little bit later
in the same box there's a card for
ginger cake and the ginger cake recipe
looks like this like chocolate cake but
with ginger okay hmm
that there's a lot hidden in that
because ginger and chocolate aren't like
each other at all chocolate is solid at
room temperature and then goes melty and
then burns if you heat it
ginger is squishy at room temperature
it's squishy when you heat it and it's
squishy when you see it's just squishy
right it has a different it interacts
with flour in a different way it
couldn't be less like chocolate right it
says like ginger like chocolate cake
back with ginger but she knows what she
means she's done enough baking with what
she is probably her own chocolate cake
recipe is the first thing it's also um
she and she's done enough baking with
both chocolate and ginger to understand
how those things are different so what
so this this pattern is a pattern for
getting started quickly with something
and when I saw this again this is this
small team I'm working with someone else
now Chuck called Neil and Neil sits down
next to me we're going to build a new
little web component just like another
this component we've already got and I'm
thinking well probably what we should do
is you know to take out the bit that's
in common factor it make it a little
library and and then we know and then
create this new thing I think that's
what that's what Neil's going to do so
Neil sits down control a control C
control V select all copy paste and I
just went that's illegal they throw you
out the software's for that right and
and and he's just thought you should
copied and paste it alone a whole thing
into a new file and then he changes the
name of it and then he just thoughts
deleting like crazy he goes like this
and then he starts I don't what what did
you and then I realized something okay
he got started with this new thing way
faster than I would have we got to
something working way faster than I
would have he was only able to
do that because he was really really
intimate with that other piece of code I
had written most of it
yeah so ginger cake is about using
existing code copying existing stuff in
order to get out the gate quickly again
see this is me telling you to copy and
paste code Oh No right so where do you
use this you use this you only use this
if you know that code intimately getting
something off the internet copying and
dumping a bunch of stuff out of Stack
Overflow is not a ginger cake that is
like just making a recipe you found on
the Internet and thinking it's going to
be fine don't don't do that's like
that's like piping stuff into sudou bash
right no one here does that do they no
that's very yeah because otherwise
otherwise the bash faeries come and sort
you out
no this idiot you that you get the sudou
warning and then you end up on Santa's
naughty list as what happens so yes a
dinger cake then says okay copy and
paste only stuff you know intimately and
there's kind of two variants if you like
a ginger cake there's a structural
ginger cake and a behavioral ginger cake
so structural ginger cake is I've got
something that's the same shape as
copy all the shape and pull out all the
guts okay
behavioral ginger cake is the other
thing is I copy the behavior of
something I've done before and just
changed some of the pieces okay this is
the opposite of dry okay dry don't
repeat yourself and we will think of dry
it dries a good thing right dry they're
a part of solid and clean code and all
that stuff we should be drying code out
it should be removing duplication the
problem is that dry has a dark side the
dark side of dry is coupling as soon as
I introduce as soon as entries and
abstraction as soon as I pull out a
library and I share it between two
components because reuse I've just
coupled those two components together I
now cannot independently reason about
one of those components without having
to think about the implications on the
other one once there are several things
using that library
I can't reason about it and also I don't
know what I don't know I don't know who
might be using the library that I don't
know about
okay so there's risks right dry has
trade-offs dry isn't a best practice dry
is a pattern dry as an approach
which has positives reducing duplication
negatives increasing coupling where I
have small components I want to have
independence of those components I don't
mind having duplication across
components I mind having duplication
within a component that's that's
probably not great but having
duplication across components is fine I
had I do I was running a Python app I
was doing a Heroku ripoff a few years
ago for a company I was working at when
our internal little deployment thing and
there was a bit of code that was the
Heroku that was like the master thing
that you interacted with and it's ran
jobs for you and then there all the
little agents that were running out and
I had the same bit of code in and the
master thing in the agent things and it
opened files and did stuff with files
and I thought I'm gonna I'm going to not
factor it into a module I'm not going to
just going to see what happens with
these two things and it turned out that
the thing that was the master cared a
lot about security and the thing that
was the agent cared a lot about having
lots of files and so these two bits of
code that started out looking quite
similar ended up evolving in very
different directions and if I'd had a
single thing and I was trying to do both
of those with this single thing it would
have been really ugly and really
complicated and wouldn't have done
either of them well and so what happens
is you have different forces acting on
the software um and so I won't suddenly
I when I'm running out of time so I'm
there I'm afraid I may need to speak a
little quickly again I do apologize um
yeah and so they're voting different
directions I have different forces
acting on them and so they're going to
develop differently um so be aware that
it's okay sometimes again not for
beginners copying and pasting code is
fine it's kind of sometimes fine with
certain very very specific constraints
that's like another one shallow silos
this is this is a team pattern and the
point of this isn't go do this it's just
to kind of illustrate that a lot of
choices that look like binary choices in
software development aren't they're more
like a scale so we think about silos and
we think about cross-functional teams
and that's basically your two choices
silo development bad cross-functional
teams good okay there's a massive
spectrum of options so
of the things that we found in this team
once we got to about six six people we
typically had there a couple of people
who were really into the trading logic
and a couple of people who were really
good at UI stuff and web stuff and a
couple of people who are really good at
kind of all the glue and connecting
things up I'm one of the glue people I
love connecting things together not that
excited about trading and rubbish at web
so I was there and you know the agile
rules if you like would tell you that we
do pair rotation and promiscuous pairing
and everyone does everything and all
that stuff it turns out that that really
sucked for a bunch of people in the team
we didn't like doing that but also what
what we called shallow silos which is
like so maybe two people will work on
the same thing for a few weeks or even a
few months right and another couple to
work on something else and that's fine
they're doing things they enjoy they're
excelling at those things the products
becoming really good but we had a shared
stand up every day we'd ever stand up
maybe twice a day now once in the
morning is a tech thing and once in the
afternoons a business kind of what have
we built and and so we're just step out
of a little silo because it's only very
shallow silo and then we'd have our team
stand out let me step back into our
little silo and we're carry on working
yeah so working in that way for us
worked out really well and so the point
of patterns like shallow silos is to
suggest there are other ways of
organizing a team it's not everything or
silos yeah you can there's lots and lots
of options as Molly was saying earlier
try things see what works for you be
prepared to experiment be prepared to
throw some of the stuff away if it's not
working and then um there's one more I
want to talk about burn the ships to
burn the ships is um is lovely it's this
story about the the Spanish explorer
whose name I can't remember
um anyone or thing he discovered South
American was all very exciting and and
and anyways like he's got all these guys
Americans of waiting their anchors or
whatever not anchors and they're quite
cross that these guys have just rocked
off and a clearly planning to steal all
their land and so and so said okay right
what we gonna do and they all well we've
got sort of ships we could go home
and he said right burn the ships
actually he said scuttled the he
said sink the ships but it's not as good
of a story
yeah he said burn the ships they burnt
all the ships what does that do that
means you now no longer have any options
okay with other forwards or swim and so
what do they do they go forwards a
conquer the land rest is American
history so or South American history so
um so burn the ships then is a learning
pattern I am not very good at this but
I've been working with people who are I
to think I practice so again I'm not
good at all these patterns some of these
plans so I think this pattern is very
very effective it's really quite
difficult okay so burn the ships is a
learning pattern when I learn a new
language or new technology what do I do
I probably download it I install it I
maybe look at some blogs and some
tutorials and I make little toy apps in
it until I kind of feel comfortable and
and then I maybe start doing stuff with
it that's certainly what I did with go
and that's what I've been doing with I'm
looking at rust at the moment rusts
pretty cool um so Joe doesn't do this my
buddy Joe what he does is this is he
puts himself on the hook for something
as of well I'm going to build this thing
by this date using this technology right
go and so now he's got going learn that
technology however what it does is it
means that he only needs to know enough
of it to solve this problem so I also
call it indirect learning I'm solving
this thing in order to learn that thing
so he doesn't look at tutorials and
blarin whatever else he's like the next
thing I need to do is this how do I do
this in this language how to do this in
very early adopter of node and and he's
like I know there's nothing out there on
the Institute but no so he just played
he's a plate with it until it did the
thing he wanted it to do
and he built some really useful critical
infrastructure in it that I like this
you're bonkers right he was he's setting
yourself this really hard challenge but
what it did is it meant that he now had
a specific goal le Goldratt in the goal
at the end of the goal there's a lovely
interview with him and he says one of
the questions and brt was talking about
this this morning as well actually about
adoption he says how long does it take
companies to adopt Theory of Constraints
in operations he says it's company as it
is it's clearly works it's brilliant why
don't people want more people doing it
and he says on average it takes between
five and fifteen years for an
organization to adopt a full paradigm
shift as in a different model of working
a different mindset for working
particularly a management level right
five or 15 years and he says because you
need three things to happen you need
some kind of downward pressure like some
deadlines some immutable deadlines
you need to have run out of options you
need to because people will do anything
before they'll shift their paradigm and
over cling on to and the third thing you
need is information it says I'm good for
the third one so what I do is I make
friends with companies then I wait and
eventually this guy comes crashing down
and they go hey Ellie that thing you
were talking about and I go yeah Theory
of Constraints say let's try it now yeah
so what Joe does what burn the ships
does is it you create those first two
artificially you give yourself a
deadline you choose to have no other
options and now you just need the
information so it's a fantastic model
for learning something very targeted
very quickly like I say I struggle with
doing this I tend to I get easily
distracted so I'm just going to really
focus on it's all shiny look tutorials
so I it takes a lot of discipline um so
yeah so there's a few more of these have
haven't got time to go through them
I've actually got a book up on lean pub
called software faster so lean pub comm
slash software faster which I'm writing
very slowly and I keep telling people
I'm writing it very slowly because it
puts me under more pressure to then
write it less slowly so I've got all of
the patterns are outlined there but and
I'm filling in the chapters one at a
time kind of thing so anyway I guess the
thought I want to leave you with the
question I want to leave you with is
this is given what you're doing day to
day given how you work
what are you optimizing for what's the
thing that matters to you what's the
goal of your system of work and is it
the goal you want it to be so thank you
very much
so again eh gamma gave a talk here
earlier today did you have a chance to
talk to him and tell him how he ruined
the meaning of parents for you a peasant
our patterns yeah when I say he's Eric
camera and he's done some really really
really cool stuff so forgiving that ya
know so I mean it is it is interesting
though that we as an industry lost sight
of what the patterns movement was trying
to do there are some very very
interesting people still doing patterns
there are still patterns workshop still
patterns conferences and in fact was
what I've seen as well is that the
patterns movement has moved into
different spaces so a lot of these
patterns aren't software development
software architecture patterns linda
ricing is one of my heroes she's written
a fantastic book called fearless change
ok fearless change is a pattern book for
organizational change it's a pattern
language for organizational change and
she I mean she gets patterns she was a
deep deep thinker in pattern so any look
up al in the writer she's amazing yeah I
mean you know if you're going to have a
go Eric camera it's got to be eclipsed
rather than patent surely right so oh oh
there I go with my art loud voice again
no and again you know people is easy to
beat up on Eclipse and whatever else as
a foundation as a movement so you know
the idea of breaking something out of
IBM and turning it into this open-source
foundation was amazing incredibly hard
thing to do incredibly courageous things
so yeah so I got a mad props to Eric
gamma and I'll let him off patterns okay
why the name here trigger why don't in
hair trigger because I want it to sound
dangerous I want you to be aware that
you have direct line from your keyboard
to production and to be aware that that
comes with a responsibility ok so again
I've been thinking about the names very
much Oh what what is a hair trigger
oh sorry what is a hair trigger so what
is a hair trigger
it's a
type of trigger mechanism on a gun that
means that you can barely need to touch
the gun in little fire
okay so it means that you can fire much
more quickly it also makes it a lot more
dangerous right and so again it's it's
it's only things for grown-ups
yeah and by the same token the the
reason the metaphor is the gun metaphor
is again that you can talk about things
like safety catches you can talk about
things like drills you can talk about
order to be able to have access to these
things so it's again I've been very
careful with some of the naming and the
names evolved you know the name a lot of
these names have changed over time so
I've been teaching this class software
faster for four years now and one of the
reasons I do it is it's basically field
research so I'm learning all the time
from people in the room which is great
fun anymore I think we might be out of
time well what one quick question okay
one new question came in how to sell the
stabilized part of spiked and stabilized
to management how to sell this to the
stabilized part of spiked a stabilizer
management it's probably more how to
sell the spiked part but let's say so
might the the context I was developing
these patterns names in if you like and
doing this working was trading and the
great thing about trading is you're
working with traders and traders
understand risk their business is risk
their business isn't trading right
really good traders understand risk and
happen to do trading yeah so what that
means is when we talk about risk and
options we're saying okay we are going
to realize the value of this software
sooner okay that's that's the payoff and
the cost for that is that we will end up
having to pay this down pay back that
governance that due diligence later and
they say that sounds like a great trade
off to me because that's the job is to
understand what trade now I'm gonna
invest in is I'm not going to invest in
this I'm going to put money over here
and not here so we say you can have this
thing sooner and it will cost us later
if we choose to keep it and that's a
pretty straightforward idea it's a
problem is
when you get into a culture where its
features features features features
mean scrum is toxic for this where you
have this you know you create this
product owner person whose job is to
just demand features which a absolves
the team of any product thinking which
is dreadful and again you can see where
this came from in the 90s we were just
putting new teams together in silos from
you know in cross-functional teams that
never worked in cross-functional teams
before they didn't know what that looked
like and they didn't really understand
how to think in product like a program
it just turns requirements into code and
a tester turns code into bug reports
right no one really knew was thinking
about a product so having someone to
coach the team on product made perfect
play it forward twenty years and it's a
completely anachronistic idea is bonkers
most people in most teams understand
what it is they're building so I got off
into a rant there yes so cool thank you
very much all oh hang on we might we
might be a minute over time so let's see
it's the last one very last question
I'll try quickly let either yes or no
it's this only for senior only teams
also for junior developers no oh so so
interesting so when we first had this
team and this is like a one-minute story
when we first had this team it was very
experienced in a minimum like 15 ish
years and it wasn't a constraint it was
a requirement it was just that the team
happened to have people in it have been
around building software a long time
about six eight months in maybe year in
and we hired two graduates we took onto
two fresh graduates um and I was
thinking they're going to really
struggle with some of this stuff or at
least I was kind of concerned that they
might struggle with some of this stuff
they totally got it they totally got it
because it actually makes a lot makes a
lot of sense right and they're pairing
with developers they're pairing with
people in the team so because that's
just how we roll and so they had a lot
of mentoring and a lot of stewardship
and all that kind of stuff and they got
it and the reason they got it is because
they didn't have any bad habits to
unlearn yet yeah and so they just knew
that I mean it you'd be an idiot to
write something spike it put it into
production and not go back and check on
it surely that's just a really dumb
thing to do
and and that's so they just learnt those
habit unfortunately of course we've now
ruined them for working anywhere else
why are you writing all these tests
right now you haven't even decided what
shut up and write a test oh okay Steve
limit you know so but yes so so um June
so so very so fresh new shiny people can
get it experienced people can get it one
I found is people in the middle really
struggle to unlearn the stuff that
they've been carrying with them for
decades or at least you know a bunch of
years in order to relearn some some
habits to go faster
that's definitely us out of time so