the morning them
and whenever I work for info ether with a
rich colour and Chad Fowler and Bruce Williams who I suspect
I love you know here on
and I'm here to talk about real software engineering
this is my I've been at all for out the Lone Star
becomes and really enjoy them so start off with
software engineering doesn't work
on at least as it's currently heart
it in universities and in training programs
at companies if you happen to work for one of the few companies that cares
about
teaching such things um the techniques that are taught
and that are called software engineering a
simply don't work they don't up
reliably control costs they don't reliably
produce quality software sometimes even when their practice rigorously by people
who've been trained to do so
they don't produce working software at all and
that shouldn't really be surprising to any of us because it
this seems to be common knowledge among working programmers
a all over this country at least up
but well it's not surprising it is odd because in every other field
that aspires to the title over an engineering discipline
um the term engineering is reserved
for practices that work in fact
that's as good a capsule definition of Engineering independent have any
particular discipline
that your as as you're likely to find which is the set of practices and
techniques that have been
a determined to work reliably through experience
and yet in software we have this set a practice that don't work
and we call that engineer up
now this is caused a lot of discussion
especially over the past year or so
about whether software is really an engineering discipline at all
and whether software development really doesn't fit that metaphor
it's not engineering it's more a crafter and art or
or something else or gardening or a
movie-making or or various different analogies I've heard
I and maybe engineering is Justin in appropriate metaphor
for the task a billing software and I don't think that's true
up I i do think software is an art I do think it's a craft I do think it is in
some respects a science
but that doesn't mean it can also be engineering and I i
I say that the problem is that um
the the people who have defined the self-discipline so we call software
engineering
have a misunderstood two very important things
software and engineering
and that has resulted in
software engineering being actually a caricature
up an engineering discipline so
I mean explain what I mean by this and
to do so I need to first start off by explaining
what I mean when I say that software is a caricature of Engineering and kind of
how it got to be that way
and the need to explain what real engineering looks like
other neat how many people in the room were trained
as engineers not a software developers okay
interesting I'm especially interested in feedback from people who have
more the classical engineering up background because
I don't I've had a kinda learn all this on my own but I I think I've come to a
a pretty good understanding of 04 software engineering got it wrong
I'm and then we're gonna look at what real software development
looks like and
in the middle somewhere I think we can develop a picture of what real software
engineering yes
so the first time that the term software engineering
a really got bandied about a lot
was in 1968 at a
conference in Garmisch Germany organized by nato
above all things um
the the first conference on software engineering sponsored by the NATO
science committee
and a at this time
you know people were dealing with what was called the software crisis
and a saw for projects were really unreliable and and flaky and error-prone
and failure prone and
and had huge cost overruns and that he really didn't know much about how to
manage them
and so they said you know we need to come to grow up as a discipline and and
as a field and and start becoming an engineering discipline and
a say this conference and I'm
I've known about it heard about this conference for many many years
and a never really new any details about it in stores I got interested in this
topic I went and read the proceedings which are all online
and I was expecting to find okay this is where the madness started
and in fact no I didn't find that all
other participants in this conference were by and large really smart people
who were working software developers
there are a few academics but
I'm the academics had good things to say as well
and by and large the findings are love this conference were
a entirely reasonable and reflected a great deal of wisdom
about up software and its state at the time
but in fact mostly what y'all you'll be impressed by
its as you go there and read those those proceedings if you do
is how willing they were to admit that they didn't know anything
I the the conference is full love
a you know we're just kinda babes in the woods at this is a new field it's
different from other fields before
there's all kinds of stuff we don't know we kinda think it might be like this
there's a lot of uncertainty
and Alan perles up
a gave a talk in which case at the into the conference in which he sorta
summarized
the few things that the group was able to all agree on
about what software as engineering should look like in
the first of the three things were a software system can best be designed if
the testing is interlaced with the designing instead of being used after
the design
that's pretty reasonable
by our standards um
over to a simulation which matches the requirements contains the control which
organizes the design of the system
now the the terminology
has evolved since then and
um so that doesn't immediately seem to make a lot of sense
but I think if you combine that with the third one it is clear what he means
for successive repetitions have this process of interlaced testing and design
the model ultimately becomes the software system itself
in effect the testing and the replacement of simulations with models
that are deeper and more detailed goes on with the simulation model controlling
the place an order which these things are not he was talking about unit
testing
and mocking and interactive design and develop
pretty reasonable there was a second nato software engineering conference
a year later um the toll
love those proceedings are entirely different a
during that year everything went wrong
um and and a within a year software engineering turned into what it became
what it was for many many years which is our entire field of processes designed
in academia for practitioners
what went wrong in one year
but I don't know a I was alive them but I was in a computer programmer back then
and so I wasn't involved in these processes but I have a theory
about what went wrong and I can go straight that theory by
up talking about another place where
up some very reasonable statements were
misconstrued and turned into completely unreasonable conclusions
where we note what happened and that is a
the birth of the waterfall process
waterfall was hurt waterfall was introduced
up by a winston Royce
in a paper at IEEE west Conn in 1970
and the paper I was called managing the desert development of large software
systems
and Royce spent the rest of his career running around saying no no no I didn't
mean that I was misquoted
up and um I've heard that story too
and when I went back and and read this paper
on I was I was astonished to find you know
II was not surprised to find that he was telling the truth he really didn't
recommend waterfall
but what I realized was that um
up the the problem
the reason that people thought he was recommending waterfall
is that this paper is a marvel of bad
information design if if you wanted to study how to write a paper
that conveys exactly the opposite impression from what you're trying to
get across
you couldn't do better than to go read this paper
so let's let's take a look at this for a minute and assume that you're a manager
of a group producing software
in 1970 I am
and you're struggling with how to you know
reliably estimate and produce stuff that works on all these problems that
have plague software management since the beginning and a friend or colleague
or maybe one of your employees
drops this paper on your desk and says this might help
0 managing the development of loft large software systems let's
pretty good that's what I'm what I'm interested in um
and oh I see that there's a diagram there on the front page
so you know let's let's start by kinda looking at the diagram to see what this
is about skim it first and then read
so that for that diagram says you're a star with analysis
and then you go to coding and
that's a kinda simplistic
and even I know that's kinda simplistic and
so a before I waste time reading this paper we look at the rest to the
diagrams and see if this guy
has a brain in his head or not and so at the top of the second page I see this
is the first time the classic waterfall diagram ever appear
and you know well thats that's pretty good system requirements and from that
gets offer requirements and then be moved to analysis and
designing coding and testing operations and and look at the caption their
implementation steps to develop a large computer program
for delivery to a customer
I can understand that process that makes sense to me I see how all those things
work
and I get this meeting to go to up I I got what I need outta that
with the very next line I believe in this concept but the implementation
described above
is risky and invites failure a
the funny thing is that that sense describes figure 3 which is on the next
page
to find out what winston Royce has to say about figure 2
you have to go back to the first page where he says an implementation plan
keyed only to these steps is doomed
well let's be optimistic
and assume that the manager comes back from his meeting and picks up the paper
again
and tries to continue through it Anne flips to the third page
NEC's this 1k to our eyes that looks a little more reasonable we can see
feedback
coming from later steps to influence earlier steps
as you learn more as you get down into the details and then release goes on to
say that
the feedback isn't even that localized and sometimes you know the things you
learn in testing have to go all the way back up and
affect the software requirements and this is starting to seem confusing and
messy and
hard to control and well who in
up she the I'm I don't know what this means in
always black boxes send but
just gets worse and worse in and then the final diagram which is hopefully
labeled
summary summary
area
a
I I think I'll go back to that one and within just a few years waterfall was an
established standard in the industry
and it's easy to kick waterfall in its kinda up
you know most people realize that's not the way to do things
I'm but a I've run into
group that kinda religiously follow waterfall and don't see how anything
else could possibly work
as recently as three or four years ago and as recently as the late 90's
a a the Department of Defense was still
essentially mandating waterfall for all of the projects that they paid for
it has taken a long time for this
idea which was presented as
a way of doing things that was obviously didn't
up to finally start to work its way out of people's conscious
consciousness because people like
simple solutions and
they hear terms and matched map those terms to things they already understand
or think they understand
and latch onto that and run with it without thinking very carefully
that's just a characteristic of people and it happened with waterfall and I
think it also happened with this term software engineer
HL mencken said for every complex problem there's a solution that is
simple
need and a wrong that certainly applies there
on
later software engineering even as people began understanding the weakness
is a waterfall and moving beyond it
later software engineering shared a by yes with the waterfall model
which is an attachment to what's called the defined process model
this is a description of that model up from
schreiber in Beatles book on scrum I'll
the defined process model requires that every piece of work be completely
understood
a defined process can be started and allowed to run until completion with the
same results
every time the idea process models was
introduced by some chemical engineering researchers on
and up the fine Macross Ismailis or to one end of the continuum
and there's another and they will talk about later up but most of software
engineering has been biased toward the defined
process model when chemical engineers
a learned this they're often very amused up to
see that software has chosen a model that so wildly inappropriate for the
kind of things we do
on but up this bias toward the defined process model has pervaded the software
engineering literature and so forth here's an example by one of the giants
of software engineering David Parnas
ok we're in a paper in up
1986 he describes what he calls irrational
design process you establish a document requirements
you design a document the model structure design and document the module
interfaces
you design a document that uses hierarchy you design and document the
module internal structures
and you write programs and maintain now look what he says later on
in that same paper the picture of the software designer driving his design in
a rational way from a statement requirements
is quite unrealistic no system has ever been developed in that way and probably
never will
and yet his his attachment to the defined process model was so strong that
he persisted
and persists to this day by claiming it
in claiming that the way we systems are actually developed is
irrational by implication because he calls this the rational design process
id
and how to fake it
yes but the name is telling yes the name in the paper is a rational design patent
process
and how and flights affected you're right
but the name is telling and
I'll in the paper the tone of the paper is
it's a real shame we can't do things this way because that would be way
better
and by faking it you gain benefits from this
irrational and disciplined way that we actually have to do it
so yes good point but up the the implication is there that that is the
only way
that that is the rational process
and that's the way we should be doing things on
the bias towards defined processes late lead software engineers
astray in other ways um this is the famous cost of change kar from barry
beam in software engineering economics in 1981
on it was well understood before then but beam went out and
and surveyed a lot a real projects and gathered real data
to show that this is the way things actually work
up the cost of finding and fixing errors up
skyrockets as the you go through the life cycle the project it's relatively
cheap up front
and it's horribly expensive out at the apt
on the software engineering solution to that was to say well if changes cheap up
front let's try to push all the change up to the front as much as we can
and eliminate change and and errors from later in the process
um but of course that has secondary effects and quite often
the processes that were introduced to try to identify all the errors as early
in the process as possible
were themselves quite costly and so that push the
cost over the entire project up across the board from beginning to end
real organizations not like that budget pressures resistant and push back down
on that thing in this is like
school stepping on a tube of toothpaste right it squeezes
the things out at the end in things end up taking a lot longer
um
we know now that there was
unseen bias in beams data which is that all the projects he was measuring
were waterfall projects
nobody thought anything of that in 1981 because that's the way saw for projects
were done everybody knew that
winston Royce said in nineteen seventy
but what it meant was that
arm beams data was
kind of skewed by that assumption and it turns out that he was not
actually measure what we believe today is the was not actually measuring
the cost are finding and fixing errors the cost of change
as a function of your position in the software development life cycle
we believe today that he was actually measuring the cost to finding and fixing
errors as a function of
the distance in time from when the air was actually made
in other words he's measuring the cost of a long feedback loops
and if you were to measure projects that are interactive
and integrate and and and deliver
working software every couple weeks or every three weeks or something like that
you would find that that graph looks very different
because you're from mostly finding and fixing errors up
within a very short time after you make those mistakes
and that's what makes them cheap
on another thing that another way that software engineering kinda went astray
was a focus on modeling
and what I call Matt MP I heard a lot of people say
you know up up software development needs to grow up
and start working like a real engineering discipline does
and I three years ago I'm picking on David Parnas a lot but I've
just read a lot of him and happened hear him speak at several different
conferences
three years ago I heard part assay in engineering people design through
documentation
the job with an engineer is to write documents
and he said you know with the software engineering field needs to
kinda get with the program on us I'm here are some examples of design
documents that have been proposed in our field
top left when there is these that specification language
the bottom right one is one apart missus proposals
a tabular mathematical expressions
I am
precise maybe
understandable
the proponents of these proposals claim that they are given sufficient training
and experience
in the long run they're all dead yep
over Leicester it's been a long time since I've seen you I'll
been seizing their up and a
I am is it clear how to map this to code
well I don't know
is it any easier to get right pincode
they've been all kinds of things in this vein on
and a as was pointed out there all now dead
essentially um but misconceptions about engineering still avail
this is something that Bruce Eckel wrote in a blog post last year
and to be fair I think Bruce knows better than this
I think he was writing this as a throwaway statement on the way to
another up point he was trying to make
but nevertheless he said it so I get to pick on him for
um this is not some kind of engineering where all we have to do is put something
in one end and turn the crank
what's real engineering like well let's get something straight
right off the bat there is no kind of Engineering we're all you have to do is
put something in one end and turn the crank
engineering is a creative activity it's about designing and building and
creating new thinks
and there are always blind alleys and missteps
and mistakes and discoveries and reactions to those discoveries and
adjustment
well so that different engineering disciplines are different if you look
at structural and chemical and
a mechanical engineering and electrical engineering
and industrial engineering all those things they're very different
they work with different materials different physical effects different
forces they work at different scales
they have different degrees of complexity in requirements
processes artifacts all those things they work with
there is a very draw a lot level over-reliance on formal modeling and
analysis on math
verses experimentation prototyping and testing
and they have a very good reliant degree reliance
on empirical on to find versus empirical processes
we've seen the definition of the defined process model
here's the definition of the other end of the continuum the empirical process
model
it provides an exercise control through frequent inspection and adaptation
for processes that are in perfectly defined and generate unpredictable
and unrepeatable outputs
chemical engineering tends to be heavily biased towards
an empirical process model of an industrial engineering is the same way
nothing we know about real engineering and you know quite often I've heard
people talk about
software development meeting to grow up and become a real engineering discipline
and those same people will say things like um
cost shouldn't be an object when it comes to doing it right
in real engineering cost is always an object
I love this quote from a nineteenth century bridge engineer named Arthur
mill in Wellington
um railroad bridge engineer and I've kinda updated his language from
flowery Victorian prose that's hard to read to something more modern
up but this is what he said engineering is not the art of constructing
it is rather the art of not constructing her it's the art of doing well with one
dollar would any bundler can do with two
in real engineering advances usually come from practitioners
not from academia
own illustrate this with a with the story of to bridge builders
the first is Robin my art who built this bridge among many others
this is the fall she'll bach in Switzerland my art was an early 20th
century Swiss bridge designer who was interested
in I'll the this new material at the time called reinforced concrete
and how it can be used cut reinforced concrete was already being used
in bridges at that time but it was being used as a kind of better start
a less expensive stronger stone
so reinforced concrete bridges look basically like
alder stone bridges just made out of a different material and and
my art realize that on reinforced concrete had different properties that
he could exploit to build different kinds a bridges
and he started building beautiful arch bridges like this a very lightweight
graceful structures
they don't look anything like earlier stone bridges
on my art was
vilified and ostracized by the
European structural engineering community
the reason for that is that he did not have mathematical model sophisticated
enough to prove the soundness of these designs
um him he was called a up
charlton and a thief he was stealing for his customers because he was taking
their money to build bridges that would fall down
he was endangering lives they said
um
today all but one of my arts structures are standing in the one that's not
standing was destroyed in an avalanche
um how do you think Mark
look in the mirror and slept at night knowing that he a
didn't have mathematical models that could prove that these bridges were
sailed
I know it's only 10 o'clock but should be awake
he stopped the sleeper Bates wide
yeah a may have any ideas what he did
is fine he kept doing it I'll
he demonstrated the soundness of these bridges to himself to his own
satisfaction
through testing prototyping
modeling he built model so these bridges in his workshop
and roll barrels full of concrete over them
and jumped up and down on a min invited friends over to jump up and down on a
min
a test on every way he knew how to prove that they were
us sound bridge designs
wouldn't yep
yep so-so modeling is modeling is not reality
right but I so
he he built model so various scales he saw how things changed as he scaled up
he over engineered the bridges according to the models that he developed
I'm any also had a a very good intuitive understanding of the statics involved in
where the forces were being distributed and things
um and later other engineers developed math there was sophisticated enough
to model these bridges
now the next bridge builder want to tell you about was a contemporary of my arts
on he was also European his name was
a Leon what's F on he did not stay in Europe he came to the United States
and he developed up what was at the time the
most sophisticated and accurate
model of the mechanics of suspension bridges that had ever been designed
and you know it doesn't help if I'm not actually plugged in
so I am he he built this theory upheld the flight how suspension bridges work
that suspension bridges were all the rage at the time there was a lot of big
suspension bridge building
going on in the United States and around the world and myself kinda became a star
of that field
and he consulted on other girls on eros bridge
in New York and the Golden Gate Bridge and several others
and finally he was given his own project and he took his theory has mathematical
model which was called deflection theory
to the limit he wanted to prove exactly what it could do
and so he built the Tacoma Narrows Bridge in Washington State
but one at the up biggest
in civil engineering disasters in US history
um what went wrong well up
as we've already observed models are not reality
there an approximation of a reality
and why we use them in engineering is often misunderstood we'll come back to
that in a minute
um up
deflection theory was believed to be much more accurate
than previous models love how suspension bridges work
and as a result um myself was able to make the the deck over this bridge much
thinner than any suspension bridge deck
up before relative to its span
arm
and the result was that
hum the deck up this bridge became subject to a force that had never been
seen or noticed
in suspension bridges before because none of the BRICS had
rigid not have the decks had ever been that tip
he began acting as an airfoil and a
diffraction theory accounted for all the known forces
a that that we're working on decks have suspension bridges which were
you know down were forced from gravity any additional weight of things on top
and
and up side word stress from win and and and various other things
but it never accounted for the possibility that there might be upward
force
from the deck acting as an Air Force and
this started happening in the deck because I was then this began
oscillating and within six months of being built
well the Bridgeport South Park iight always stories to illustrate
three points %uh the first one I've already mentioned a
important advances come often come from practitioners
not necessarily from academia and that they're brought into the academic world
and
and refined and so forth but they come from practitioners
the second point I i want to illustrate is that software is not the only
engineer discipline that occasionally loses the plot about what engineering is
all about
the third point is illustrate the point that mathematical models were introduced
to engineering as a cost-saving
tool it would be easy if you hear software engineering people talk about
math and modeling
would be easy to get the idea that it's the only way to do things right
and then it's a tool for robustness and you don't know it really works unless
you have math to prove it
I've heard all those statements
but that's not why I was introduced to engineering at all
it was introduced to save cost
because in other engineering field they're working with real materials
and things that require people and labor to go out and build
and I'll up building prototypes and testing them
especially at scale is extremely costly
and if you can build a model an approximation of reality
you can save money how's it work well here's an example
calden up on my favorite Calvin and Hobbes cartoons calvin says hello I know
the load limit on bridges data
and set so I was modeled myself as a dad on Calvin's dad
and whenever my kids ask questions about the world how it works I always try to
come up with some wildly
I inaccurate but humorous answer and and this is one of the best ones
I'm well they drive bigger and bigger trucks over over the bridge until it
breaks
and then they way the last truck and rebuild the bridge
and this happen so much in our family that I photoshopped actual photo of my
wife
into this final frame up
I'll so that's ridiculous it's funny because it's ridiculous
why is it ridiculous because that would cost too much
so to engineers never actually build real prototypes and test them
no of course they do if you haven't seen the video
Boeing testing the triple seven wings to the breaking point
I encourage you to go seek it out and do it
um built a foal scale
Boeing triple seven prototype most of the fuselage
empty of course but the wings up built
to spec and hope the tip so the wings
up to these two which is up in the ceiling and started cranking them up
and they did until they broke
and watch the video it's quite amazing and will make you feel really good about
first
flying in with those planes because they almost touch at the top before they
break
but up when they do break they break at exactly the same time
and no they don't flap when you're flying I saw that back there
a when when the their vengeance is like a normal play
a when they when they do break the break at the same time
and all the engineers get really excited
weather so excited
validated their models who said that excellent
it validated their models they thought their model was accurate
but they didn't know for sure but it happened at the exact point they
predicted with their models
models are not reality
models are approximations that save us the trouble
of doing this as much
but they don't say this enough the trouble to do it at all I'll
up engineer still build models
aerospace engine oils mir's build a lot of prototypes and test them in wind
tunnels and do this kind of thing
this kind of thing um electrical engineers
bill models a lot and test them
and prototype to ask your favorite new friendly neighborhood
aerospace engineer how much modeling he would do
um or how much math he would do if building a model his design and testing
it were effectively instantaneous and free
the answers may be you probably not none you probably bills do still do some
mathematical analysis
but the answer is a lot less than I do now
on this is my favorite definition oath
engineering from the structural engineers association structural
engineering is the science and art of designing and making
with economy and elegance structure so that they can safely resist the forces
to which they may be subjected
noticed the tensions in this definition
science and art
it employs the findings up science
and yet is done with creativity
designing and making engineers doc
sketch something on paper invalidated with math and and throw it over the wall
and never look at it again
that participate in the building up what they design
structural engineers have hard hats in their office
because they go visit the site and talk to the construction people
and work with them during the process
with the economy and elegance
cost is always an object
based on that definition here's my definition of software engineering I'm
not claiming that
its the best one possible but I think it's pretty good
software engineering is the science and art of designing and making with economy
and elegant
want to preserve those three tensions system so that they can readily adapt to
the situations to which they may be subjected
we know that software engineering will be different
from other kinds of Engineering we know that because other kinds of Engineering
are different from each other
software systems are usually more complex in terms of number of moving
parts
and and things like that than a artifacts and other engineering
disciplines
um we're not working with physical materials we have different laws we work
with
and it's rare for a software project to run up against the limitations of
physical materials
very rare I'm and we knew this
from the beginning this is a quote from
we we knew that that class of urging was different from the very beginning this
is a quote from royces paper about
the that introduced waterfall process
the testing phase is the first about for which timing storage input/output
transfers et cetera
are actually experienced as opposed to just being analyzed
these phenomena are not precisely analyze double
yeah if these phenomena fail to satisfy the various external constraints that
invariably a major redesign is required
in affect the development process has returned to the origin and one can
expect up to 100 percent overrun
in schedule and/or costs
so what's the answer then do we go back to those confusing diagrams that was
proposed in nineteen seventy
I think the answer comes from a man named Jack reeves who
pointed out the most important difference between software and other
kinds of Engineering
paper in a C-plus post-journal in 1992 called what is software design
reams talked about the analogy that we often make between software development
and engineering
and he said you know in in engineering you have these engineers and they
I'm produce documents just as part of said they do
and that as the design of the system and then they handed to laborers who build
the finished artifact and so if that's the way engineering works then software
engineer gonna look like
having engineers and they produce a design and they handed to laborers who
sit in cuba called
and build the finished artifact which is the source code
and that's the way many projects work today I had a a guy
send me a note a couple days ago and asked me if anybody had recorded and
posted this talk yet
because he said you know where I work we build software as if it were bridges
um so so the problem with this analogy is
you know we we've we tried and tried and and this summer
up manifestation of that process on the bottom doesn't really seem to work
and the big problem yes that that second phase there
we've never really found a good way to write down a software design
in a way that is comprehensible and precise
and thorough and doesn't require those pesky labors in the cubicles
to redesign a bunch of it which they're clearly not capable of doing cuz they're
not engineers
well most look at this problem he said maybe we've got this analogy wrong and
and since that's the trouble some part let's get rid of that
and let's say that we left the the software developers be the
engineers be the designers and
that thing over on the right that source code that's not what the customers are
paying for their care about source code
that's really the design
maybe not the only design it's still helpful to have diagrams and documents
that describe the structure at a higher level view but
in reality the source code is the detailed
thorough design of our software system
the one that's precise enough to actually build the system out of
so if this is the way we draw the analogy what's the course Park what
corresponds to the labors and the builders that build the thing
compilers our programming language implementations
and the thing that the customers are paying for is actually running code on
systems not file sports or scope
if you'd role the analogy this way where's the model
in the source code
where the document
a yep
where's the document thanks Adam but that's not what I was looking for
somebody said it is Maria the source code
it's a document why only when you realize that that's a design document
before
well pearly pretty good reasons because program it one of them is because
programming languages have only recently kinda reached the point
where it's possible to write code
that that is almost as easy to read as it was to write
okay so lol it when
its things have changed to make this a little clearer but I think this is the
right analogy
the source code is the model programming languages
our formal languages some love them even have mathematically specified semantics
but even if they don't ok their their formal languages
and we understand the math behind them at least as well as your average
structural engineer
understands the math miss behind about the procedures that he was taught to do
to validate his designs
programs themselves our models
of the solution to the problem that we're trying to solve are very tools are
mathematical in nature
running a little behind some escape these quotes um
but up the this was understood by people
even back in the nineteen sixty-eight I Garmisch Soccer Development Conference
now one more quick thing I'm already a minute over but I'm a fish quickly
well this is a simplified example a 10 up David Parnassus
tabular mathematical expressions that he's promoting
ass the right way to build software requirements
up to simplify this a lot so that I don't have to take time explaining
the details I mean it's fairly obvious how something this simple works
and it is precise and it is a document
so makes him happy harm
but let's look at what happens if you view code
as the model and the document and as the math
that you need here's another specification but says exactly the same
thing
as partisans tabular as that Tiger mathematical expression
and here's another and here's another and here's another
I'm sure all love you recognize at least one of those representations
they are just as much documents
that specify that operation as
the tabular mathematical expression on the previous slide
but the problem is that the the tabular mathematics
medical expression is merely a document
test unit or r-spec or cucumber
or fitness tests are no less documents but they're not merely documents
their documents that can up run
and analyze and validate a system against
the document requirements and be more than just a document
Norman Jack reeves wrote on his his
the paper testing was still expensive it was still very
it was very cheap to compile your design into a prototype but is still very
expensive to test it
in the eighteen years since then we've learned a lot about how to make
testing cheap so I returned my earlier question
how many how much math and informal analysis with your friendly neighborhood
aerospace engineer do
if building a prototype with his design and testing it
were affectively instantaneous and nearly free
because that's the situation we have in software
this is a diagram of from
Extreme Programming the granddaddy of at all processes
um and and these are the dependencies between the practices and
a catback document these as a way of argument
and and saying you know yes all these practices are flawed
but up a
it works because they have these other practices to backfill and fill in for
their
there a failings I'm and
about 10 to about five years ago I started thinking about how messy that
was an
and a wondering whether there was any
way to make sense of that and what I learned was
um you can take those practices
there are few that are truly practice is there more standards but you move those
at those
and you take the practices and you can lay them out and they
up for apply to different scales of
artifact and decision in your system
a pair programming you're working mostly with statements and Methods and
in unit testing and and continuous integration you're working
with the level of classes and interfaces and to some degree design
and all the way up to short releases are all about validating that you've got the
right solution to the customer's problem
and additionally
on they map well two different time scales
the smaller decisions in the smaller artifacts but we're gathering feedback
about those at the level of seconds and minutes an hour's
and the larger decisions on the larger artifacts it's more costly to gather
feedback about those so we get their feedback about them at all
scale-up days weeks and months
actual processes are economical
cost tuned feedback engines
this is about as empirical process design as you can get
but it's no less disciplined it's no less rational
for being empirical rather than to find
software engineering is based on a bunch of assumptions and summer those
were once true but are no longer true code is hard to read
code is hard to change testing is expensive
some others assumptions were once widely believed but they were never really true
all engineering is like structural engineering programming is like building
things modeling and analysis are about correctness rather them
controlling costs reality software engineering
is that it is a very unlike bridges and buildings
the additional complexity we work with hinders requirements design and approval
source code is a model building and testing are in room designs
is affectively free certainly compared to
the other engineering disciplines and empirical processes
are in fact rational processes for software developers
so if we wanna grow up as an industry has a field
the answer is not math it's not models it's not documents
and it's not copying other disciplines
the answers to learn from practitioners biased towards empirical processes
encourage continued innovation in processes
and do like other engineering disciplines do take the practices that
work
and call those engineering software engineering today is called agile
sorry for running over time thanks
