Get notified about Kevlin Henney

Sign up to a email when Kevlin Henney publishes a new video

yet there are actually gonna be no fail
screens in this talk just for variety so
we have this rather interesting
situation and anybody who's been around
for more than a few years and taking a
step back and looked at the trends will
notice the underneath constant change
there is a kind of silent and very
steady continuity and constant lack of
change and so this is the premise here
oldest in you you I find that I although
I'm not necessarily keeping up to date
with every single technology because
that's actually not possible anymore
what I find is that I can actually have
an informed understanding of a
surprising amount of things by saying
what is that what is what is this like
and therefore what are the differences
what are the things I actually need to
concentrate on and you also find that
you're able to then pass on these pearls
of wisdom and do God never seen that
before and you can go yeah yeah it's a
really new idea back in 1972 or this was
1974 and this kind of thing so this is
why don't we explore and Al Rashid it's
quote everything has been said before
but since nobody listens we must also
and we must always start again because
there's something else in software that
we are particularly bad at we have a
very weak sense of history so it is not
simply that we keep rediscovering and
reinventing the wheel and eventually we
might actually make it round
it's that we have a very poor cultural
sense of history and so are in a we live
in a constant state of astonishment and
rediscovery and I'm not saying that
that's necessarily a bad thing well no
actually maybe I am well I'll let you
decide so let's go back we're gonna talk
history let's see last week Shakespeare
day turns out that Shakespeare was one
of the first programmers and you know
this is a little-known fact
clearly the lack of appropriate hardware
in Elizabethan times was a little
awkward so to bring so he would write
these scripts and he had to use the
actor model to kind of execute them so
but many of his plays are actually
carefully disguised commentaries on
issues that we may be familiar with so
for example the tragedy of Hamlet Prince
of Denmark is actually a play that is
entirely about memory management oh you
don't believe me you're thinking oh it's
just that quote no no look here's a
failure a failure is talking about
manual memory management now I can free
tis in my memory locked and you yourself
shall keep the key of it on the other
hand Hamlet's all about garbage
collection yay from the moment table of
my memory I'll wipe away all trivial
fond records okay records okay not a new
idea there's a whole load of database
migration stuff littered across the
place so you've got this oh well you
know these days were all about garbage
collection and garbage collections are
really new idea and all the rest of it
and then somebody kind of says oh wait a
Lisp Lizbeth sometimes misattributed is
a language of the 1950's its first
implementation was 1960 I'm only going
to take things that run things that are
on paper do not run solo it was sketched
out in the late 50s the first working
implementation was 1960 and that had
garbage collection was a niche thing
that was functional programming nobody
else was doing it except of course Algol
68 and the clue to the year is in the
name so this is my copy of the Lisp
programmers manual one of my most
treasured possessions and I've got the
Algol 68 manual as well I do love a good
old book and Algol 68 at the time was
considered to be a large language too
complex and ambitious to be implemented
and is now smaller than almost any
language that you are using you can
actually find online implementations of
it Algol 68 is the most influential
language that few people have ever heard
of or used it gave us such wonderful
things as the abbreviation of int
everybody else in the 60s was happy with
the word integer but not Al Gore now
we're gonna knock that down to int we're
gonna have cha we could have long we're
fact we're gonna this is a procedural
language and it gave us you know people
often think procedural that that's just
another word for bad it's like wait a
minute so let's let's look at the
characteristics of Al Gore 68
it was expression oriented not statement
oriented so therefore everything yielded
a value you didn't have to have two
different syntaxes for if statements one
for expressions in one photo okay this
is sounding kind of familiar it had if
and fee if you ever wondered where that
came from it came from here it allowed
you to pass around anonymous procedures
that captured their variables by closure
so in other words lambda expressions
this was procedural programming
something terrible happened in the 1970s
we shall look into that so this was
state of the art and it was garbage
collected 1967 similar 67 again the clue
is in the clue to the years in the
number and the name that had garbage
collection so this is really not a very
new idea and really what I want to
explore here is this idea of ideas that
are not you so I've got my name on a
couple of books to do with patents and
they say it's worth understanding what
patterns are a lot of people think
think singleton there is a good
singleton well in fact there's two good
Singleton's there's the singleton that
attracts consultants hello I'm available
to help you with your singles and
problems and then there is the singleton
that is actually good for your code
that's this one it's a single-malt okay
and when you sip it when you have a dram
of this stuff you pause for a moment and
you think you know what has that kind of
fire rolls around your mouth maybe I
won't put that really big global
variable in the middle of my code
and you have that moment of kind of like
oneness with the universe and your code
is improved just simply through inaction
so that's the single term that you want
by the way curious observation in my
experience a system either has zero or
two or more Singleton's present one
uncanny hmm so what we're really talking
about is something a little bit deeper a
few years ago when everybody was going
through manifesto craze I got a bit
upset by their sort of it pissed off and
I was running a workshop at a cover at a
company where we were actually trying to
pull out what are your patterns not the
patterns that we find in books but if I
were to join your team on Monday what
things do you do perhaps that I am not
familiar with what's normal around here
what is your vernacular architecture so
we were looking at this so I just put up
on the on the whiteboard patents
manifesto if it had a manifest it'd be
this one we are uncovering better ways
of developing software by seeing how
others have already done it but simply
as Brian foot said patents are
aggressive disregard of originality it
is the idea that most of what we build
bit of originality is the bit that you
want to really labor at it turns out
most problems have been solved and we're
very poor at communicating those so
related to this one of the key members
of the patents community did Gabriel
wrote this book in the mid 90s his
collection of essays it wasn't just
about patterns some of his reflections
on software development software as an
industry and so on and he collected
together a number of these thoughts and
one of the more interesting ones is this
worse is better now how'd you go pause
for a moment I have to do this every
time I put this slide up worse is better
is possibly the worst name that he could
have come up with it and it's there's a
sort of a its self referential in that
respect I guess there's also a sort of a
humor here and an irony one of the
hardest things in software development
is naming things correctly
we are so bad at it and this is an
example because when you hear worse is
better you think oh I'll just put out
any old crap and that'll be good enough
no that actually has a name that's
called good enough software that the
good enough school of software is
actually quite different so you need to
really understand what dick was saying
and obviously it turns out people had
really bad attention spans even during
the 90s it's not a modern phenomena so
we'll let's actually look at what he
said and let's find out what he meant by
worse it was kind of like partly a joke
partly a play if you like of why
software be more likely to succeed if it
was developed with minimal invention you
know I was take what you know and do
something else with it add the bit that
people don't know it is far better to
have an under featured product that is
fast and small now when most people
think worse they do not think of these
three qualities you know so yeah I'm
gonna do worse is better all right yeah
it's gonna be absolutely bulletproof
there are no bugs okay your idea of
worse is very different to my idea of
thought it was gonna be slow and buggy
and you know I thought it's me large and
bloated but no apparently small is worse
no the worse is a judgment on the last
aspect here rather than one that covers
what an expert will consider to be the
complete requirements it's about minimal
requirements it's about focusing on the
smallest scope and this theories
elaborated explored a number of times
throughout the decade and I was involved
in a panel that oops the two thousand on
the worse is better front but the whole
thing started back in nineteen ninety
which predates not only a jold of what
we call agile development but also rapid
application development and a whole load
of other stuff and the characteristics
simplicity and that one never goes out
of date we keep having to say it because
nobody's listening but he have an
emphasis here the design is simple in
implementation the interface should be
simple but anything adequate will do in
other words it needs to be sufficient
not stupid not terrible
but it doesn't have to be awesome
because it turns out if your
implementation is simple
then there's it has a very important
property you can discard it you can
replace it okay you can change it you
can understand it and that turns out to
be one of the most important properties
of this approach completeness the design
covers only necessary situations and can
be sacrificed in favor of any other
quality one of the classic examples of
this is Ward Cunningham's wiki the
original wiki so here's his sort of
generated purl from it is a hundred and
this is the top and tail of the original
of the original wiki Perl file it's 150
lines of Perl for heaven's sakes I mean
that's not even like comprehensible to
humans so you know if somebody comes
across this it'll be far greater mystery
than hieroglyphics in the future I mean
it's a terrible language but 150 lines
of it you know what if you can get away
with that and I want you to just imagine
if you've got a team to do that if you
instead of getting something like ward
Connie we go oh you know what I want an
editable web I'm gonna just try this
really simple thing and I'm gonna
introduce a few conventions I only keep
it really light and it's not perfect
it's not complete but I've got it up and
running and I used to hang out a lot on
the c2 comm wiki the original wiki and
it was great it was a was it was just
enough that you need and we have
MediaWiki we've had everything has
expanded from that it's so small that
you can rewrite it it's so small you can
write your own but it's also got massive
potential for extension as as we can see
with something like there the full
infrastructure behind Wikipedia so if
you imagine offering this to a team at a
company they'd spent 18 months and not
come up with 150 lines of Perl oh my
goodness it would just it would just
dwarf any Java project you've ever
experienced so there is this thing of
like let's just start small because if
it's small enough we can change it if
we can keep it small correctness the
design is correct in all observable
do it do it right consistency the design
is consistent as far as it goes but it's
less of a problem because you always
choose the smallest scope first so in
other words this is actually an
incremental approach the use of the word
first here is really important you're
gonna do this you're gonna come back to
it you're gonna add things you're gonna
throw things away so this is a really
interesting kind of perspective here now
what we've just done here is discovered
the design process is initiative one you
might be thinking okay well dick was
talking back in 1990 so that was a bit
of a revelation was it No the design
process is an iterative one Andy Kinslow
that's taken from this document the clue
is in the number 1968 welcome to the
half century anniversary of the NATO
software engineering conference 50 years
how are we doing we've discovered that
design processes Initiative 1 how's that
working out for you yeah new idea to you
yeah for a lot of people it's absolutely
refreshing and yet yeah and there is
this notion sometimes people
misattribute misattribute this they say
ok this this conference in garmisch
created the term software engineering
actually know as best as we know it was
this woman here Margaret Hamilton she
worked on the Apollo flight systems and
it was in the early to mid 60's that she
coined this phrase and she developed
really kind of crazy cool ideas like
fault tolerance which actually allowed
the mission to go ahead I began to use
distinguish it from hardware and other
kinds of engineering yet treat each type
of engineering as part of the overall
systems engineering process her idea was
that engineering was everybody's at the
table ok there's kind of no hierarchy
and that was that was her perspective
but a lot of people go around wait a
minute this is all about plan driven
development isn't it isn't that what we
were taught isn't this isn't this what
the document was filled with yeah it's
filled with classic statements like this
Douglas Ross the most deadly thing in
software is the concept which almost
universally seems to be followed that
you are going to specify
that is where most of our troubles come
from this was not news in 1968 this was
no great discovery we didn't have to
wait for Royce's paper in 1970 which is
often misattributed as being the origin
of the waterfall process there's the
point here is we knew this and the
hardware and the interaction that we
have in terms of program has changed
radically and yet it was already a known
thing now I'm not gonna say that
everybody knew everything back in 1968
but when you read through the
proceedings you get a real sense of
variety of thought just as we have these
days not everybody was of one mind but
there's an awful lot of stuff on these
on these lines as I say 68 was a good
year the full joint computer conference
1968 oh there's a lot of details in here
the one that I'm going to focus on
briefly here Research Center for
Augmented human intellect DC angle bar
this is the mother of all demos by
Douglas Engelbart very very influential
he showed crazy ideas like dynamic
linking at runtime which turns out to be
quite important for modularity video
conferencing the mouse and stuff like
very very influential people in the
audience included people like Alan Kay
who went on to develop smaller small
talk systems and there is this idea here
of 68 good year good year so let's go
back to the future 1990 implementation
characteristics of worse is better the
implementation should be fast turns out
that's quite important especially back
in 1968 if you're gonna write Mouse
drivers because nobody's done that
before you need things to be fast it
turns out that speed is one of the most
important critical qualities that is
overlooked because a lot of people
misunderstand the guidance on
performance let's put it this way if you
want to improve the usability of any
system making it faster gives you that
for free it's not just changing colors
you can change the colors you can move
the buttons but if you make it faster so
fast that nobody notices then you've
suddenly got an improvement in usability
you no longer have to have a debate
about what color and what logo or sim
you should use for the weight cursor
it's gone there's nothing there which
means this is interesting and that
performance should always be a concern
it's not something you do at the end
because we have no end
in an incremental approach my favorite
piece of advice from the mid-90s
remember there is no code faster than no
code until somebody invents a tachyon
pipeline in the processor and this will
remain true but we also have this other
observation going back into the 80s the
fastest IO is no IO and this is one of
the most overlooked things I did this
with a team where it turns out we got a
three-fold speed-up and something they
had managed to only get a 10%
improvement over two years simply by
eliminating unnecessary i/o it was just
a case of why why are you storing this
why we're not keeping this in memory and
this is something we need to remember
because we everybody's got this habit
these days of shoving things out on the
network so one of my favorite blogs of
2014 was this one by Adam Drake one of
those wonderfully descriptive titles
command-line tools can be over 200 times
faster than your Hadoop cluster so he
wrote this big data well not big by
modern standards big is a moving target
big is just simply a way of oh it
doesn't fit in memory but that doesn't
sound that doesn't roll off the tongue
so we use the word big but he chose this
too gigabyte problem which you're saying
what good grief on my current laptop I
can run that in memory and still have
space to look at pictures of cats you
know but you go back to the end of the
90s and you tell somebody you've got two
gigabytes of memory they're just gonna
sputter into their coffee and go I'm
sorry that's not happening big as a
moving target it also means your
architecture and your assumptions are a
moving target and people get into a
habit and they think oh the right way of
doing it as we did a few years ago let's
push everything out to the network
because there's cheap computing
resources there if anybody ever gives
you the option to not put something out
on the network take it okay
pushing stuff and then out of the
network when you do not need to is one
of the
best ideas you could ever have and there
is a very simple reason for this it's
called the speed of light it turns out
it's not in a config file you don't get
to change this this is not you know the
point here is that we're looking at me
I'm looking at this monitor here this is
this is about you know it's nearly three
light nanoseconds across that's actually
quite slow if you do that in terms of
cycle time my laptop is about one light
nanosecond across that gives you a cycle
time of around a gigahertz that's really
slow you put something on the other side
of the planet that's gonna be super slow
I'm not saying don't distribute but I'm
saying if anybody if unless you have a
very good reason to then don't do it and
the problem is I always got islets push
it all out and it's just like no keep it
all here you can do some great things
until somebody says this is slow we
don't have the right clearance or you
know there are other reasons then keep
this that chain that does not change it
should be small how small well
Dykstra had this in a lovely way of
looking at things my point today is that
we wish to catalyze a code we should not
regard them as lines produced but his
line spent this advice was offered in
the 1970s I was completely unaware of
this advice and spent most of the 1990s
advising people something similar and
this has not changed because it turns
out that the bandwidth problem for
software development and comprehension
is this thing that's that's the problem
can you fit it within your cognitive
bounds can I understand it therefore can
I work with it effectively the minute
you cannot do that the minute you can't
comprehend and grasp something then that
your ability to work with it drops off
dramatically it turns out that has not
changed this will never change well
actually that's not true but that's a
different talk you have to invite me
back so we see also as an aside that
this also has benefits okay let's talk
about small this is I trying to give a
kind of retro field 1980 this is Linux
this is pre Linux sorry Lions Lions John
Lyons from University of New South Wales
correctly he wanted to have an authentic
operating system for his operating
system course and at that time for
antitrust reasons a Bell Labs and AT&T
couldn't do anything with Unix so he he
used that in a year
put it in a book and annotated it or
rather he didn't put it in a book he
made a set of notes you can see on the
front it was passed around by samizdat
people would stand at photocopying
machines copying the the Lions
commentary now for those of you who too
young to know what a photocopier is it's
like a it's like a socialized form of
scanning ok and you hang around in a
university library or something you know
hoping to meet somebody interesting and
chatting whilst you're putting this
through anyway they came out in book
form and things I need to observe here
is the kernel code is in there nine and
a half thousand lines nine and a half
thousand lines gets you an operating
system I've seen classes bigger than
that and they do not do as much as an
operating system what does your system
do their domain description okay let me
translate that you take data from over
here you change the format you do some
calculations and you put the data out
over there is that about it yes okay and
you've got this big honking great class
in the middle of your system that seems
to have its own gravitational field it's
so big yeah yeah so you've got this
thing the small thing it's it's
computers have changed radically and yet
still it involves humans working on it
and when we have limits of understanding
but it turns out also if you want
creativity the worst thing you could
ever do from a creative point of view is
to take somebody imagine an artist go to
an artist and you say I'd like a picture
what off
I don't know well how big would you like
it to be owner what medium would really
like me to use I don't know you have now
got a very frustrated artist if you
start saying on a landscape I want it
this big I want you to use predominantly
the color blue
and I want you doing this suddenly
they've got something and they will
create something awesome and this
observation is true for any creative
activity as the late Dennis Ritchie and
Ken Thompson observed oh this paper was
written in 1970 there have always been
fairly serious severe sized constraints
I love the fact that always makes it
sound like it goes back a long way
yeah 1970 here we are in 1970 there
always been fairly severe cyclist range
on the UNIX OS and its software given
the partially antagonistic desires for
reasonable efficiency and expressive
power the size constraint has encouraged
not only economy but a certain elegance
of design one of the worst things you
can ever do for design quality is say we
have no boundaries you need those
boundaries they're very important
clearly they change with time but
understand what those constraints are
because otherwise you end up with stuff
like this
this is what we call a legacy system
on Valentine's Day because that's how my
wife and I roll
that's romance hey it's Valentine's Day
what should we do let's take there let's
take the kids down to Stonehenge yeah
that sounds great you know forget the
roses and my kids were there they were
just they were looking at these things
I imagine get a crow or Raven on that on
that one's got a very pleased with that
so the kids were there they were looking
at the girl why I've seen pictures of
this stuff dad but I didn't realize it
with these were that big why is it here
and suddenly you realize that you're
talking about enterprise software
why is it here who built this what is it
for we don't know but twice a year it
lines up and gives the right results
it's our job to maintain it the reason
I'm talking about this is you know this
is a classic information architecture
it's yeah it's very grounded in hardware
yeah like I say computation has come on
but you know moving forward a couple of
thousand years we get to the ancient
Greeks mano lithos one stone one huge
sodding great stone difficult to move we
don't know how to move it but we just
keep adding like into it and stuff and
maybe chipping away at a corner here and
you think how do I want to build my
system in a way that is more aesthetic
so this is my youngest son a few years
ago it is about five he put this
together I was very very impressed
particularly kind of like that little
Japanese aesthetic at the seaweed on top
and you think Oh lots of small stones
elegantly composed that is what I want
that's a new idea so Doug McIlroy said
this is the UNIX philosophy right
programs that do one thing and do it
well I've got a lot of people going
around single responsibility principle
it's a really new idea no it isn't I
also showed that image to a lot of
people and they go oh I know what you're
talking about you're talking about micro
services aren't you Kevin I kind of nod
and I say if that helps you then yes I
am if that's good if that helps you
absolutely that's what I'm talking about
you know surely micro services is a new
idea well there is something in them
that is new but the problem is that most
of the virtues that people extol about
them are actually not new at all and so
here's an idea why don't we define a
subset of the system which is small
enough to bring to an operational state
then build on that subsystem
this strategy requires the system be
designed modules which can be realized
tested and modified independently apart
from the conventions for inter majek
communication so that was 1968 okay
importantly notice the
approach here the description is not
simply of let's just put things together
there is this notion of bring to an
operational state it's not a partial
system it's bring to an operational
state and everything except for the
conventions for inter modulation can be
handled and catered for we see the same
themes of rising every single decade
component software clay mr. Persky 1997
this was already old by the time this
book came out as an idea very good
definition of a component a software
component is a unit of composition with
contractually specified interfaces and
explicit context dependencies only so
dependency management not a new idea
again and this concern a software
component can be deployed independently
in his subject to third party
composition every decade this is
beautiful cycle it's almost in tuned
with the solar cycle of sunspots it's
about eleven years this is a cycle it
goes round and round and each wave does
add something you but the point is you
need to recognize the bit that's new
rather than say ah we got this is
totally radical I mean there was this
really great idea called
service-oriented architecture and the
difference between services and micro
services is the word micro because it
turns out that when you look at the
definitions of what services are
supposed to be there kind of an awful
lot like what people are saying micro
services should be how they should be
small composable and you know you can
have a small team and you can do this
and you could you can update them
independently and and and then they grow
yeah micro is turning into milli is
turning into centi and its convention
gonna turn into micro so should be small
it should be interoperate with the
programs and tools the expected users
are already using every likes to
reinvent the universe the full quote for
Doug McIlroy is this right programs to
work together interoperation
of course John Cook made this wonderful
observation in McIlroy summary the hard
part is his second sentence right
programs to work together that is
non-trivial that is one of the reasons
that we end up with bloat and challenges
and that's a that's a human thing that's
not gonna change
so therefore exactly the same challenges
that we've always had will always be
present things get they lose scope they
drift a bit they get a bit bigger than
they should be
we we end up with a lot of fudge code
and sort of workarounds to get things to
talk to one another that's not going to
change perhaps what you what you can't
constant it should be bug free and if
that requires implementing fewer
features do it okay well how do we
there's many ways of ensuring that we
could we could actually try and do stuff
and make sure it works one of the things
it's a radical idea that's proven
popular I'm testing so Alan Perlis in
1968 a software system can best be
designed if the testing is interlaced
with the designing instead of being used
after the design one of the things that
I found fascinating about reading the
software engineering proceedings from
1968 was there were some terms that I
had I had assumed came around later
for example middleware I had originally
attributed to late 70s early 80s the
term middleware is in the document unit
tests I had attributed as a 1970s term
I'd been unable to find anything
predating the 1970s until I read this
document so this is not use you know
okay well maybe we're going to talk
about test-driven development surely
that's new so Alfred a ho
who is the a in awk hey-ho Weinberger
Kernighan awk is a lovely little
language that doesn't get as much
perhaps doesn't get as much airtime as
it used to because everybody scripts and
stuff these days but it was partly
knocked out by that abomination that
people call perl or as a friend of mine
described it executable line noise and
ork has a very elegant and
counterintuitive execution model it's
organized around
pattern matching and goals it's some
really nice little stuff and so in an
interview so it's 1970s Alfred Ayers
says we instituted a rigorous regression
test for all the features of walk any of
the three of us a home Weinberger Konya
who put in a new feature into the
language first had to write tests for
the new feature so there you go TDD 1970
style we are very good at reinventing
stuff sure our up motivation and our
understanding of things improves but we
need to understand that a lot of these
ideas that are treated as new
or not and if we only had the ability to
recognize this kind of constancy of old
ideas we'd probably get even further
with our refinements and understandings
while we're on it
and I know Dan's in the audience given
when then my favorite way of describing
test structure as well as organizing
requirements also has echoes I remember
looking at that game I wait a minute how
I used to do use cases preconditions
triggers post conditions but it was
Jason Gorbals that tipped me off on the
fact that this is Tony horse logical
construct axiomatic basis for computer
programming 1969 given a given given a
precondition when you execute something
you get a post condition and this was
the basis of all methods but it also
turns out to be a good conversational
construct a good way of organising tests
a good it's it's recursive its present
all the way through this is not in that
sense of new idea I'm just looking
forward to the 2020s when we'll probably
find a different way of describing these
three it should use past many
subtractions as long as they don't get
in the way so don't make things too
complicated so Ward Cunningham came up
with the term technical debt that one
dates back to 1992 as a term and a lot
of people misunderstood what Ward was
saying he wasn't saying it all sucks
because I mean I have a debt my wife and
I have a debt it's called a mortgage
yeah and occlude the word mortgage is
actually in the first word first part of
it Mort death this is a deal on to the
death okay
now it turns out we got a decent
trade-off for that we've got a mortgage
it's structured debt people don't turn
up on our door with brickbats saying
give us the money every month it's it's
structured we've got a we've got a
reasonable way of repaying and in
exchange awesome we get a house so in
other words debt is not of itself bad
it's what you do with it and as far as
Warren was concerned it's a shipping
first time code is like going into debt
a little debt speeds development so long
as it is paid back promptly with a
rewrite I think Ward is very
conscientious with his money
he couldn't imagine that anybody would
say yeah let's just increase the debt he
says he that he coined it so it'd be
blindingly obvious that it's a bad idea
when you live when you leave it I manage
the danger occurs when the debt is not
repaid every minute spent on not quite
right coke counts as interest on that
debt importantly that was the origin of
this but again the observation that
sometimes it doesn't work out quite as
we hoped is dates back even further
there you got some microservices
architecture as implemented by most
companies Alan Perlis in the long run
every program becomes Rococo and then
ruble if you're not sure what Rococo is
we are presented once again with this
idea of like ok so how do you build a
system surely we can just specify and
it'll work it's just the programming
that's getting in the way it would bear
out 1991 I think walking on water and
developing software from a specification
or easy Botha frozen so so how are we
gonna do the specification so one of my
favorite cartoons alongside xkcd of
course is commits trip and you have the
manager talking to the coders there
someday we won't even need coders
anymore we'll be able to just write the
specification the program will write
ah nobody's ever said that at all in the
history of programming going back to the
1950s yeah again there's a regularity
maybe people could just write it and yep
yeah I watch it come around again oh wow
you're right we'll be able to write a
comprehensive and precise baton ban we
won't need programmers anymore exactly
and do you know the industry term for a
project specification is comprehensive
and precise enough to generate a program
code it's called code
you can't get much more precise than
that Jack Reeves in 92 C++ uses journal
this is actually a touchstone for many
of the craftsmanship movement and again
this is considered to be this is over 25
years ago and there's this idea and it
wasn't necessarily new but he
crystallized it wonderfully in this
question this exploration of what is
software design programming is a design
activity now why is this important it's
important because for decades and we
continue to do it I'd like to say it's
all in the past but that's not the case
people have managed and mismanaged the
programming activity as if it were non
intellectual non design based and merely
a production activity and this idea that
it's not a production activity is not
new it turns out that we've solved the
production problem it turns out that
there are other engineering professions
that are deeply jealous now again this
is not a new insight 1968 Peter Nahum
Brian Randall the replication of
multiple copies of a software system is
the phase of software manufacturer which
corresponds to the production phase in
other areas of engineering it is
accomplished by simple copying
operations and constitutes only a minut
fraction of the cost of software
manufacture this is a profoundly
unoriginal observation but I didn't you
know but we keep going every time I
think oh it's a new observation I
remember first coming across it in the
1990s Jack Reeves every time I look
further back there's somebody else who
said it and this is important because if
you manage the design activity you're
going to manage think very different to
managing the production activity so how
are we gonna all know stuff if it's a
program activity it's a design activity
parlous 1972 again this one is is this
one's a sort of a stand standard classic
especially everybody going into phases
and getting very excited about modular
concepts on its usual cycle the Java
folks are getting excited about this one
again having forgotten they already had
classes and stuff like that but
nonetheless Parnassus said we proposed
at one begins with a list of difficult
design decisions or design decisions
which are likely to change now notice
he's not organizing abstractions
by you know necessarily domain he's not
organizing them by this idea of how
things group and cluster or
normalization he's organizing them by
volatility by certainty by stability and
instability the recognition that changes
the only constant has always been there
and perhaps when you are creating a
software structure the one of the things
you need to care about is not simply the
cognitive bandwidth of a human being but
the economic ramifications or what
happens if we have to keep changing
everything if I have to touch everything
all of the time that's gonna be an
unsustainable activity I won't end up
touching everything all of the time I'll
just touch a few things and then
everything will localize and then we'll
end up with the Stonehenge and we'll end
up with a lot of copy and paste actually
can't do that with stones it turns out
but each module is then designed to hide
such a decision from the others this
simple observation crystallizes many
things not simply the idea of modularity
but most people overlook that his
observation was to do with volatility
you've got a team that can't agree on
design guess what
put put a boundary around that
disagreement you can actually come up
with a really simple draft of how to
structure your system based on whether
or not you agree with your colleagues
yeah based on hey we've got two ideas
for this okay we've got we've got
something there we have no idea about
this okay well there's a boundary around
that you can actually structure a system
first draft let's try that it also tells
you how your process can flow where
you're going to explore so cohesion what
am i favorable to pick this one this one
up in Powell's in in Portland people
just don't do book covers like this
and there's probably a reason for that
this is the 1970s and you know depends
on what people were taking at the time
but that does something to your eyes
cohesion is a measure of the strength of
Association of the elements inside a
module a highly cohesive module is a
collection of statements and data items
it should be treated as a whole because
they are so closely related again we've
got a different perspective on why we
glue things together and the attempt to
divide them up would only result in
increased coupling and decreased
not a single concern that we expressed
now seems even remotely new
so let's talk about other things let's
talk about our understandings and
misunderstandings of paradigms okay or I
mentioned earlier on his perspective on
object orientation was this it means
only messaging local retention and
protection and hiding of state process
and extreme lake binding of all things
now what I find interesting about this
is that when you look at this it tells
you why mirror this is a messaging model
at heart and in this book that I had
just a few years back 97 things every
programmer should know russell winder
makes this very simple observation says
right okay instead of using threads and
shared memories our programming model we
can use processes and message passing
process here just means a protected
independent state with executing code
not necessarily an OS process but it
turns out these ideas are fairly old
languages such as Erlang and all come
before it has shown processes are a very
successful mechanism for programming
concurrent and parallel systems they
don't have all these synchronization
stresses that shared memory
multi-layered systems have the problem
is that we got all very excited about
adding threads to code and every sort of
said yeah let's go and add this stuff
into into our core programming languages
and core libraries and I remember when
Java came out that one of the first
things I noticed about it was that all
of the collection classes the few that
it had had the synchronized interfaces
and I remember thinking you guys have no
idea what you're doing do you because
that's not how this works you just you
the active thing you don't want to do is
to share are all the primitive
collections between threads you're just
doing threads because it sounds cool and
this is the problem the rest is history
and consultancy and bugs always remember
if you're if you're trying to improve
performance then a thread is not the way
through composing in terms of threads
and locks is not the way to do it
synchronization is the one thing you
actively want to avoid if possible all
computers wait at the same speed you can
have a three gigahertz weight you can
yeah that is the purpose of
it is to stop the purpose of
synchronization is to eliminate
concurrency so if somebody says we're
doing threads to make things faster why
are you using locks to make things
slower hmm I sense a disturbance and
your understanding of the forces
involved so this is not new I mean the
actor model actually dates back Carl
akhom which is based on communicating
sequential processes hey Tony Hoare
again 1970s as its origin I ended up
doing some stuff with with all confused
guy also ended up doing a master's
degree where my research was about the
actor model this rather than something
like early and so it's object based but
it was also built in Lisp which was kind
of interesting and this kind of brings
us around full circle because what we've
just done is we've accidentally noted
that and if we look at what Alan Kay
used to say about small talk in the
relationship to Lisp he said that it was
quite tight in the sense of the idea of
building a system where around a small
set of primitives a small set of ideas
from which you can compose something
larger he got from Lisp and that
inspired small talk was actually an
economy of ideas that went through but
the messaging model that also seems to
be interesting and people debate whether
or not actors are an object model or not
the reason they do this is because it's
politically interesting to debate it
there is no debate they are an object
model according to the original
definition from alan kay and it turns
out that lambdas also fall into this
there's a wonderful paper written in
1984 by a car delhi and wagner about
data abstraction William cook revisited
it a few years ago saying I actually
explore the theoretical basis of this
approach and he makes this observation
Lander calculus was the first
object-oriented language and he puts the
date in 1941 so I did a bit of digging
1932 so it's kind of it's kinda like
really sweet when you know you got Java
programmers getting terribly excited in
2014 going yeah we've got lambdas
and you got C++ programs going like
we've got those and we got those since
you got the JavaScript programmers going
yeah what about us and everybody else is
going yeah what about you we're talking
programming languages here right and
then and then you're sitting there and
you got all this conversation you got
Lisp and Algol sitting there going up we
had those 1960s 1932 yeah
programming like it's the 1930s however
obviously everybody gets a little bit
you know got all this is the best
paradigm this is the best paradigm I
always like to bring functional programs
down-to-earth very with this observation
from mr. Haskell silent Peyton Jones
Excel is the world's most popular
functional language it tells you that
half of the story is not the paradigm
it's how you execute it it's how well it
is carried out and it's slightly galling
to many people that people in their
accountancy Department I'm doing
functional programming for far longer
than they have but we have so many
misunderstandings it turns out that this
is a landscape without boundaries
there's a continuous flow from one
paradigm into the next they're not
bordered off maybe's build walls between
the paradigms a stupid way of thinking
so we're gonna separate everything else
apart modularity lambdas whatever it is
but we do have to put all this back
together again and that becomes our
perspective on this one we have to have
a philosophy of this and perhaps that
philosophy we like to call architecture
but there's a nice way of describing how
we should be reasoning about larger
systems and this also takes us into the
modern space when we need to start
thinking about how we compose
microservice systems how we compose how
we organize our reasoning about
frameworks back in early 90s Glencoe
talked about coordination languages and
I remember learning about this stuff
really I made a lot of sense to me this
idea of a genuine separation we can
build a complete programming model out
of two separate pieces the computation
model and the coordination model you
have nice little pieces that do nice
well-specified jobs again this predates
component thinking but that idea the
same idea the same cohesive ID
and then you have separate to that a
coordination model sometimes it helps if
it's in a different language people find
that more convenient but it doesn't have
to be but how old is the oldest
coordination model well I've noticed one
thing at this conference and I saw it in
a tweet somebody observed you know what
everybody's keeps referring to UNIX
pipes so yeah so will I 1964 Doug
McIlroy again we should have some ways
of coupling programs like garden hoses
screwin another segment when it becomes
necessary to massage the data in another
way this is the way of i/o also what you
have here is a concatenated programming
model a functional model a data flow
the idea of the coordination modeling
and have processes that have a very
simple input-output model continuous so
ongoing execution not termination based
execution you've run a program then it
finishes ongoing and then I can have a
coordination model the pipe it took six
years to find the pipe symbol on the
keyboard it was Ken Thompson that found
it in 1970 put it in so sometimes a good
idea takes a while to implement six
years in this case so I want to close on
this idea that we know in many ways more
than we give ourselves credit for and
that brilliant as our progress has been
we might be even better if we paid
attention to the things in the past so
we could understand when a new idea
comes along what he's genuinely knew
about it and focus on that rather than
getting distracted by repeating the same
message copying and pasting exactly what
was I mean literally copy and pasting I
worked with a guy a number of years ago
who had a same PowerPoint presentation
that every time a paradigm came along he
would get the PowerPoint presentation
and just do a global replace of whatever
word you know object for component
component to service service to
Microsoft whatever he would just do a
global replace and go out to customers
and say look this is what we're offering
you okay so the point here is that these
are the things that are timeless not
just not just the constancy of
PowerPoint that's that one level is
cynical but it's also actually
revealing but we would make much more
progress if we had this kind of
historical recognition that there do
seem to be these core ideas thank you
very much