Get notified about Todd Montgomery & Martin Thompson

Sign up to a email when Todd Montgomery & Martin Thompson publishes a new video

so when we started out you know both of
us were fairly idealistic in our careers
you know we started out with the idea
that you know things should be all nice
and clean right design
I come from an electrical engineering
background you know so I was thinking
that you know things should be awfully
cut you know clean and there everything
should be nice and organized you know
and you know even software should be
this way you know because this is you
know this is a fairly mature discipline
even after you know 50 years or so yeah
like we're basically idealists we like
to see things nice and clean this was
kind of my view coming out into the
world I expected to see servers that are
all beautifully cabled all nicely done I
expected to see software done really
very well and I can hope that would be
the way the world is but this is
actually a lot more what was the world
that I kind of come out and appeared in
in an evening it's worse than that yes
some systems are absolutely scary and
this is not just random things picked
off the web over ten years ago I joined
a start-up and we had a server room and
we went into that it did not look
dissimilar to this we had no idea which
machines had which IP addresses the way
we worked it out is we wrote some
software that tortured the disk and we
run around listening to the different
servers to work out which IP addresses
were which machines it was that bad but
it didn't it's worse than that you know
sometimes we're even proud of certain
solutions you know if you look at some
software and people are doing these
sorts of things and they're proud of it
almost we should be ashamed of some of
what we do in suffer this is crazy stuff
but let's look at how bad this can
really be for our industry let's look at
some metrics so what are we looking at
here sort of successful challenged and
failure so a successful project is a
project that succeeds on time budget and
return on investment a failure just
feeling on - I'm challenged is feeling
on one what do you see yeah when we look
at some of these numbers I think there's
a couple things that stand out the first
thing is is that you know from the
difference between ad hoc and iterative
and agile there's not a big
reference I mean there is definitely a
difference but it's not that big you
know we would think that there would be
a much different you know and there and
that would be much different compared to
as much as we talk about agile and how
bad we usually put down waterfall it
actually isn't it's kind of trailing but
hey it's not that bad but when you look
at the failure rates you know even agile
itself twelve percent you know is total
outright failure that should be somewhat
surprising to us yeah let's look at from
the other dimensions look at it by team
size like things are actually quite good
with small things but it starts getting
rapidly bad as teams increase so to cool
for a large teams this is not a good
thing to look at and as these teams get
larger the difference between approaches
actually stops mattering you start
converging our point where the failure
rates are almost likely to happen and we
think about that you know there may be
something to Amazon's - pizza rule right
where you have small you know smaller
teams that are doing much more you know
this this kind of lint lint some
credence to that yeah so those were some
of the good studies it can get worse
than not here's one from the Standish
cast report in 2010 where we're only
looking at less than a third of projects
succeeding this is not a good place to
be you know we wouldn't want to get on a
plane if there was a 33% chance that
we're gonna get there right let's think
about that for a moment so you know we
should be thinking about that in sort of
the same situation let's look at if buy
money as projects go up in cost the
likelihood of failure is going up in
cost as well this is again not very good
what if we go to some of the largest
good so this is like a typical corporate
project where you're spending through a
15 million plus here's a study of over
so fifteen hundred are five thousand
four hundred projects and we're getting
to the point where 70% go so badly they
have threatened existence of the company
that undertook them now we're not just
talking minor failure we're totally
taking out the company this is not a
good place to be and this is a 2012 so
this is this is recent stuff and we
think we're getting better at this so
what I'm gonna do here today are
industries in a bit of a mess we can't
have arrived then this is to idealists
we keep seeing there's a lot of sacred
cows it's a lot of dogma there's a lot
of ideology going around in our industry
we want to take on some of those
subjects and so don't pick some holes in
them and see if there's any sort of wave
forward so it's pretty since in Chicago
and sort of you get a good stack run
here let's cut up some cows so let's
start off enterprise software this is
nice and easy at this end let's look at
the word itself yeah when you think of
enterprise software do you think of
things like difficult and you know many
people and dangerous and new ways of
doing things but that's actually what
the term works like but if you think
about it a little bit different in terms
of enterprise actually it makes a lot of
sense yeah especially maneuvers we're
going to kill the company that we're
actually working person that the
enterprise is a good choice here so this
new mean really modders and it's a theme
that keeps coming up on our industry
nîmes program behaviors we need to think
about that since its own name it is one
of the hardest problems in our industry
but we still don't seem to crack it we
need to get better at this example ease
the architect
yeah the architect you know especially
the enterprise architect right sort of
setting up on high going the bow shout
use IBM thou shalt use Oracle things
like that and you know a lot of times do
they actually do any code do they
actually contribute you know to a
project and on fundamental you know
physical way by actually building part
of it sometimes yeah but ever
increasingly that's the role that
architects are being pulled out of you
know they're making decisions and
designs but they're actually not
following through them building yeah so
Dave Mirra pointing into gee snow
something that we both care passionately
about is open source I think open source
in many ways is a game changer and why
it's a game changer is we get to see
real work so you go back to the
architect example we can go and see
their buildings we can walk and live in
done generally we don't see this with
code open source changes that when it
comes to things like recruitment we can
see other people's code and it can be a
lot better when it's done this way so
there's some wonderful reasons for this
when I was at L max I led our technical
PR program an open source was part of
that one of the most important things to
why we did that
recruitment it wasn't because we wanted
to be altruistic and just give this out
I needed to recruit people I didn't have
the budget to pay them huge salaries I
didn't have the equity to give our stock
in that way so what was the best way to
get good people into the company we'll
show them that you do good things and
sure they're good working on great work
and that's where the disruptor and other
stuff came right from we just wanted to
show that you can do good things in our
it was probably the most successful
thing we did for recruitment it's a
really useful technique and it also has
another side effect you know the light
of day gets rid of a lot of sense right
when you have your work out there and
you you know even after the years that
open-source project and it's still up
there you know in in Google code or
github now you know different things
like that you know your work lives on in
that way and people can look at it and
they can you know see if you've improved
you know and it even goes to the part
where open-source projects are actually
part of you know your resume now right
someone can go to github and see the
different projects you committed to and
look at your work I mean there's
actually even organizations that
specialize in finding people with
specific skills by analyzing you know
your their github contributions so you
know it's awfully hard to hide anymore
oh it's brilliant I had this one email
about two years ago it was hilarious
some one guy sent me this email subject
line was you're a fake oh this is gonna
be good
I went in this guy looked at your github
history and some of the stuff that you
do early on it's really not very good ok
it looks ok later on I started thinking
does this person not get what learnings
about we actually make mistakes we get
better with time
I said you see there's something broken
in our industry we think we're gonna be
all this upfront planning big design and
we're gonna be right well we're not
that's part of the reason we've got a
lot of these failures that are out there
let's go back to the enterprise software
thing for a moment so product managers
you know a lot of times in an enterprise
software organization act as a surrogate
you know for the customer you know they
sort of filter what is coming in from
the you know the from customers in the
field and they are also the ones who a
lot of times you know message back to
the field you know the sales team do we
really want a surrogate for the customer
I mean I've always thought that you know
I'd like to talk to the
itself and get that straight from them
because I don't want a filter I want to
know the good the bad and especially the
ugly no yeah I want to get out there
I've done it all sorts of weird things
including set on a desk in the service
center taking calls when I was writing
service center software you get to know
what it's all about you work with the
people who actually use yourself and you
learn a whole lot more like we talked
about the minimal Viable Product it's
like to build these things that are just
the minimum viable thing like most
people too are picking something no one
wants as an annually want to make
software that's excellent for the end
users okay we want it to be the smallest
slice of what's useful for them but
let's make this excellent I think I'm
also part of the anti-pattern here is
the product owner we're gonna pick a bit
on our gel here because like what I keep
seeing is a pattern happening in the
real world we got product owner in the
team what is the product owner the
person that the business can do without
that they can give you your project yeah
gonna be telling you the exact right
thing to build not a good place to be we
can say go back you're going the wrong
way with this the thing is technologist
we are part of the business we have this
problem of the vámonos and it's as much
our problem that's not we are just so
subservient to the business we've got to
get out we got to work with them we've
gotta help them we're gonna stop using
these terms like we are solving their
problems we're fixing things for them
where we should be working with and this
is the programming behavior by using the
words we got to think differently about
this and we really need to take
responsibility for ROI ourselves right
we need to actually look at what the
investment is see if we it's how we
would want to spend that money right is
it really the Minimum Viable Product it
big or is it gonna be the product that
we actually want to build right and
that's why we need that access to the
you know the customers directly it's why
we need that type feedback cycle you
know so that it's only way that we can
do this is actually by having that it's
kind of interesting so why are we doing
this and why we'd so making some of our
decisions I keep seeing this over again
people randomly trying stuff on they're
just wasting the money if the company
the wasting the money of the project you
should be looking at
what do we want to achieve what answer
do we need to a question and how do I
find that out for the minimum investment
these are ways you could be thinking if
you want to get on well with the
business and actually start solving
things in the right way so sticking in
the latest piece of technology that
looks good on your resume are good on
your CV is not solving the problem
unfortunately we were living in this era
of what I call resume driven development
and it's partly the problem to do with
our recruitment and how we go on about
it we don't look for people who solve
the the real business problems and come
up with solutions we look for who's got
such in such a framework and such and
right way to be going if you were
spending your own money you'd do this
differently Oh a job to pick on this for
a while so a lot of times you know agile
is sort of done as a way of playing
house and you need some adult
supervision right sort of go through the
motions doing what you're been told you
need to do not really sure exactly how
to do it well if you kind of still go
through the motions and try to make it
seem like you're magic I keep coming
across teams like this and they really
do look like they're playing house
people are going through these motions
but what are they actually doing what
are they're trying to solve like this is
a really good pattern if it water scrum
fall so what people are doing is they're
having the daily stand-ups but they're
releasing once every six months or once
a year they've got nothing that's doing
the feedback cycles for them they're
just playing these games because again
this resume driven development we've got
a look at what really matters here and
what our job is about and leans about
underneath it's actually coming from the
scientific method it's about focusing on
how we learn it's focusing on the
feedback cycles it's focusing on
outcomes it's not focusing on the daily
if the daily stand-up is not getting you
closer to your right cup you should not
be doing it your people
we mostly dearly stand-ups know you
don't have to do daily stand-ups if
they're help you get to your end go do
them but you should be focusing on what
your end goal is and that's what's
important with the likes of our job
focusing on those outcomes but there's
an uncomfortable truth that we all know
about the development and especially all
of us that have worked in even you know
small teams and it's very true in large
teams yeah I consult all over the world
I've consulted in many companies and I
keep finding this same pattern happens
over and over again is one or two people
are responsible usually for the success
of a software project and it's got
nothing to do with the stand-ups it's
got nothing to do with methodology it's
one or two people are willing to do what
is necessary to get things done yeah and
it revolves around passion and pride a
lot of times right or even just
frustration you know a couple meetings
are happening someone gets or even you
you get frustrated that nothing's
happening and you just take it on your
shoulders and do it
I mean we've all been there right we've
all seen that or you've all been that
person and that a lot of times is what
separates a good project from a mediocre
project pride passion and just the
desire to get things done tell it was
definitely being that person I remember
a couple of years ago talking on skype
we've worked together sort of
independently but we haven't worked in
the same company together and we're
chatting on skype at Wednesday's in
Todd's telling me about how he's in this
bug triage meeting and how they're all
discussing how to solve the problem
planning into the future and he just
solves the problem in the meeting by
actually the good thing that laptops and
Wi-Fi is you can go to some of these
boring meetings and actually get some
real work done I where people just play
a house you've got to just focus on
solving the problem itself
it's kind of interesting so all the
things I have done a lot is recruit
people and you'll get all the normal
nonsense about how you recruit in my
mind there's always one question and
sometimes I ask this question directly
of people sometimes I do it in a run of
art thing what do you want to know from
people as if they weren't on that
project or there weren't in that company
what would have been different
how did they make a material difference
and not usually tells you a lot about
how do you find that person that makes
the difference the person that actually
matters yeah and it's not only what they
say it's actually how they say and yeah
and in the tone and the facial
expression and the body language and all
that gives you a definite sense of a lot
of different things just from that one
question hi
we can going ya know so we've got a lot
of manifest those who've seen the agile
manifesto like there's a bit of an
interesting backlash against going
through our waterfall project there's
lots of other things coming out and lots
of other things we've been kind of seen
just recently we've seen the no TCP and
I think Todd had some views on that when
he seen it yeah the no TCP manifesto is
is really interesting in pretty you know
presents a lot of things that I totally
agree with and there's a few things in
there that are definitely sarcasm and
satire but there's actually really good
pieces to it so there's you know there's
some good and some not-so-good
questionable parts you know but there's
also the reactive manifesto which you
had no small part in I didn't intend to
get involved in it all those kind of
interesting getting involved in some of
these things because what kaksi came out
to me why did I get involved in the
reactive manifesto there's a lot of
foods kind of mute a little bit of
history I got a background of martial
arts and I chained in Jake Hadid which
was Bruce Lee style but what was kind of
interesting is Bruce Lee was famous for
innovating in martial arts more than
anyone probably in history and how he
moved stuff forward but he didn't focus
just on innovation to begin with and he
used to get really frustrated with
students who just wanted to learn the
Silver Bullet the magic technique
whatever it was gonna be what he made a
really strong point off and to the point
where he actually got rid of all of his
students except six at one point which
you've got to focus on mastering the
fundamentals before you then start
playing with things before you start
changed things before you start doing it
differently we are not doing the
building on the shoulders of giants in
our industry it's something we've gotta
get a lot better at and also the idea of
you know sort of fake it till you make
it it's kind of antithesis of this right
you you really can't fake it when you
let the fundamentals but you can't
really do that and move forward No so
let's just get into a bit of actual
technology itself it's sort of rent a
little bit but the software stuff
technology itself keep seeing shared
mutable state we build systems we have
lots and lots of threads and we've
trying to protect this with locks and
all this other sort of beauties and
stuff like this
but this should be one of the most
feared things we have
our industry some people will tell us
the way to do it in fact it's the common
way especially in job or we we play with
this shared mutable stay at all of the
time yeah and and when you think about
this you know we have compilers that
reorder statements we have CPUs that
we have memory models and everything
else that make this hard when you have
multiple threads that are trying to
access the same thing it's very
difficult to actually reason about and
it's even harder to enforce you learn
nightmare even with really really good
people and I've helped on a lot of these
sorts of things and kind of like
obligatory of cute cat picture for a
second it is like herding cats when you
start having multiple threads repeating
the seams theater I have not come across
any multi-threaded program where people
are mutating seems to be it that isn't
bug-ridden and I mean that by even some
of the best people in the world this is
just such a hard thing to do people head
off down this road they create
multi-threaded programs they all start
banging on the same theater and after a
while you just look at the code yeah you
feel a little sheepish when you look at
it get a little uncomfortable because
you're not exactly sure what's going on
it's hard to reason about these in a lot
of times they only get more complex as
you try to add things to them it's it's
a total nightmare I'd argue shared
mutable state should only be used by
system programmers and people may even
put a forward a case like I had this
great discussion with guild before he
goes yeah but what about a cache do you
want to have a normal programmer on a
project developing a cache since it's
probably one of the hardest problems in
computer science that is system level
programming as well I have not find any
single example where you'd want shared
mutable state being manipulated by
people on the same project and it's a
good idea this is a normal business
style project it is a system level
program reading problem and if we think
about this from you know sort of
Conway's law right would you want a
whole bunch of things that are you know
being manipulated by different people
within the organization as well no
that's not going to work from the
businesses either well Natalie so what's
the answer well there is other
techniques we can look at soon as I got
panned only structures we can have
single rider
shared-nothing designs are the answer to
love it this is how we work like all the
people in this room we don't have
a single mind that were alternate we've
all got our own copy of the world from a
modeling perspective and we all
communicate by passing messages there's
a lot to be learned from nature and how
we do this we don't you shouldn't be
inventing these silly things that we
keep doing in a computing world which
just our very own natural I'm because
there are not so we can't even really it
to them right and we get it all wrong
and if you don't math will hunt you down
you know that's not a really something
how hard you try no matter how smart you
think you are math will literally hunt
you down across the galaxy it needs to
and you know and hunt you down and make
you you know Val do its will so the
complexity scary enough well what is the
math behind this I guess many people
will have a heart of um dolls law who's
heard of universal scalability law get a
few people that work in the old Gunther
so um doll and is that plan to pebble
mainframes was pointing out that
parallel computing is so hard because
you get contention and with the
contention you got serialization point
and you're limited in your speed up the
blue line here mill Gunther find from
real world experiments that that blue
line was a dream you don't even get
close to it so this isn't this is an
idea of an algorithm where you've got
only 5% of it is the sequential
component you then have to make that
data coherent to all of the parties
involved in it and that coherence has
the cost that has to be included and
after a while the coherence starts to
dominate and you start slowing down now
if we've got shared mutable state this
is the world you're looking at and you
cannot run away from this mile so if the
complexity doesn't scare you
you gotta worry about the math because
we will not go fast so be ruthless in
reducing complexity
you know strive for simplicity strive
for you know the elegance of something
you know because simpler something is
and the less it depends on and the less
it contends on the faster it's going to
go and you're going to avoid you know
the math you're gonna actually be on the
right side of that curve instead of the
wrong side so that's you know both mark
and I have a very good sense of you know
when something gets too complex how many
times have you actually done a solution
and you keep adding things
to it and kind of make keep complicating
it and you get to a point you just and
you stop and you go is this the right
direction how many times do you actually
listen to yourself and go no this is
wrong I have to start over it has to be
simpler than this Marta and I do that
constantly when we're working on stuff
and do it to each other because it's
sometimes you don't realize you're going
off that way and I should be very
careful of pair programming because it's
so easy to drag your paradigm with
exactly the same sort of group think you
need that external influence you know
change it up there is very few problems
that are really complex excuse me we
come up with complex solutions to them
and you find it hard if you're doing the
wrong thing you're going the wrong way
so let's look at something a little bit
more fun Paxton coding we keep doing
this all the time this is the source of
one of the biggest performance problems
I keep seeing in systems where we encode
and all of these wonderful formats yeah
you know timbre is a wonderful
individual and you know we do them a
debt of gratitude for XML we also should
burn him at the stake for excellent you
know XML is kind of horrible in a lot of
different senses you know so you know we
came up with Jason which is you know a
lot easier we we get rid of some tags
and just get them down to a single
character which is great you know but
it's it's it's still text it's still
encoded you know and we even look at
this and if you've ever looked at the
HTTP 2 spec and some of the things that
are actually in there they stood there
still text encoding you know for certain
things like headers and how they're
encoded and using base64 and when you
have a group of people who know the AC
to be one spec and you know different
things like that and are setting around
and are talking for an hour what an
actual respect means for base64 because
of a certain type of encoding that's
been added to it and they can't agree on
the spec there's something wrong very
wrong you know but you know usually
people say well it's human readable so
that you know I can I can read it well
let's think about this for a second its
encoded you then print it to the screen
which decodes it and shows you this you
know encoded information in ASCII yeah
so all these internet protocols we're
basically running an Internet debug mode
yeah yeah woefully inefficient and the
next thing is you know binary is hard to
work with which is always flabbergast
coming from an assembler and you know
and and see background you know actually
binaries the easier thing to work with I
have to actually build a parser which
I've done several times I hate that so
it's a lot harder than just actually
working with binary I'm so yeah shut up
and stop whining right just just do this
it's actually a lot easier even in
languages like Java it's a lot easier to
work with even the JavaScript that's
actually is it or easier to work with
it's kind of interesting so we end up
with all this unstructured data because
we get obsessed with taxed and we've got
loggers that just take completely
unformatted strings so what we get is
completely on format of data that's
unstructured hard to understand hard to
deal with
we have creating this whole industry
around this and this whole industry is
the deal with this big heap of crap
we actually structured this and some
sort of sensible way it'll be a heck of
a lot easier and Dean wouldn't have a
job have you ever actually looked at
what some MapReduce jobs look like on
Hadoop let me explain you pull off text
you convert it into you know binary you
do some operations on it you know then
you write it out in text then you do the
reduced stage where you read it in
convert it from text into binary do some
operations on that and then write it
back as text what I mean really yeah
like what are we doing this and there's
much more to this
so like Todd there was a lot of bit of
iPhones like what happens we put all
these protocols on phones well you want
to keep your device out of a high energy
state and there's actually you know
depending on the device several
different stages so what you want is
something which sends very little data
doesn't have to send you know for very
long and it's fairly efficient well
guess what text is not a very you know
easy way to send you know complex data
think of sending XML versus sending
Jason right it's much much shorter but
guess what it can be even shorter still
that keeps a phone for example or an IOT
device out of a high energy state so
there's no reason to actually use text
encoding when you're thinking hey I want
to extend the battery life as much as
possible do we want to be charging our
phones every day let's don't who are
lazy programming there's a lot of that
problem on why we're doing it it gets
worse stuff you know we we kind of
addicted you know synchronous
communication makes things really easy
we've been doing this for a long time
you know we started with local / local
functions than when you were like hey
you know what we can actually remotely
put these at different places all we
have to do is put some networking
between them you know Henry had our PC
and now we have rest right it's kind of
the same model request/response and
synchronous request response the amount
of time you go back to the 1950s or some
core network at IBM that actually
pointed out that's trying to do
synchronous RPC was an anti-pattern and
it was gonna have this world of hurt
come with it and no one read the paper
and now we're starting to read this
again after realizing I Steven o skied
on a grid talking ahoo so a couple of
years ago were he'd gone through the
whole of the past couple of decades of
his work on Korriban and RPC and not
something and the pian he went through
and in the lightbulb moment that took
him like two year or two decades later
to work it out when he read this paper
we need to be doing things as
synchronous because there's a kind of
interesting problem with this in that if
we assume a remote RPC call is going to
you're just so wrong you're so wrong on
so many levels it's going to feel and
bad stuff does happen and once we've
done this sort of coupling we end up
with this real problem how could a
simple do on this you know it's it's
it's you know it's great right you use
synchronous comms you do something now
you're doing networking and you're all
excited right so you know you get that
buzz and that hi you know the next thing
is you know your you know your family's
having an intervention you know they're
saying look you know this is really bad
for you and you're like no no this is
great and then you teeth start falling
out things like that you know it really
is very addictive you should see the
denial people are in about RPC it's the
same sort of behaviour with people who
have addictions it's wrong it doesn't
it starts off being easier but it just
keeps getting worse and it gets harder
and harder and there's a reason for this
coupling in location in time this is
down to the building on the fundamentals
whereas if we decouple things in the
time and we did couple of men in the
space it makes it so much easier to deal
with stuff we can deal with systems
feeling we can deal with pipelining for
performance we can box we can do so many
great things if we just decouple these
things it has to be a synchronous and
the first thing is is that get out of
you know airs being anything really
special think of them as messages think
of them as an event right when you start
doing this you actually start thinking
about it in a very different way that is
actually a lot easier to handle you know
because an error that happens on one
side but has to be reflected in the
logic on another machine it has to be
handled this way you know if you think
about even go back to you know the way
the internet works with ICMP and errors
and how those work
they are messages and they're handled
just like a normal message by the
infrastructure it's how the endpoints
actually manage them yeah there's a
great study came out last year was
soonly like all of these feeling
projects especially from a reliability
perspective their most common cause of
failure in large-scale projects is pure
exception handling and then a lot of the
studies that were showing the exception
handlers were empty and never tested
whereas if we make errors first-class
things and we pass them as messages we
just deal with them this is where things
like our axe is really good because we
define how we deal with the messages I
only have to define how we deal with the
errors it's just there it's in your face
it's a great way to be working so the
question is really if you're thinking
about and you're doing micro services
and you're distributing things around
are there are they on meth I mean that's
a good question right are you relying on
the synchronous comms you know to
sympathises so supposedly simplify your
logic and or is it just sort of making
it look like that way yeah so who's
doing micro services with rest
you haven't fun yet
so things that should have been together
in a monolith we're not breaking apart
who there's good reasons to break them
apart we'll see you break them apart you
need really good communications and Rast
will ecology - couple on this it's
actually bad another than RPC but it
still is a synchronous protocol for
dealing with these things
you go to messaging is gonna get a lot
easier especially we start moving
forward to the micro services let's go
back to that architect thing again and
you know abstractions you know we even
have sort of a law around you know leaky
abstractions right and we kind of think
that you know almost all useful
abstractions and I wouldn't even say
non-trivial are to some extent linky and
this because of Joel's both C's pointed
here is the detail of underlying
complexity cannot be ignored this is
really funny in that it actually shows a
fundamental misunderstanding about what
abstractions are so we have to have a
law to describe them but wrongly a much
better way of looking at them is even
look it's Dijkstra's opinion and the
whole purpose of abstraction is not to
be vague if you're not vague you won't
leak out because you should be creating
a new semantic level in which are
absolutely precise Dijkstra said this in
1972 is cheering acceptance speech most
people in this room were probably not
even born in 72 yet we're not learning
we're playing with these sorts of
abstractions I think there's something
else going on to why we're doing this
with abstractions and why people are not
understanding it we're because they're
committing these sins yeah we're kind of
committed to building up these baroque
architectures and these baroque
solutions because sometimes it makes us
feel important that only we understand
it sometimes it's just we want to show
off you know and sometimes we just it
got complicated because it to solve the
problem it got complicated yeah this is
a danger of smart people in computer
science they want to show off how smart
they are even worse smart man in
computer science we want to kind of
leave a legacy I'm gonna leave their
seed in some ways and we end up with
these baroque things and this becomes
part of the problem
a really good example is over Alice I
hear the Warrens you take two perfectly
good models you've got object
orientation and you've got set theory
and you couple them together so neither
of them can do a good job of what they
do and we use the excuses of all I don't
need to understand the data pier so
don't need to understand sequel if you
you should not be using a database and
it's not hard trying to work out the ISA
Turek properties are high brilliant and
what a dozen weird scenarios is a lot
harder than understanding some basics
out there in using these things properly
yeah and also think about the other
reason why our arms are a lot of times
used you know you use this so that you
can have a model which is usually in
some specialized language because you
want to avoid sequel which is a well
understood and well documented and you
know has actual
theory behind it language that separate
you know supported by lots of different
mean yeah I've seen sequel statements
that are shorter than most you know data
models for ORM s I love the irony of
this so we've gone through a number of
decades of not trying to learn sequel
avoiding set theory we have brought in
hibernate toppling all sorts of other
stuff and we've come around to Java here
and we introduced streams guess what
streams are set theory we've spent
decades avoiding it and then we get it
and we're told that this is the way to
do stuff that is just so thick innocent
people aren't even realizing
then you come on one of my favorite
topics at the moment
oh yes functional programming what is
the biggest issue with functional
programming any volunteers biggest issue
in functional programming functional
programmers and and to be fair this is
not just simply for functional
programming there are lots of different
things where this could apply but it
just so happens that this seems to be
systematic and you know in the
functional programming community thanks
the elitism that seems to be attached
with functional programming just seems
to be so bizarre that's out there
there's superiority and you can see this
so much to make so people say the study
and functional programming University we
had this really good quote from last
year where you can if you do all the
basic courses and then you get a choice
because when you complete on the basic
courses you really like the next thing
you're gonna do is solve the performance
issues because functional has got some
serious performance issues especially
you want to be completely pure so you've
got a fork in the road here and what you
can do is you can go to the courses
where you learn how to do the right
things and use the compiler and use the
systems in the right way or you go to
the other course which is 101 abusing
people online and this seems to be
either way and most functional
programmers go and if you look at some
of the forums it is just staggering some
nature and the put-downs and attacks so
these guys could be the warm-up act for
gamergate it's just ridiculous and that
we keep hearing things like functional
programming is gonna solve the
multi-core problem I got a simple
question to that hi how a dysfunctional
programming solve the multi-core problem
and usually one of the things that gets
thrown back is software transactional
memory well guess what it's a field
experiment one of the things we've got
to learn from ODS our feedback cycles
everything is where's the experiment and
show me the proof that it actually makes
a difference because remember this graph
you use software transactional memory
that red line is coming to get you and
notice it actually gets worse I mean
we're at the point now we're you know
32-bit product 32 core processors are
you know very attainable and as that
keeps going and actually is getting
worse so if we were to say hey you know
software transactional memory is awesome
we're going to be using it we'd be on
the wrong side of this and just
wondering why yeah if anybody wants to
come and chat about its not very
helpfully talk but basically if you
increase the complexity the model the
number of the threads are the size of
the search space that you're dealing
with you will keep going further down
that red line it is not the answer in
goes the wrong way and what's even worse
is a lot of the data structures and
stuff under this have no mechanical
sympathy they don't respect access
patterns of CPUs they do lots of point
to chasing lots of data dependent loads
they just do not perform in how their
work and so when people say this is all
grid there's a lot to be said about it
and so with the sort of bashing out of
the way the other thing is it's actually
great brilliance and functional
programming so I like to bash it but I
also like to use it and I like the
battery because of the dogma and
religion that's around it not because of
that it's fundamentally wrong just like
anything there is no perfect solution
that solves every single problem there's
some good bits there's some bad that's
that are not appropriate there is some
genuine brilliance and I would recommend
anybody here just a lot of comparative
or procedural programming to go learn
functional programming you will become a
much better programmer and there's lots
of great stuff in there just leave the
dogma aside and leave the superiority
aside because that's not a good way to
be working and collaboration is a great
thing because you know bringing things
from different disciplines and different
points of view we'll touch on this in a
little while as well is really a
strength you know so you know while we
bash it a little bit you know we both
actually do a lot of functional
programming you know it are in our way
we you know get rid of a lot of shared
state we get it rid of a lot of state
that we have to hang around we see what
we can do without having not have a lot
of state around and also to some of the
data structures that we've used
especially in air and have been very
much influenced by functional
programming yeah some quick persistent
data structures are wonderful things we
need much more research on how to make
persistent data structures performant
then we're in a really good world and
unless people admit with some of the
issues are with the structures we'll
never get to the performance side and we
need support from our wrong times and
support from our compilers to do this
well and this actually relates to it
into the other thing is like this whole
Dogma but we'll throw Hardware out the
problem I keep seeing this this is
something that's starting to work
incredibly thin now we can't just keep
throwing hardware at the problem it's
it's free lunch over time
yeah we can't we can't be slopping
anymore because Moore's law is is still
continuing but it's continually in a
different direction than we anticipated
so turning Hardware at it you know
doesn't make it doesn't make it
necessarily make things faster unless
it's been designed in the right way to
take advantage of that hardware it keeps
a simple example inside our modern CPUs
when we're processing instructions we
have an l0 cache most people are
probably aware of their l1 l2 l3 no
nowhere there's actually in l0 the
purpose of why we've got an l0 is not
for performance it's for par saving so
our Hardware friends are constantly
trying to see of energy and how they're
working so rather than going out to
other caches look at this small cache of
decoded operations so they don't have to
keep decoding instructions over and over
again and there's only 1500 decoded
operations to be in there as microbes if
your loops fit into that you get much
better performance than if they don't
in fact after that there's even smaller
buffers with a live branch buffers that
can only hold 28 microbes and if you
don't fit into that your loops won't go
quite as fast as they could do and
there's also other little things like
you can only have ear branches in a loop
have an exception in the loop to take
advantage of those loop rounds buffers
the grid thing is if you write simple
composable code it goes really really
fast so if you've got a loop to do a
purpose quite often it's worthwhile
going over and a set of data once and
doing the action and then going over it
again and doing another action rather
than trying to do the two at the same
time not less in counterintuitive quite
often that is the faster solution it's
also easier to pass easier to reason
about all really simple
I am ruthless when it comes to
separation of concerns single
responsibility principle these sorts of
things anybody that will work with me on
Noah I almost get crazy about it but it
makes so so much easier understand so
much less complex it also typically
makes it faster there's some times where
it won't and you need to measure to find
that out but it should do it based upon
measurement I keep seeing people like
long code in like oh I'm passing this
dude anywhere that will be faster just
the assumption of thought will be faster
adding complexity for a broken
assumption I should only ever be done
based on measurement so code should be
as simple as we can make it and no
simpler and it should be composable we
should do very simple things this is
actually one of the things that
functional programming does talk about
you know making these things very simple
making them for it very composable but
it goes beyond that you know even good
object-oriented design has simple and
composable at its heart here's another
scary picture this is your typical cast
subsystem in one of our modern servers
within a core we have layers of caches
we've got that little l0 cache up there
at the top all of this the scary
pictures not that you need to know this
is the important thing that comes around
to understanding abstractions it's not
understanding that detail is what
abstractions does this have to use it
right and what you gotta learn is the
patterns of access really matter and
locality really matters in your code so
what does that mean well if you go
through data structures in a predictable
way the hardware can prefetch it for you
if you're gonna use stuff together keep
it together so one of the things that
I've done a lot when I get to understand
code bases I come into a company discuss
their performance problem one the first
things I want to do is actually imagine
everything but also could feel for how
it all works and understand it typically
your feel for it is I'll go through and
I'll refactor a code base refactoring is
usually a way I get to understand stuff
and I'll find this feature in vien
fields or in the wrong classes are in
the wrong structures and CEO whoever it
happens to be and so I'll just go on a
tidy and exercise like this property's
been accessed from that class all the
time it should be across there and also
basically refine the model to do that
and just make stuff simpler and easier
to understand and usually run a
performance test after that again just
to see what difference it makes on
complex projects I typically find I get
about a 30% improvement in performance
just by doing that exercise cleaning
things up and why has that made a
difference because things that you use
together are capped together whenever
you've got the fields in the same
structure that are used together they're
typically in the same cache line in the
CMOS page and these things start to
really modern art up
they give you a nice simple claim code
but also they're fast the way that you
know I mentioned that the way Moore's
law has gone is kind of different than
we expected processor speeds they
haven't changed very much in several
years bandwidth in all kinds of
different ways has been following
Moore's law latency has not you know
speed of light it's not only a good idea
it is the law
latency isn't gonna get much better
doesn't matter if you're talking about
networks that are on chip networks that
are you know spread out all over the
world bandwidth though and capacity
increases which does mean that how you
take advantage of it
is going to is different designs have to
be slightly different than they were
previously because if they're not they
can't take advantage of the hardware so
if you put some hardware and it's
throwing it at it you see no change it's
not just memory you'll find this pattern
repeats on many different scales you
find so many things in our industry are
fractal so it's network bandwidth the
storage capacity memory capacity number
of cores but the response time for many
things don't make much change because
physics is coming into it you need to be
aware that this stuff really really
matter it's like we're looking at CPUs
per core are probably getting five to
ten percent faster per generation
networks are doubling or even going up
an order of magnitude between
generations that bandwidth stuff is just
changing so much I still see people
compressing theater on a local line and
you think why you're wasting all our CPU
time and this network isn't even coming
close to being used correctly it's being
aware of what matters so what does this
mean for software and I kind of like to
use an analogy for this herb bus they
make the a320 which is the best selling
aircraft of all time there's more these
been sold to Airlines all run the world
they typically make run about two a day
or 42 a month depending on the
production line to how they're going get
a text two months from order to delivery
when they go to build these things is
about a hundred thousand person ours in
building an aircraft
scratch how do they deliver to a day
when it takes over two months to build
them their pipeline and what do you do
is you break the thing up in the stages
and you have the pipeline continue going
they have multiple pipelines going so
one in China one in the US and they're
doing this and there's a lot to be
learned from this
like this whole shared mutable state and
working on stuff on how complex it is
and how difficult it is to understand it
is a hack of a lot easier to deal with
pipelines when you don't contend on data
you do the same task over repeatedly
with CPUs are brilliant that because
they're hot and cached for instructions
for data for whatever they're doing and
you just pipeline it through and you can
get throughput if you look at most
hardware it's all pipeline installations
that's how we in process instructions so
let's learn from others that build on
the shoulders of giants and sort of do
things at scale like this a better way
to think about it is stop thinking about
your code think about flows of theater
and transformations that you do to data
it makes your code a lot simpler a lot
more elegant a lot more performant and
how it works what subject we're going to
tackle here is something that you know
Martin and I feel pretty strongly about
there's actually quite a few people that
do as well it's about diversity in in
our industry we're not a very diverse
group you know but it's even worse than
we think yeah I think a lot of the
previous problems that we have are the
result of this we suffer from an
interesting form of TDD and it's the
most obvious one where we've got a
diversity problem there's also other
we've gotten even touched on but I want
to show some stuff because we've got
some real data on this here and it's
kind of fascinating and it shows how we
have restricted some of our thinking
this is an interesting survey showing of
a number of graduates from different
programs that are female so if you look
at that graph the red line is computer
let's graph here the hell out of you
certainly scares me because you know
there's when we start to think the same
when we start to you know not challenge
you know accept an alpha male type of
way you know we really restrict what
kind of solutions we come went up with
and that means that the innovation that
we have in our industry starts to
decrease and so with that decrease in
that line we should also think of that
as that's potentially going to stall
this as an industry at some point but
that's actually continued Dunnigan that
Plateau was actually a good thing that
attacks two got worse and stuff and that
red line is nerd in engineering and
mathematics as well but if you look at
things like law medicine all sorts of
other difficult subjects we're
approaching 50% it's the right thing
what we should be saying so we've got a
fundamental problem here this was from
comic-con eggy melon who done this study
and what they find was fascinating so
they went back to the 60s and in the
went to 1984 without turn down happens
is half in 1984 what they discovered was
when people were coming to university
some people were starting the course and
people don't terribly and one season
terribly tempted to drop art and a lot
of these people who done terribly did
amazing in high school like took top in
a class in mathematics top in the class
in different sciences and some of the
people who done really well weren't
necessarily those sorts of people so
they interviewed the more than with the
interviewed right through the couple of
decades to find out what had happened
and what they discovered was there's
this concept of they're called the haves
and the have-nots and around the
beginning of the 1980s we started seeing
the personal computer being available on
people having computers at home and the
haves with the people who grew up with
the computer at home and whenever they
went on these computer science programs
they had already got the the basics of
programming so there were a kind of leg
up and they could go quite quickly what
also they discovered was the marketing
around all of this was targeted hot
white meal teenage boys and as a result
they had got the computers and all the
rest lost out
and things like candy and other places
were and RadioShack were marketing out
this group and we ended up with these
with this problem so when we got
university these people were doing
really well and everybody else was
struggling so Kenickie mellon had an
experiment they find out if people had
this experience by competing at home and
those who didn't and the ones who didn't
they put them on a foundational course
and brought them up to the same sort of
level guess what two to three years
later and the people who completed a
foundation course the dropout rates were
the same they were coping perfectly fine
and everybody was doing equally well and
this has been repeated in a number of
other universities so there's kind of
interesting and how we've got into that
what was fascinating was actually the
media we think has caused a lot of this
because the media targeted these another
way weather was deliberate or not but
they targeted these white male teenagers
with the marketing to get those
computers we need to somehow influence
the media I think we've got a bigger
problem of the media like why do people
go into medicine why do they go into law
all these smart people going into these
things because we've got TV shows that
make them sexy subjects to go into and
most of the tack related stuff is the
dorks and the geeks and it's all not
very appealing so we that's something we
can't really fix but I think it's part
of the problem but there's a lot we
learned from this so you know let's
think about this for a moment we have
actually have quite a few extremely
impressive Murrell models you know as
women within our field Grace Hopper she
but basically postulated distributed
computing she also invented COBOL and
she also invented the compiler I mean
every language owes her a debt right
debt you know and well she was also an
admiral in the u.s. Navy too I mean it's
a pretty good career yeah but we're
gonna have to burn her with Tim because
you did create a COBOL yeah yeah well
me ask you a question
who do you think coined the term
software engineering who do you think
came up with the idea of Indian testing
anybody know who came up with the idea
of priority scheduling volunteers on
that can interesting this amazing woman
came up with a lot of those things so
Google recently attacked end-to-end
testing which I think was a completely
bogus thing because they're obviously
not doing it right this is the person
who came up with end-to-end testing this
is a person who came up with priority
scheduling Margaret Hamilton
she wrote the software for the palo
aladdin speciaiiy a spaceship that went
down on the lander went down a lot she
led a lot of software development she
was the director of software at NASA up
until 89 and done some really really
cool stuff and so we did the diversity
of thinking in different ways of doing
stuff so here's a really good example
whenever the lander was going down on
Apollo 11 the bulk of the software was
written by her there was some other
software that was doing radar guidance
not written by her it was controlled by
a switch and the astronauts accidentally
turned this switch on and it started
heating up a lot of CPU cycles and
started generating errors remember I
said who invented priority scheduling
she did because what you've done is she
had foreseen that these things could
possibly happen and if they do happen
she wanted to back off her software to
do the absolute minimum but make sure it
had priority to do what it must
absolutely do like lamb dish craft so
this is one of the reasons they survived
was she invented priority scheduling we
got better right and actually I think no
we understand priority scheduling I
doubt there'd be many man would have
come up with that but she came up with
that because women are great at
collaboration well we're missing out on
some of those diverse options that are
there so there's a lot to be learned and
I think there's a lot we can do here and
safety you know and doing working as a
with NASA and her contributions actually
you know and I didn't know this for
until recently but her contributions
actually did influence how software and
the safety around software was looked at
within NASA and you know so we we oh you
know this woman of a huge debt as well
as Grace Hopper and there's lots of
others personally I know of two
different women who influenced my career
you know quite a bit in AMT Levinson and
Sally Floyd they're in two different
disciplines one instance software
engineering the other one is actually in
networking as a physicist and the reason
why they influenced was because of their
work right and I think if you think
about it you've probably know of a woman
you know within you know software that
has actually influenced you as well
would there be an instructor or it'd be
a researcher or it actually just be a
colleague yeah other the same things why
we became both the bleeding as
passionately when I study computer
science one of my majors was parallel
concurrent systems it's something I do a
lot night today that was taught to me by
Mary snap card she was the first female
to do a PhD in University of Cambridge
in England and she really struggled to
get throwing it done that absolutely
brilliant but also inspiring women to
sort of teach some of their stuff but
the scary thing is we seem to be keeping
those eyes now we got to make sure we
don't have that happen so one of the
interesting things that has kind of come
out to address as people have talked
about the fake it till you make it
because basically so many men just fake
it the full of and they kind of
get away with it and do it and so it's
been recommended that some women take a
similar approach to this the article
figured to make it even go and read it I
think that is actually fundamentally not
addressing the problem we should have
MIT what the problem is and deal with it
that's actually most of us don't know
what we're doing and we need to learn
and we need a work stuff art so stop
faking it and let's work out what we
need to do and dear father who's a good
friend of mine he came up with this law
I remember meeting him about 20 years
ago I was working with me told me about
Farley's law and less as soon as you
realize most people don't know what
they're doing the world makes a whole
lot more sense we can of land separate
whereas we've worked in different things
then we got together again whenever he
worked on Lmax and that's in the day of
high school he's law going and he says
yeah kind of refined it paper
and it is true but we just gotta admit
that we're going to admit that we've got
to learn we've got to do things better
we've got to do these things and know
how we do things and part of it is how
we need to look at how we train
programmers how we deal with it like
coaching and apprenticeships are a kind
of interesting thing I think we need to
do we need to build on those really
solid foundations and stop making a lot
of mistakes that we have done from the
past and the quote something from Grace
Hopper herself like her most important
achievement in her mind is not just the
compiler but what she did for change for
training the young people and there's
another quote from her when she was like
a little in a career and she was sort of
reflecting back and she said you people
constantly come into they do you think
you can do this this is like you say try
it and you got to back them up and then
you've got a challenge and you got to
come back to it and do this ride so we
got to get into this sort of culture and
much better and thinking of ways of
doing it so kind of quickly in closing
kind of no question what we think are
the greatest achievements of the human
race between Todd and I we come up with
to what we cannot believe in one is a
scientific method and that's
fundamentally about how we learn and we
deal things with experimental evidence
and the great quote from me on this is
Richard finance and this is it doesn't
matter how smart or how intelligent you
are if you make a guess and that guest
cannot be backed up by experimental
evidence it is still a guess that's how
we should be thinking about building
software and building on the solid
foundations the other thing yeah and the
second one is the understanding of
evolution right there's a lot of things
that actually come out of this that we
see the system's evolved we see that
they can start out fragile and then get
heart you know more hardened and you
know become anti fragile over time you
evolution and learning experience you
know has tremendous you know advantages
to it you know something doesn't work we
try certain things we harden it now it
does work in it and it becomes much more
adaptable so these things you know we
see this we do this all the time you
know and it is kind of a side effect of
evolution yeah this is done to that
point is like the adaptability the
the is what really matters in getting
that right but don't worry about is so
much like yeah we've talked a lot about
we screw up stuff but I kind of think
we're living in the era software alchemy
this is like going back a couple of
hundred years ago and many of the other
physical sciences we're kind of working
this art so fine let's work it out
the great thing is it's a fascinating
and brilliant time to be doing this and
we should do cool stuff
I don't accept the crap just don't
follow the her don't do the CV resume
driven development nonsense that we keep
doing did the cool stuff and try to do
it right and have fun with it because
it's one of the best jobs you can have
right here and on that will wrap up