00:00:05.440
you look just like they said um my my boys will be immensely pleased
00:00:10.639
by that introduction thanks um am I on the screen so uh in one of the many Pearls
00:00:19.400
of Wisdom in Gerald weinberg's great book secrets of Consulting is one that he calls ronda's first
00:00:26.240
revelation and ronda's first revelation says it may look like a c Cris but it's only the ending of an
00:00:33.600
illusion um the uh the field of software
00:00:38.680
engineering originated in the middle of what was called the software crisis uh in the 60s as software
00:00:45.480
projects got bigger and more complicated and more ambitious uh you know by the standards of the time um uh they also
00:00:53.120
got uh more difficult to control and manage and predict and they would fail in various ways and that became more
00:00:59.600
common and so NATO of all things uh called uh
00:01:05.159
people from industry and Academia uh practitioners and theorists uh a whole
00:01:10.600
big group of people to Germany for the first software engineering conference in
00:01:15.960
1968 and um it actually got off to kind of a promising start uh but then for
00:01:22.240
various reasons that I won't go into in detail kind of uh went wrong and the result was that uh we labored under 30
00:01:30.000
years of this um that's a little unfair because the software engineering folks
00:01:35.840
did realize some of the limitations of waterfall and they tried other things but to my mind all of the traditional
00:01:40.960
software engineering processes sort of suffer from the the same fundamental limitations that waterfall did um and so
00:01:48.280
things were pretty unpleasant in the software industry or in large parts of the software industry for about 30 years until the late 90s when uh the agile
00:01:55.159
movement came along and and related to that you know practitioners and programmers began kind of taking
00:02:00.200
ownership of the processes and methods they used and how we deliver software um
00:02:05.320
and things got a lot better but the the sort of failure of the traditional software engineering ideas have given
00:02:12.319
rise to another crisis uh a couple of years ago Tom DeMarco who in some ways
00:02:17.519
was one of the fathers of software engineering published this article where he uh suggested that the idea of
00:02:24.040
programming as an engineering discipline was a failed idea that just needed to be abandoned uh closer to home my colleague
00:02:30.840
Bruce Williams back there early last year tweeted this I am not an engineer and neither are you I doubt you're an
00:02:37.400
architect either um both of these crises the original software crisis that led to the
00:02:44.319
software engineering field and and then the sort of Crisis now of oh we're not engineers and and uh maybe what we do is
00:02:51.280
incompatible with engineering and we should give up on that idea uh are really driven by the same illusion uh a
00:02:58.280
thorough misunderstanding of engineering and what it is and this was my response to Bruce um it's a little more Curt oh I
00:03:07.360
love you too Bruce um it's a little more CT than maybe he deserved but you know I was busy uh so let's talk about
00:03:15.040
engineering for a little bit and what it is um when you talk about engineering to people who don't have an engineering
00:03:21.280
training and background they tend to think of this list of things kind of you
00:03:26.360
know Engineers do a lot of modeling and mathematical modeling and formal analysis of those models and they write
00:03:32.640
a lot of documents uh designs and plans and they specify everything to the nth
00:03:37.760
degree and the goal of all of this is that the product of engineering is safe
00:03:44.599
and reliable and that the engineering product project is predictable uh budget
00:03:49.760
and time and and quality and all those things uh also if you talk to you
00:03:55.720
mentioned engineering to people who don't have an engineering background they tend to think of civil engineering
00:04:03.280
or more particularly large scale Structural Engineering Bridges and highways and things like that and that's
00:04:09.599
kind of a natural thing those things are obvious they're kind of easy to understand how you'd go about you know
00:04:15.959
you might not know how circuits or chemical processes work but you can conceive of how you'd go about building a bridge and uh we trust Our Lives to
00:04:23.560
those things every day um so that's what people tend to think about and if we take that list of things
00:04:29.360
people think about when they think about engineering and apply it to civil engineering as a kind of
00:04:34.400
checklist how does it work well they do a lot of modeling yes they do uh do they
00:04:40.160
do mathematical modeling and and and Analysis and formal analysis and specification and verification of those
00:04:45.840
models yes they definitely do and they definitely write a lot of documents and designs and plans and all those
00:04:52.840
things are they safe I don't want to at all suggest that Bridges and civil engineering projects
00:04:58.880
aren't safe because by and large uh and to extreme degree they really are
00:05:04.840
however uh with some regularity every few years there are failures of civil
00:05:10.240
engineering projects uh so while these projects are largely safe it's not a guarantee sometimes they they fail to be
00:05:19.160
safe as for predictability um if you're involved in local or state government at
00:05:24.520
all or pay attention to those things and look at the procurement processes you know that uh the the idea that civil
00:05:29.960
engineering processes are predictable are is kind of an illusion um often there are big cost and time overruns um
00:05:37.120
to the extent that they are predictable um it's the construction process itself and not the uh the
00:05:43.479
Engineering Process that's often the predictable part and uh also to the extent they're predictable um the credit
00:05:49.080
for that goes to Pro good old fashioned project managers not the engineers so uh uh that's kind of an
00:05:56.120
illusion so you know three and a half out of out of five for or 3.9 out of
00:06:02.160
five I'll give them for civil engineering but there are a lot of other kinds of engineering um civil instructural
00:06:07.720
engineering Aerospace mechanical these are just a few of the kinds of engineering uh that are out there and
00:06:14.720
I've kind of ordered this list from from sort of big scale things uh and big
00:06:20.039
scale concrete things not necessarily cement style concrete but physical uh tangible structures down to more
00:06:26.840
smallscale sometimes abstract things and um as you go down this list from the
00:06:32.720
large scale concrete things to the smaller scale abstract things um the rules change a lot and uh uh as you get
00:06:41.319
down into chemical and industrial electrical engineering um the costs are much less dominated by materials and
00:06:48.560
labor and they're more dominated by uh uh the cost of the design process and
00:06:54.759
and figuring out what you want to do and exploring Alternatives and things like that so for for example if we apply that
00:07:00.879
same checklist to industrial engineering uh it looks pretty much the same but there's a big piece missing how many of
00:07:07.919
you know uh people in the front people in the back don't bother raising your hand so I can't see you at all um uh
00:07:13.759
people in the front how many of you know what industrial engineering is or have a good idea of what that is
00:07:19.039
anybody just a few it looks like so industrial Engineers design and optimize
00:07:25.720
processes and often that's uh Factory processes Industrial Engineers design uh
00:07:31.360
assembly lines um often they design in collaboration with mechanical engineers
00:07:36.440
Factory Machinery so uh just to give you an example if any of you have ever been
00:07:41.520
into a crispy cream doughnut shop and seen the mesmerizing automatic donut machine uh that is really the product of
00:07:47.560
industrial engineering collaborating with mechanical engineers how much
00:07:55.000
mathematical verification and modeling and Analysis do you think went into the design of the crispy cream dnut
00:08:01.520
machine not much at all um it was almost certainly a uh uh an iterative sort of
00:08:08.440
tinkering uh project uh in the workshop putting stuff together and trying it to see if it works and wow the the dough
00:08:15.560
really sticks to these little bars here uh we got to figure out a way around that um so so it doesn't fit that sort
00:08:22.840
of definition of engineering that we've we've that most people tend to think about and um that's really nice my
00:08:29.800
confidence timer box is upside down it's going to be hard to read um so if I go over by like an hour that's why
00:08:37.959
uh so there's something missing from this which is that they do prototyping um as you work down that
00:08:45.080
scale and and towards the the more abstract uh kinds of engineering um they
00:08:51.200
tend to be more test driven uh if you want to use those terms we have an
00:08:57.920
idealized view of engineering and we tend to think of it as sort of uh very sophisticated and and and planned and
00:09:03.880
and predictable and well thought out and uh uh we tend to if we see something
00:09:10.279
that's rough heun and sort of something you could build in your garage or something an idea your kid would come up
00:09:15.720
with we don't tend to think of that as engineering and sneer at that kind of thing if it doesn't solve the problem completely in a very technical way
00:09:23.839
sometimes though engineering is just kind of Workshop stuff and Common Sense and it doesn't solve the problem
00:09:30.079
completely in a complicated way it solves it mostly in a simple way a good
00:09:35.240
example of that U the aerospace engineer Eugene Ferguson tells the story of his first engineering invention when as a
00:09:42.120
boy uh he took a trip to the airport and saw in 1937 uh A Douglas DC3 land for the first
00:09:49.720
time and he observed what all of us have seen either in person or uh in movies uh
00:09:56.839
the you know plane comes in as it touches the runway the tires which are not rotating yet hit the runway which
00:10:03.680
relative to the plane is moving fast and they Screech and there's smoke and the plane uh bucks as it um spins the wheels
00:10:10.680
up and everything else and he thought that's kind of cloy and crappy and it's potentially dangerous because the wheels
00:10:16.320
could blow out and that's a particularly fragile time for the airplane as it's first hitting the ground so um he went
00:10:23.120
home and sketched out a design for a mechanical device to spin the wheels up uh to approximately the airplane planes
00:10:29.600
ground speed just before touchdown and he sent this proposal off to the Douglas aircraft
00:10:35.240
Corporation and he relates the story of getting a note from you know presumably the Vice President in charge of crank
00:10:41.680
proposals from school children and uh um he explained that this was
00:10:47.399
actually a well understood problem and it had a name called pre-rotation and there were numerous proposals that had
00:10:52.440
been floated for how to pre-rotate tires and um all of them involved adding
00:10:58.000
weight to the airplane and to the landing gear and that weight would be better used increasing the tread
00:11:04.040
thickness of the tires um and Ferguson goes on to say
00:11:10.240
that that experience taught him that every technical problem has alternative Solutions often several one that was not
00:11:16.880
obvious to me was the Douglas solution to reject solutions that required more machinery and to use the weight saved to
00:11:22.800
make a simpler system more robust as an aside I think any of us in
00:11:28.680
this room who uh before coming to rails worked with web development in Java
00:11:33.959
Frameworks will have no problem seeing rails as something of a Douglas solution
00:11:39.720
to the problem of web development so anyway to do engage in a
00:11:44.920
bit of public gloating uh eventually Bruce responded with this you know by the way Glenn you changed my mind about
00:11:50.959
software engineering uh what's next architecture um and my response at the time was uh no
00:11:57.639
I'm not going to touch software architecture with a 10-ft pole but about 3 months ago somebody gave me this
00:12:02.800
business card uh so I guess I kind of have
00:12:08.160
to um have to think about software architecture now but um in any case we
00:12:15.000
all most of us anyway misunderstand engineering and to some degree even Engineers have an idealized view of what
00:12:22.560
Engineers do we understand con concrete things better than abstract things and so we look at the obvious ible things
00:12:29.760
that Engineers do and we think those are the fundamental things but really the documentation and the math and and and
00:12:36.199
the modeling and stuff isn't aren't the fundamental parts of engineering um and there are very few engineering books that talk about this but if you're
00:12:42.199
interested just a quick recommendation uh two books what Engineers know and how they know it by Walter
00:12:48.440
vincenti and Engineering in the Mind's Eye by Eugene Ferguson the guy who told the DC3 story are well worth
00:13:02.120
case that really programming kind of fits into engineering you know somewhere along that Continuum down down near the
00:13:08.279
abstract uh side of things um but let's talk about programming a little bit programming does differ from the other
00:13:14.360
engineering disciplines in two really important ways and uh one of those is that um I'll
00:13:23.519
talk about one first uh software engineering field the way it was originally conceived was designed by an
00:13:29.360
analogy with more traditional engineering disciplines and the analogy goes something like this in traditional engineering disciplines you have
00:13:35.680
engineers and those Engineers are tasked with producing designs which they draw or write down on paper and those designs
00:13:42.560
are handled handed to laborers or construction workers who build the finished AR artifact and if that's what
00:13:50.199
the process of engineering looks like then what would the process of software engineering look like it seems pretty
00:13:56.160
simple and obvious right you have Engineers Maybe the same guys just uh you know retrained and uh they produce a
00:14:04.040
design and write it down on paper and they hand it to laborers who toil in
00:14:09.560
their cubicles and uh produce the finished
00:14:15.399
artifact and um people kind of went with this uh analogy for a long time even
00:14:21.720
though it didn't really work very well uh until about 1992 uh when and well you know some
00:14:27.440
people had realized this before but uh a guy named Jack Reeves in 1992 published an article that said you know we got
00:14:32.839
this all wrong and the key to the problem to realizing there's a problem is that second slot there second part of
00:14:41.160
the process we have never figured out a way in software to specify a design in a
00:14:47.079
way that's clear enough and thorough enough and you know uh able to we can
00:14:52.360
reason about enough to know that it's correct and then hand to programmers and they can produce the working system with
00:14:58.279
any kind of fidelity to the original design without redesigning and adding that to that design and all those things
00:15:04.880
so he said work with me on this and try a thought experiment let's get rid of that design document and teach the
00:15:11.519
programmers to think of themselves as engineers and do things that way and you know that source code that's not really
00:15:18.440
the finished artifact that's not what customers are paying for they're paying for deployed systems running on real
00:15:25.000
machines and solving their problems that source code is actually the design of
00:15:30.880
the Software System maybe not the whole design it's still sometimes useful to have diagrams
00:15:36.639
and and high level overviews and introductions to part of the system uh that can be read without looking at
00:15:41.920
source code but when it comes to the detailed design of your system the source code is
00:15:47.880
it so then what do we fill the third slot
00:15:53.399
with anyone the close running well that's the
00:15:59.680
fourth thing that's the artifact they're paying for what's the third slot compilers programming language
00:16:04.759
implementations go there and then you end up with running software which is what customers actually
00:16:12.600
want Reeves pointed out that uh you know there is a really big difference between
00:16:18.800
these two things the analogy still works right but all of a sudden the costs are
00:16:24.240
upside down the third step in the top row is by far the the most expensive it
00:16:29.959
dominates everything in Structural Engineering uh the cost of material and labor um and as a result they have all
00:16:38.000
kinds of tricks to avoid spending money on building prototypes and testing them
00:16:43.160
in fact we tend to think of mathematics and formal analysis as a tool that the engineering disciplines use for
00:16:48.279
achieving robustness and safety but uh if you look at the history of the fields
00:16:53.319
mathematical mathematics and formal analysis were introduced as a cost-saving measure because if you and
00:16:59.360
uh build a model that's that approximates reality and do some analysis on it you can reduce the amount
00:17:05.439
by which you over engineer uh and uh reduce the cost of materials so the
00:17:11.400
third step on the top row is by far the costliest and the most timec consuming
00:17:16.959
and the third step in our field is by far the cheapest and fastest and that changes everything we
00:17:24.000
do and that's why the proper engineering approach to uh software is not to load
00:17:31.400
the front of the process with a bunch of analysis and inspection and verification but rather to be iterative and build
00:17:38.120
many prototypes of our design and test them
00:17:46.520
okay let's focus in on this a little bit
00:17:53.240
more is there a model here I'm not going to be able to hear
00:17:58.840
hear you unless you yell is there a model here
00:18:04.440
maybe that's actually a pretty good answer in in the best case uh yes
00:18:10.440
there's a model uh visible in the source code is there a document
00:18:16.880
here the source code is there math here yeah it's the source code computer
00:18:23.799
programming languages are formal languages and some of them even have mathematical specifications we're at a
00:18:28.919
ruby conference so we don't have that but um you know still Ruby is executable
00:18:34.840
math um all those things are there it just doesn't look quite like uh it looks
00:18:40.360
in classical engineering and let's focus on the document issue in particular um there
00:18:46.600
have been all kinds of proposals for how to document the requirements and specifications of of software
00:18:53.000
systems um I want to show you four documents they document a very simple
00:18:58.480
process C because it had to fit on a slide but uh here are four documents a junit
00:19:06.120
test an rspec example a cucumber
00:19:12.200
scenario and a fitness test table those are all documents and
00:19:18.760
they're all specifications but they are not merely
00:19:23.799
documents in the classical engineering disciplines where they have to work with physical materials they're not working
00:19:30.880
with pure abstraction and pure information uh they have to work with
00:19:35.919
mere documents we get to work with documents that are more than just documents but they execute and verify
00:19:42.280
themselves and verify uh an implementation against those specifications we get a huge benefit
00:19:48.559
from that and any process that purports to be a software engineering process and
00:19:55.159
doesn't doesn't acknowledge the upside down economics where expensive in traditional engineering disciplines is
00:20:01.240
the cheapest part of our work and that doesn't deal with the fact that our documents and our math can execute and
00:20:06.880
do real work for us uh is not acknowledging the realities of our
00:20:13.720
field so I mentioned that uh engineering is different from um that software is
00:20:19.000
different from other engineering disciplines in two important ways and one of them is this upside down cost model and the nature of what we do the
00:20:26.360
second one was uh pointed out to me by a guy who uh wrote To Me named Zay bidder
00:20:32.200
one thing electrical engineers do not do is to sit around Pon pontificating about whether electrical engineering counts as
00:20:37.559
real engineering I suggest that we should uh
00:20:44.320
um choose to be just like the traditional engineering uh disciplines
00:20:49.440
in this respect at least now there's a third crisis
00:20:59.000
would we prefer to be Engineers or would we prefer to think of ourselves as Craftsmen and if we consider ourselves
00:21:06.200
Engineers what is the role of craft in what we do and if we love being
00:21:12.279
Craftsman can we still think of what we do as an Engineering Process and and and
00:21:17.440
be that disciplined about it not that craftsmanship isn't disciplined
00:21:28.640
let's think about the difference to the extent there is one between Craftsmen and Artisans and
00:21:36.400
engineers and since we've been talking about documents let's focus our discussion on documents for a minute an
00:21:43.159
artisan or craftsman May doesn't have to but may produce documents to help
00:21:48.279
themselves think but then they build what's in their
00:21:53.960
heads that sounds an awful lot like what we do except then when we build what's in our heads it turns out to be a
00:21:59.840
document too Engineers on the other hand must produce documents well they they they
00:22:06.159
produce documents to help themselves think but they don't have a choice in the matter they must produce documents
00:22:11.640
uh to convey the design to builders and that's the primary purpose of those documents and that's because the the
00:22:16.840
engineers are not the Builders of the things they design they are divorced from that and a
00:22:23.840
lot of that divorce comes from again the need need to deal with physical material sometimes at Large Scale it might be
00:22:30.240
more than one person to do uh the skill set for Designing the thing and actually building it might be
00:22:37.240
different so they have to convey that design to the builders but for a minute let's look at
00:22:45.880
some models and documents that Engineers produce and we're going to start with we're going to
00:22:51.600
start at the top of that list I showed earlier civil and structural uh uh engineering and work our way down to the
00:22:59.120
the more small scale abstract kinds of engineering um bending moment equations
00:23:05.559
and models for Bridges handwritten sometimes more
00:23:11.679
formal sometimes a bending moment diagram notice that these models bear
00:23:17.520
very little resemblance except in a very abstract way to the artifact that's being
00:23:26.760
built but then you get to Space Engineering and there's a lot of that same kind of thing but there's also models that at least are physically
00:23:33.960
accurate for the envelope of the structure uh so you can test it in Wind tunnels and airplace Engineers do a lot
00:23:39.440
of wind tunnel testing with models that look like what's ultimately going to be built and mechanical
00:23:46.000
engineers when you get down to electrical engineering things are more abstract still and apart from the fact
00:23:52.720
that it's usually threedimensional structures or two and a half dimensional structures compressed onto a two-dimensional sheet of paper paper
00:23:59.159
this is starting to look very much like the artifact they're actually
00:24:04.559
building as the engineering discipline becomes more abstract the models can
00:24:10.679
become more
00:24:16.159
concrete and then there's software how much of a resemblance does
00:24:21.200
this bear to the thing that's actually Built Well if you want to think of it in
00:24:28.039
terms of you know btes and registers running through the CPU and the instruction Pipeline and and all that
00:24:33.760
stuff given that this isn't an object-oriented uh language and and CPUs aren't objectoriented at all uh this
00:24:40.679
doesn't seem to be much of a correspondence but the designers of
00:24:45.880
programming languages with the possible exception of some of the languages we saw last night uh make sure that there's
00:24:51.399
a perfect isomorphism between the constructs in the language and the constructs that get run on the
00:24:57.080
computer so in some sense this is exactly the artifact that gets built and
00:25:03.480
it feels like that to us when we're writing this code doesn't it we don't think about that
00:25:09.480
transformation to uh uh sets of instructions and data stored in memory
00:25:14.880
locations and loading things into registers uh we think about classes and methods and variables and the constructs
00:25:22.200
we work with in code and we know that the compiler or The Interpreter will take care of maintaining that
00:25:28.760
isomorphism so that what we write gets executed just like that on the
00:25:36.080
CPU software engineering is the most abstract of engineering disciplines and our models are the most
00:25:42.480
concrete for what we do another interesting thing about
00:25:49.559
engineering modeling is that as um computers and software have become more
00:25:55.960
powerful even in the traditional engineering iines their models have started looking less mathematical and
00:26:02.559
more like simulations and so it turns out to be
00:26:07.679
cheaper and more uh effective in many cases to build a simulation style model
00:26:14.080
a prototype in software if you will than to formally model things as systems of
00:26:20.279
equations and so in electrical engineering you have uh circuit simulators that help with the the
00:26:25.880
circuit design process um and CAD cam systems that can do more
00:26:31.480
than help you draw things but automatically take Parts through all their degrees of freedom and check for
00:26:37.120
uh collisions and and possible abrasion between parts that would interfere with the working of the machine and fluid
00:26:43.320
dynamics modeling of how landing gear affect the airf flow uh uh around an
00:26:49.480
airplane as it gets close to uh Landing um propeller uh Dynamics uh Statics
00:26:56.760
modeling of bridges uh and also um for purposes of traffic
00:27:03.039
engineering which is another engineering discipline uh modeling of airf flow around structures to see how that will
00:27:08.440
affect uh cars on roadways and pedestrians and things like
00:27:13.840
that so software is changing the way traditional engineering disciplines uh are working and W allowing their models
00:27:21.520
to be less abstract and more Concrete in similar ways to those that ours are so
00:27:27.840
about to conclude software
00:27:34.039
models because our artifact is abstract our models can be Concrete in
00:27:40.919
the sense of feeling like we're working with the real thing the model is isomorphic to the built artifact there's
00:27:47.720
a direct correspondence between what we write and what gets executed uh and I
00:27:52.880
can prove that because uh um you know as uh uh Dave Thomas and Andy Hunt point
00:27:58.320
out in the pragmatic programmer it's never really a compiler bug right the result of these things is that
00:28:05.640
modeling feels to us like working directly with the runtime
00:28:13.279
constructs and we feel those things as we work with them Corey are you still
00:28:19.799
here now you had to go so Corey has been tweeting recently about the software
00:28:24.840
he's currently building pushing back on him and and uh telling him that it needs to be designed in a different way and
00:28:31.880
sure enough he tried that and it was way better um how many of you have a physical sense of the objects and and
00:28:38.720
and values and things that that run through the software you're building as you're building it
00:28:44.159
anyone a lot of us we have a spatial model and it feels like we have our
00:28:49.679
fingers in that thing it's totally a construct of our brains but that's the way it feels to
00:28:55.360
us and because of the nature of software where we're not isolated from the building process of our our things we
00:29:03.000
we're the designers and the builders the compilers just do the grunt work to us it feels like we're building the end
00:29:11.080
product and furthermore we are also writers um our code must serve two
00:29:18.799
purposes it has to be the solution and it has to describe the
00:29:24.360
solution it can do both of those things in one document
00:29:30.360
so brief degression here the cinematography technique you're
00:29:36.960
about to see is called racking focus and in this technique the the director and the photographers uh
00:29:43.799
arrange for something important to be in the scene from the beginning but out of focus so our attention is not drawn to
00:29:51.120
it and most viewers won't see it at all until the focus changes and brings what
00:29:56.320
was previously invisible to our attention now in this scene this scene
00:30:02.320
from the Spider-Man is such an extreme case uh that it it's really just an optical trick unless you knew that
00:30:08.519
spider web was there and knew to look for it you couldn't possibly see any part of it um usually the technique is
00:30:15.159
more restrained here's a scene and it's going to be a little bit dark on these screens I apologize this is a scene from
00:30:20.880
the old 1980 movie uh the stunt man and um Peter oul is visible from the
00:30:27.279
very beginning of this scene in the background and he's even recognizable because he's such a distinctive looking man but most viewers of this scene
00:30:34.320
wouldn't notice him until uh the he's brought into focus and your attention is
00:30:39.679
drawn to him what we focus on matters and the things we don't focus on
00:30:46.519
can completely Escape our attention and the fact of the matter is
00:30:51.640
in software some things are easier to focus on than others one of my favorite quotes about software is this one from
00:30:58.200
son and susman programs must be written for people to read and only incidentally for machines to execute I love that I
00:31:04.919
use it all the time I think about it all the time if you take it at face value it's utter
00:31:10.519
crap we don't get paid for for programs that people read we get paid for programs that execute on machines and
00:31:17.320
work and do useful stuff and you know sometimes people kind of miss the point with this and they do
00:31:23.600
take it literally um and one of those is a dear friend of mine Dan North who
00:31:28.679
recently wrote you know software practitioners often fall in love with the software itself and start thinking of themselves as Craftsmen of software
00:31:35.360
and he went on to describe how this is a bad thing because of course nobody pays us for those internal things that nobody
00:31:41.880
pays us for source code that's fun to read they pay us for code that works but you know uh I love you Dan but
00:31:49.720
ablon and susman are engaging in a technique you may have heard of called hyperbole um and and they're they're
00:31:55.760
exaggerating a little bit to make a point uh somebody who makes the same point uh in a more straightforward way
00:32:01.480
is Donald kth let us change our traditional attitude to the construction of programs instead of imagining that
00:32:07.320
our main task is to instruct a computer what to do let us concentrate rather on explaining to human beings what we want
00:32:12.960
a computer to do see the difference is is not whereas abelon and susman talked
00:32:18.519
about uh we shouldn't do this we should do that kth is talking about where our focus is and it's really important that
00:32:25.559
our Focus be there because um our systems uh have this
00:32:31.760
internal and external dichotomy uh the internal things the internal quality of our systems its
00:32:37.960
internal structure is abstract and the external behavior is concrete and our customers notice it and
00:32:45.080
draw our attention to it the internal things are hidden and in
00:32:50.480
fact only we can perceive them because you have to understand software and be experienced with it in order to look at
00:32:57.000
those things and see whether it's good or bad in many cases but the external qualities are public and
00:33:03.679
visible and finally the internal qualities have potential
00:33:09.559
effects that may or may not come to pass and and your expertise can help you judge the likelihood of that but the
00:33:15.159
external qualities have immediate effects that your attention is drawn to now but that doesn't mean those internal
00:33:22.159
qualities are not important and they're important because they do have those potential effects that can bite us or
00:33:28.840
reward us later but in order to do a good job with
00:33:35.600
those things we have to focus on them because we're working with pure
00:33:41.240
information pure abstraction because we are writers because we are creators and
00:33:49.720
designers we have the luxury of being both engineers and
00:33:55.639
Craftsmen we're both designers and makers we are not insulated from the
00:34:00.840
artifacts we're designing and like Craftsmen we can feel the things we build and its quality
00:34:07.360
affects us emotionally we have this luxury and we also have a responsibility
00:34:14.359
to be not just Craftsmen but also Engineers because otherwise or to be Craftsmen and not just Engineers it's a
00:34:21.159
luxury and a responsibility because otherwise we would inevitably lose sight of the less tangible but no less
00:34:26.560
important aspect of our Creations thanks very much