>> Rob DeLine: Good morning, everybody. It's my pleasure this morning to introduce a
good friend to the hip research group here at Microsoft Research, Susan Sim from the
University of California at Irvine.
Like us, she's very interested in sort of human aspects of the software development
process, and she tells me that she has a very sort of nontraditional format talk for us this
morning. So I'm very intrigued and anxious to see it. So welcome, Susan.
>> Susan Elliott Sim: Thanks, Rob, for the introduction. So I'm going to be talking
about some work that I've been doing, more thinking than work. It's heavily influenced
by science and technology studies.
As I looked back on the research that I've been doing for the last ten years, I've been
looking at psychological factors in software development, I've been looking at social
factors in software development. And anytime I look at social factors, there's the
psychology or the organization. And when I looked at the social factors or the -- there's
always something missing from the picture. And as I brought more and more stuff in, it
got more and more complicated.
I also got into science and technology studies because it seemed to provide a way of
dealing with more stuff or more factors. Also, for my Ph.D. thesis I worked on
benchmarking, which is an evaluation method for software tools. I also -- in order to
interpret my results, I used Thomas Knuth's theory of scientific revolutions about
scientific paradigms and things like that.
So I already got my toes wet into science and technology studies.
So science and technology studies, what it tends to do is look at -- let's see. See if we can
wake this up. The computer's gone to sleep. So science and technology studies is kind of
like you take your -- there's psychology. You take your sociology or your social factors
and you place it within the context of a culture. And you also place that culture in the
context of history. And it's the idea that people are essentially the same over time. The
trappings might change, the clothes that we wear might change, the devices that we use
and all of the technology might change, but we are essentially the same.
And so it has that basic idea. And it's really good at asking broad, sweeping questions
about what is the nature of the things, what are the interactions. It's not so good at
answering questions.
So I've been thinking about the question of what does it mean to program a computer.
Because this is at the heart of a lot -- this is the kind of question that STS asks, but also I
think this is the kind of question, the kind of what if question or the fundamental question
that will lead you down alternative paths or lead you down other pathways.
In building software, you try and identify what the requirements are in the beginning.
But when you're working with the customer, customers often have a difficulty expressing
what their requirements are because they're too entrenched in their own environment to
see outside. Also, they don't know what the capabilities of the technology are.
So you need somebody who is a technologist, a requirements engineer, software
developer, or somebody like that to go in and you do a little bit of psychotherapy and say
what is it that you really want to achieve here. They call this paving the cow path.
Sometimes customers just ask you to automate what it is that they've already done instead
of build me a better way. And so by asking this kind of question, then we can figure out
whether we are paving the cow path when it comes to software tools or is there another
way, is there another way to do what it is that we want to do.
So the question I'm starting out with is what does it mean to program a computer. And
we all have an intuitive sense of what this is, because you can -- if I told you is this
person technical or is that person technical or not, you have a pretty -- you can tell me
pretty quickly whether someone is a real programmer or not. So a systems programmer
is a real programmer, Visual Basic programmers are not real programmers or, say, a
Goowy programmer may not be a real programmer.
So we have these intuitive ideas about what is real programming or what is not
programming. So what does it mean to program a computer?
So the title of this talk deliberately riffs on Donald Knuth The Art of Computer
Programming. And this is a pretty hardcore idea of what it means to program a
computer. So this is the second edition, it has three volumes in it, of a planned seven,
eight volumes. He's working on the fourth volumes right now, and he has to keep
releasing subsections of it because it's getting to be too big and he's talking about turning
that into two actual volumes. He may not finish this before he dies.
But, in general, computer scientists revere this work. They think this is a huge
achievement. It's a pinnacle in terms of intellectual work. Firstly, it's got analysis of
algorithms, running time efficiency. And he's trying to comprehensively cover all of the
algorithms that we know.
And it's not even written in a high-level language. The code examples that he gives you
are in machine language so that you will have a basis for comparing the complexity and
time costs of each of these algorithms.
So this is a particular view of what programming is. It's very mathematical, very
algebraic, that this is what it is, and that the pinnacle or the kind of achievement this
represents is like more like math than it is like human factors. If somebody is sitting in
front of a computer entering the codes instructing the computer, telling the computer
what to do, these are the steps. Execute this and if you do it right, we're going to be okay.
I should mention that this is work in progress. This is the first time I've given this talk.
And I don't really now how to publish this work. So if you have any comments for me,
feel free to stop and ask me questions or talk to me afterwards and say, oh, this is what
you can do with it.
So what is the image of the programmer that comes out when you hold this up as a model
or a paragon for programming? Well, it looks like this. Okay. It's a stick figure,
genderless. No clothes. I mean, not that he's naked, or she; it's that the clothes don't
matter. You know, they're -- the gender doesn't matter, all of the social trappings don't
matter, there's the chair and there's the computer and the person sitting in front of it.
That's it. What's the most important thing? The noggin that is driving the figures to type
things into the computer.
This comic is taken from a Web site called xkcd. Does anyone read this? Yes. Okay.
So ubergeek, very, very geeky, but I just laugh so much. I guess it just shows how much
of a geek I am.
Most of the drawings are stick figures. And the joke here, if I had to explain to a space
alien or an English major why this is funny, right, that it's a person sitting in front of the
computer, but also there's both contrast against Knuth's ideas of programming and also
what is actually done when you develop software. Where in Knuth does it talk about,
you know, my code is crashing when given pre1970 dates?
Knuth does algorithms. This is software engineering. This is programming in the real
world. This is -- pre1970 dates is significant because, you know, the beginning of epoch
was in 1970. And so UNIX times are given starting 1970. But where does Knuth talk
about this?
And also this interaction here, the person telling the joke to the guy, this is funny because
we have this culture. We have this funny culture because we like to take things literally,
but we also kind of step outside ourselves in terms of taking things literally. We're very
mathematical, very analytical, but we're analytical about being analytical. And so we
make a lot of jokes like this, that it's both a pun and it's also, you know, uses domain
knowledge. Someone who doesn't know about the epoch, and also it's a play on word, it's
an upon that -- you know, epic versus epoch.
And so it's not only -- this looks like just somebody typing on a computer, but it's not.
There's so much more there. And it's only when you start having to take these things
apart. And this is what science and technology studies is really good at, at providing you
these lenses for taking these things apart.
Because when you look at the sweep of history, when you look at the sweep of different
cultures, for example, epic and epoch are only close with an American accent. If you do
this with a British accent or an Australian accent, it's not as funny. So this is where you
start to see the culture, and also the sweep of history.
All right. So I'm going to show you -- does anyone recognize this? It's the difference
engine. This is built I think about five years ago. Charles Babbage's difference engine.
Often hailed as the first computer. I mean, when you get into it, there's lots of debate
over what constitutes the first computer. But a lot of people say this is the first computer.
And I'm going to play you a little video. It's -- I apologize for the quality of the video.
But I was reading about the difference engine. I'd even read William Gibson's book on
the difference engine, and I said, oh, well, big whoop. You know, it didn't work, he
wasn't able to build it, it was so big; this, that and the other thing. And it wasn't until I
applied an STS lens and also that I saw this video that these light bulbs went on and said,
ah, what are we doing.
Okay. So let me try and find this video.
[video playing]
>> Susan Elliott Sim: So that's the difference engine. It was built to create calculation
tables. I think the closest thing that we have these days is maybe looking up F values,
when you do statistics -- that, you know, if you've ever done statistics as an
undergraduate that you calculate your FLU and then you look up in a table where it's
statistically significant or not, that's the only place I've ever seen these kinds of
calculation tables used. Also maybe in the back of your trigonometry textbook you might
have a table of sign and cos values.
But back in these days, everybody used these values because you didn't have calculators,
you didn't have a device that you carried around to calculate these things for you. And if
you wanted to know them in any practical, usable way, you would have to look it up on a
table. And so the production of these tables was a tedious, time-consuming, important
problem. And this is the exact problem that Babbage was working on.
Okay. Where's the software? You see the hardware, but where's the software?
>>: I don't think there was any.
>> Susan Elliott Sim: Ah. Okay. So one possible answer is that there is no software.
Because the idea of software hadn't been invented yet. But what does it mean to program
this, right?
So the thing with this is a -- software as we know it didn't exist here. But this device was
programmed and it was programs using hardware. And it didn't calculate -- this is -- one
of the things that set this apart from devices that came before it, is that it would calculate
an arbitrary equation, I mean, within certain constraints. It would only do certain powers
and it could only have a certain number of terms. And the final answer you could have at
most 32 digits.
But the equation that it calculated could be entered into it somehow. You would -- and
basically you go around backing, you flip a bunch of switches. And so that's how you
programmed the software, or that you programmed -- I mean, programmed this device. I
mean, compared to -- they would have logarithmic computational devices that you would
have a little machine that you could crank and then you could say calculate the log of
something, calculate the sign of something. So you would have purpose-built devices
whereas this one you could hang the equation that you were calculating.
So where's the software? So the software in the single-purpose device and the hardware
were together. I mean, it just is arbitrary where you draw the line. I mean, you can see it
these days, what's hardware, what's software. The most obvious difference now is your
graphics cards. You know, what used to be in software has been put into optimized
hardware for calculating pixel locations so you can have really spiffy graphics. I mean,
the line is shifting. The line shifts depending on what you build into the hardware.
Where's the software here? Just depends on where you draw the line.
I mean, it calculates equations. That's fixed. That's built into it. What you input as or
what you program into this to calculate or what equations to calculate is in the back.
There's a number of features of this that is eerily similar to modern systems. One, 32
digits, you know, why 32 digits? Well, you could say multiple of two. But he's working
with digits. I mean -- and, you know, when we do binary now it's base two. Okay. Why
32? This thing here is the handle that drives the whole thing. You would have to turn the
crank around four times in order to do one step in the calculation. This is very similar to
the clock in your logical arithmetic unit, the thing that you learn about in undergraduate
computer architecture.
This is the tempo, this is the calculation each step goes around and around like that. I
mean, it makes you wonder how much of what we're doing has been influenced shaped,
limited constrained by the history of computing, the by the different inventions that
people have come up with.
Okay. So that was the slides for the video. Ah. Anyone recognize this? ENIAC.
ENIAC, or ENIAC, depending on what your accent is.
Okay. Can someone point to the computer? This is the computer. I am note making -her job title is computer. Okay. During this era, and everyone before, from in the 1940s,
1930s, 1920s, they hired young women, and it was always young women, to be
computers. And they would -- their job title is computer.
And what did they do? Well, they did math. They derived -- they did integrals,
derivatives and things like that. They calculated numbers very similar to what the
difference engine did. Like, you know, I need you to calculate blastics tables, I need you
to calculate this or that. And they just did math all day, and then they print out these
tables and other people would use them, or that I need to calculate some kind of
optimization, I needed some kind of what is the best way to do this, what's the best way
to use these resources that I can get the most out of it. So that's the computer. She's the
computer.
This, they thought of it as a big, I don't know, calculator, right? It was just a device. And
I really like this model here. So if she's the computer, who's the programmer? Who's
programming -- who's programming the ENIAC?
Okay. So what does it mean to program the ENIAC here? This guy, he's got the
mathematical equations that he wants to calculate. The ENIAC was generally used for
calculating the basic tables, which are, you know, how high should I point the gun and
with how much force should I shoot the ammunition so that I can reach a certain place.
And much of large hardware and software development in this era was driven by military
requirements, either breaking the code, the enigma code or any decrypting
communications, and also for making ballistics tables.
So this drove a lot of the software development and hardware development. So he's got
some equation that he wants calculated. And she is rigging up the machine to do the
calculation that he wants. And I try to give this explanation to people, and they say, well,
isn't she just a compiler. And if she is just doing rote allocation of equations, is she really
a programmer or is she -- you know, is this a skilled job.
There's no question that this is a skilled job. Someone gave them a bunch of these
devices and say make it sing and dance, no manuals, they had to figure out how to do all
of these things. Yeah.
>>: The person who built the entire thing, did they think it was a computer or did they
think what -- did they really think it was just a calculator, a fancy calculator?
>> Susan Elliott Sim: It -- the history is ambiguous, because there's shifting terminology.
They weren't quite sure -- I mean, to say that it's just a computer is kind of belies our
modern mind set. All right. I think they -- I think in modern terms they would have
thought that it was a computer. But their idea of what computer meant is different from
what we think of computer.
>>: At the time, like adding machines, mechanical adding machines were commonplace,
both in [inaudible] business but also in these kind of computer sweat shops. So, yeah.
>> Susan Elliott Sim: Yeah.
>>: [inaudible] just a question of degree [inaudible].
>> Susan Elliott Sim: Yeah.
>>: Which we're getting more and more [inaudible].
>> Susan Elliott Sim: Yeah. Yep. So how you actually programmed the ENIAC was
using wires, was using, you know, hammers, wrenches. So each one of these boxes was
a logical unit in that it performed a particular calculation, for example, this might be the
cubing unit and this might be the squaring unit, this might be the addition unit. And each
one of these things represented one of the bits in the calculation and so that you would
take the results of this computation and then run the wires to square it, and then you
would run it back to -- run it somewhere else to take the log of it or something like that.
So what was programming? Moving wires.
And so this is -- puts a lot of what we're thinking on its head, and yet this is part of our
history, this is part of how we think about programming. Come back. There we go.
So many of the first programmers, you know, many of the first computers, computers
were originally women. And so for a long time, this was a female-dominated field. Like
almost all of the programmers, all of the ENIAC programmers were women. They're the
ones who were the first people who came up with the ways of controlling the machine to
do have it do arbitrary tasks.
Just in case ENIAC is viewed as an accident, hears a bunch of pictures that I found on the
history of computer Web site or the computinghistory.org Web site. So the bomb which
is based on a Polish machine used by the British to break codes during World War II,
that's a woman in front of it. The Colossus machine at Bletchley Park, again, a woman.
The ENIAC machine, about half women in that picture, the IBM SSEC, the MANIAC
machine, I think at Harvard, and then JPL. I love this picture. 1955. This entire room.
Manhattan Project. If you read Feynman's memoirs, he talks about working with the
women there. Yeah.
>>: [inaudible] Star Trek the original series? Right?
>> Susan Elliott Sim: Yeah [inaudible].
>>: [inaudible] explain why culturally -- right?
>> Susan Elliott Sim: Yeah. So here are the explanations for why culturally. One,
computers -- the job title -- were originally all women. Right? So you hired young
women with good math skills to calculate these things. What else? Computer
switchboard -- or telephone switchboard operators. Somebody calls in, you find out
where you want to call, you pull out the plug and you plug it in somewhere else. That's
awfully like programming the ENIAC. Right? You take a wire and then you run it in
somewhere else.
There's a third factor -- it just escapes me at the moment.
But, yeah, so cultural factors like that, yeah.
>>: Do you have an understanding why they favored the women for those jobs, were
they better at the math, were they [inaudible]?
>> Susan Elliott Sim: Well, it's culture that these were acceptable jobs for women.
Yeah.
>>: There's also historical [inaudible] computer job titles started in the Civil War and
essentially [inaudible] a lot of women to [inaudible].
>>: Yeah. Especially if you're sending the men to go and fight or if there's -- this is also
the gender division of work, that the men made -- designed the computers and then -- or
designed the devices and then the women did the programming.
>>: So it also strikes me, this lower left picture, just as easily could be a stenography
pool or [inaudible].
>> Susan Elliott Sim: Exactly. That was ->>: Or a typing pool.
>> Susan Elliott Sim: Yeah. That's exactly it.
>>: [inaudible] of the era.
>> Susan Elliott Sim: That was the third reason that I -- that escaped me. Okay. Punch
cards. What does that look like? You know, typing? Stenography?
And this picture, I don't have a date for it, but you can figure it out maybe from the
hairstyle and the clothes. This is where it all went horribly wrong. And this was an
advertisement for the computer, and here's a user, anyone can use it. Hmm? It's like the,
you know, putting a woman next to it and saying anyone can use it.
And so I -- in the past I've done studies of, you know, the participation rates of women.
And when the first computer science degrees came out, women's participation rates were
really high, you know, up in the 50, 60 percent range. Especially when they started out in
the math and physics groups of different universities. And it was viewed as an academic
subject. And so if you were good at math, this was a natural transition for you.
It may -- so and the numbers kind of peaked in the '80s and then they've gone down and
down and down ever since. That's a separate discussion. That's an entire talk all by
itself. But we can think about that. Another thing that may have contributed to this is
that with the creation of Fortran, they -- so Fortran, when they -- after they came out with
Fortran, they said, okay, anybody who's good at math can do the programming now and
anyone who's good at logic, it doesn't just have to be the specialists.
And so they started recruiting chess players to be computer programmers. And so that
started to tip the balance more towards men, because they found more male chess players.
So that contributed to it as well.
So this is one of the -- so the point here is that -- what is an appropriate role for someone,
the culture of what determines someone's career choice and what the possibilities that
people see for themselves are socially and historically determined as well. I mean, look
at all the historical examples that we just brought up.
Okay. Who recognizes this? Fortran. Fortran. The first programming language. Every
single family tree or genealogy of programming languages starts with Fortran at the
beginning. Fortran is the parent of every language that has come since. Fortran is a
high-level language. It was created in 1953 by John Backus. And it was created in
response to an economic problem, not an intellectual problem.
It's not that someone came along and said, boy, it'd be cool to have a high-level
programming language. It's that the cost of programming computers became so high that
they said we have to find a cheaper, easier way to do this. Because they would build
these machines, millions of dollars. In order to set it up to calculate a particular equation,
it would take about three months to set up all the wires to have it go just so. And then it
would run for a couple of weeks. They would get all the numbers that they needed, they
would print the tables, and then we'd do the next job.
Computers were becoming more pervasive. Everybody wanted one. They could do all
sorts of cool things with it. You know, you could keep your accounts, you could keep -you can calculate inventory and things like that. But even though people wanted
computers, they didn't necessarily have the computers on site. So computers IBM was
offering as kind of a service. We would host the computers, you would have a share in
the computers, we'd host this computer for you, we'd have the programmers for you, you
just tell us what you want it to do. And so they -- so when the cost of developing the
software, so telling the computer what to do began to outstrip the cost of the hardware,
that's when they say we've got to make this easier.
So stored programs. Programs that were stored in software, whatever software meant,
because this was still punch cards, punch cards are physical, but this is software. So
where's the software. Oh, okay. So we're starting to see modern lines emerge here.
So they would store the cards -- they would store the software in cards, and it would -yeah, this is readable, right, you could read this as a human being. And that was the
whole point. And it's not just that Fortran was a language; Fortran was also a body of
technology, including the compiler that made this possible.
Grace Hopper made her name by coming up with intermediate codes that were more
human readable that you would translate into computer code. And she came up with
these techniques by hand. You know, when you see this, translate it to this number.
Again, your undergraduate compiler course, this is what you learned.
John Backus came up with an entire infrastructure for doing this. And also not only did
you translate the codes, if you see this turn -- write into this code, if you see this, just turn
it into this code. Some of it was very mechanistic, very algorithmic.
But part of it was that he used dumb solutions instead of really clever human solutions.
For example, the allocation of which instruction goes where in memory, where you are
going to place these instructions was considered a real art. And this is where John
Backus received a lot of his resistance, that automatic programming -- this is what
automatic programming is, is not possible. You can't possibly do as good a job as human
beings laying out these instructions in memory.
Now, this is not one of the criteria for what is a real programmer these days. You know,
know one is evaluated on this. We've deferred some of these tasks over to the computer,
and no one is viewed any less favorably because they can't line things up in the most
efficient way in memory.
Okay. So I'm going to stop trying to do some history and try to move into the modern
era. Okay. Anyone figure out what this is? It's the output of a make file. It's a build.
Right? It's a build. You've built some software. You've compiled it, you've linked it,
and you've put it together into the jar. It's a build.
All right. So what's this? It's a build. It's a build. Right? This is from the TV show
Extreme Maker Home Edition -- Extreme Makeover: Home Edition. You've got big
machines, you've got people, you've got somebody standing around talking to each other,
other people working, they've got safety equipment and stuff and like. They're making a
house.
Why is this a build? And why is this a build? I mean, why is it in computer
development -- in software development this is the build? But in construction, in the rest
of the world, this is the build. What are you doing here? Are you building the software?
Well, yeah, you're kind of building the software. A computer is taking the code that you
wrote, compiling it and putting it together. Well, what about the work of requirements,
what about the work of actually creating the codes, what about all of that other work?
Are you not building the software there?
Then why is this called the build? I mean, there's -- this is a computer doing all of the
work. And if this is what is viewed as the build, maybe there's something a little bit
funny with this picture. In the rest of the world, this is the build.
>>: The metaphor.
>> Susan Elliott Sim: Is it the meta --
>>: The metaphor is the code, the software [inaudible] the source code is the blueprints.
>> Susan Elliott Sim: The source code is the source. It's kind of like in The Matrix, oh,
Neo, he is one with the source. You know, he knows the source.
>>: And this is just some stunt that happens before [inaudible] before the building can be
occupied [inaudible].
>> Susan Elliott Sim: Yeah. And somewhere in this it breaks down. Right? I mean, the
metaphor, I think you're right in the metaphor. But the way in which we think about
developing software I think is -- these kinds of metaphors having made it into software
development kind of makes us see things in a funny way. Right? This is kind of like
the -- our environment as users or as customers, we're just used to things being a certain
way. And until we kind of say, hey, what's going on, this is -- then you can call out the
contradictions and the things that don't make sense.
And I think this metaphor and this analogy is similar to this. It's hard -- it's a little bit
hard to see, but this is a player piano, okay, and there's a roll up at the top that is the
music. And it can work as a normal piano as well, you can play a player piano by
pressing on the keys.
But a player piano, what makes it a player piano is that you put in a roll of music at the
top and someone is sitting in front of the piano and their job is to pedal, pedal as gently as
they can to make sure the whole thing works.
And this is a person playing the piano. This is a player piano. This is a piano player. So
this person is actually creatively, actively playing the piano. This is the active creation
over there.
What's going on over here? This is very similar to compilation. The script has been
written. The computer is just doing the job of turning that script from one representation
to another. This guy is like the build master. This is the build master. This is the build
machine, that's the build script, and he's pedalling for all he's worth just like your build
master.
The build master is responsible for making the build happen, and this is a bit of a black
art too, you know, just actually getting this to build, you know, you can't always build
every single piece of software on any machine.
I know from my experience downloading open source and getting it to build is -- you
need to have a lot of tricks up your sleeve. And I know many companies have a
dedicated build machine and they have a dedicated person looking after their build.
So I think using the metaphor of the build or use the label of build for your build process,
like your Ant script or your Makefile or anything like that is like a player piano. And
leaving out all of the creative work, other than just turning your code into zeros and ones,
you know, kind of aligns the work of the piano player. I mean, who made that scroll?
Who composed the music? Who turned the music into the scroll? And also this I think is
the creative work of computer programming. So this is the piano player versus the player
piano.
Okay. This is -- yes.
>>: [inaudible]
>> Susan Elliott Sim: Yes.
>>: The first [inaudible] pedals the player piano does get to control some aspects of the
program.
>> Susan Elliott Sim: Yes.
>>: They get to control speed.
>> Susan Elliott Sim: Yeah. Um...
>>: Presumably. It's not just.
[multiple people speaking at once]
>> Susan Elliott Sim: They -- yeah. I think they -- I think it's -- if they don't pedal hard
enough, then it goes slower. But once you pedal hard enough, then pedalling harder will
not get the music to play harder -- or faster.
>>: So can you view him as the end user who runs the program created by the piano
player, which is reported compiled.
[multiple people speaking at once]
>>: Scroll is the program and he's then the user. Like someone who created the scroll,
and then ->> Susan Elliott Sim: Yeah. I tried to metaphor. I tried to metaphor. But it's actually -if you keep -- if you push that metaphor, it becomes really unpleasant. So what are you
teaching the end user to do? Is the end user's entire job to pedal?
>>: They're benefiting from the program. They're listening to music.
>> Susan Elliott Sim: But it separates them from being a producer versus a consumer. I
mean, is this the music that they want? This is the music that they're stuck with. This is
the music that you thought you wanted them to hear.
>>: They theoretically pick the scroll to put in there.
>> Susan Elliott Sim: Theoretically. Theoretically.
>>: They pick other scrolls to -- for whatever music they want to hear.
>>: They just have to be playing with a movie, like [inaudible].
>> Susan Elliott Sim: Um...yep.
>>: I would personally view the gentleman on the top picture more as like an ops team in
the concept if, you know, I work a lot of Web apps, the passing teams where we have a
live operation, so it was kind of a layer between the end user, and even after code was
already built, you had to have an operations team to keep it maintained in making sure
that you had the applications, that was running properly on the server. So, you know, I
view the user as like the listener of music, in this case, maybe able to ask the player to
change the music [inaudible]. But in this case you'd have a layer of ops that would be
maintaining the code or maintaining the bits that have already been built. That's kind of
how I view it.
>> Susan Elliott Sim: Anyone else? I think -- I think none of the -- your comments are
well taken. And I think that you raise possible alternative interpretations of this
distinction. What I intuitively don't like about these metaphors -- and maybe this is what
I don't like about software development, is that the user is kind of like a receiver. There's
this big gap between the makers and the people who are receiving the problems of what is
being made.
And that's a lot of the -- what is going on with Web 2.0 stuff, a little bit. But that, you
know, the consumers are also producers. That's at where intellectual property law falls
down, that can I use this and make something else with it or can I create things, or you're
supposed to receive this stuff and you're not supposed to modify it.
And I think this conversation -- or this point ant what is the role of users is going to carry
on in the next few slides. So I encourage you to bring this up again in a couple -- yeah.
>>: Just one other distinction is in the lower picture it's not clear whether she's
composing music on the spot or whether she's playing some music that somebody else
composed, which is just playing it. Which I think is an interesting distinction.
>>: And there's a lot of [inaudible] in that distinction. I mean.
[multiple people speaking at once]
>> Susan Elliott Sim: So this is waterfall model. I think we all learned this at school.
And this is put out as a software process. And this is held up as a pretty good software
process, because this is where -- I mean, even though nobody uses it, this is the ideal
because it's clean, it's engineering. But you do all of the requirements, you get all of the
requirements, and you hand over to the specification stage. What do you hand over? A
document. And this document is complete. And you never have to talk to the users
again.
And then the specification stage, they take as input a document. And what do they
output? A document. And you hand it over to the design phase, and this probably -you're getting into a different team from requirements to design. And you hand over this
document and somebody else makes the design. And of course this is -- came from a
hardware development model that, you know, you make these things and then there's a
manufacturing step and it's done forever.
Design to implementation, here you have a little bit of switch. You hand over, you know,
code as well, which is different from the documents. So we tend to really like this step.
This is the part that makes software programming or computer programming really
special, otherwise we're just writing documents.
And then the testing and then the maintenance. We're just handing artifacts over to -- and
of course we all know this is fiction, right, that we hand over -- there's actually a lot of
interaction, there's a lot of feedback, there's a lot of to-ing and fro-ing. You can't come
up with a really good architecture until you've got a really good requirements and you
can't come up with -- you don't actually know what all the requirements are until you
know what some of the design is, so it's kind of like messy and all over the place. And so
it's just not as clean as this.
And so other process models have come up, like spiral and agile and things like that that
tries to capture what are the -- what the process should be.
Now, okay, what's this?
>>: [inaudible]
>> Susan Elliott Sim: That's right. Very good. Yes. This is a daily standup meeting for
an agile team. They're standing in front of their task board and most of you probably
know, but the agile daily standup is at the beginning of each day, you have a meeting
where you're standing up, so you try and keep it short, under 15 minutes, you know, what
did you do yesterday, what are you going to do today, is there anything blocking you, do
you need any help, just to touch base with everyone on the team.
Where's the process? Is this software process?
>>: Absolutely.
>> Susan Elliott Sim: Yeah. This is -- so where is this?
>>: [inaudible]
>> Susan Elliott Sim: Oh. Don't even worry about the structure. I mean, this is the
process by which software is made, right? I mean, there's the -- we did a study a couple
of years ago that we asked people if you use a process and they say no, we don't use a
process. And when people say we don't use a process, they mean we don't use a formal
documented process. But we have things that we normally do and we adapt and
improvise in the following ways.
But I think this is part of the assumptions or the bias or this is just how we use the
language, that if you don't follow something that's been written down or you don't use the
same thing every time, you're not following a process.
This is the process. This is not the process. Right? Is this the process? Or is this the
process?
>>: Well, so you're missing a slide. You're missing -- there are schematic views of the
agile process ->> Susan Elliott Sim: Yeah.
>>: [inaudible]
>> Susan Elliott Sim: Yep, yep, yep.
>>: [inaudible]
>> Susan Elliott Sim: Yep.
>>: And you can show people approximating the waterfall flowchart or you could show
people approximating the agile flowchart. Both of them have flowchart, both of them
have people deviating from that model that they implemented. So are you talking about
the delta between the model ->> Susan Elliott Sim: No.
>>: -- and the execution or the delta between the waterfall and the agile [inaudible]?
>> Susan Elliott Sim: I'm talking about what the textbooks say process is. And I'm
talking about that versus what is the process or what is the body of work, or the work that
you have to do to get software built.
>>: [inaudible] agile textbooks also. It's not fair to compare a representation of one
process with the execution of another.
>> Susan Elliott Sim: I agree. And I realize I'm missing a slide. So let's pretend I have a
representation of an agile. But even if you do have an agile representation -- and I can
quickly pull one up, I can pull one up because I actually have one.
>>: Is that picture the process or are those people the process? The answer is yes and
yes.
>> Susan Elliott Sim: Okay. This is the agile process. So let's say is this the agile
process. This is the process. This is the prescription of what you should be doing. But
this is the full-bodied enactment of that process. This is the work of developing the
software. But I think even -- my point is even in this representation, there are things that
are missing. Okay. We all agree that nobody actually does this. And even in this, there's
stuff that's missing.
>>: I think we all agree that nobody does this.
>> Susan Elliott Sim: Yeah. Actually I went to an agile conference in August, and
there's a new process called scrum but. We do scrum but we don't do this, we don't do
that. And everybody does scrum but. Nobody does scrum.
>>: So would it be more fair to just call it philosophy than a process, then, in those cases,
the ideology of scrum or the ideology of that?
>> Susan Elliott Sim: Okay. So this is one of the things that agile is up front about that
waterfall is not up front about. Agile, you know, what is the thing that holds all agile
together, is the agile manifesto, right? And really what agile -- all agile processes have in
common is that this belief or the set of values that, you know, some things are more
important than others.
>>: [inaudible] with the art of computer programming, if presumably the implementation
of software development [inaudible] more than just bits and machine instructions. Since
it's built by a human, there is a philosophy behind it. So what is [inaudible].
>> Susan Elliott Sim: What is Knuth's philosophy when it comes to software
development? I don't actually know. But I think there's an xkcd comic about that.
I don't remember reading him saying anything specific about this. But judging from his
actions, he would say it's fairly mathematical and it's about the input and creation of
codes and things like that. I mean, look at LawTech, for example. Right? He created
LawTech because he wanted to have something to typeset his documents. Because when
you went from version one to version two, his system had gone away. And this is what
he created for people to create documents. It looks like code, right? That's my guess.
And okay. So the point I'm trying to make is that this is -- even if this is the process, not
this, right, even if you say let's do agile, there's stuff that's missing from here. And we've
been doing field studies of agile. This is not one of the teams we studied, but we've been
studying agile teams and agile artifacts and the roles that agile artifacts play. And let's
see. Let me skip this one because we're running out of time a little bit.
Okay. So this is the diagram that we came up with for the -- for lack of a better word, the
process. How is it that people interact with each other, what are the roles that artifacts
play in the environment, how do things work together so that we can develop software.
So each of these, you know, actors are participants in an agile software project. And they
interact -- they have their input into the process through a user story. Either you're
feeding in user stories or you're taking a user story and you're implementing it.
You also have personal artifacts. This is something that we found common to all the sites
that we studied, that everyone hides their personal artifacts. Oh, I just wrote these notes
for myself. Agile says, you know, as little documentation as -- no unnecessary
documentation. And that official documentation is lightweight, right? So there's
nothing -- so people hide their artifacts and say, oh, this is just for me. And so that's why
we have these personal artifacts. And it's like the more you hang around a team, the more
these things -- they can't -- as a researcher they tried to hide them from you.
And so they have their own personal artifacts. And what is being built? It's not just -code is being built, but test cases are being built, functionality is being built. So the
software in use is being built. That's the deployed running integrated software.
And then there's this whole thing has a piece of conversation about it. Because very little
is written down, how do you get requirements? You talk to somebody. How do you do
validation? You talk to somebody. How do you figure the dependencies? You talk to
somebody. So there's this entire conversation that's going on.
And this is kind of like these are individual private spaces and this is the public space in a
project, and these people come from their private spaces or private representations of
work and participate in this public representation of work.
And they do this through user stories and they're able to do this because they are backed
up by their roles, backed up by their personal artifacts, personal credibility, background
and experience and things like that.
So what we found in this study made us wonder and what is the process of building
software. And it reminded me of the Brooks' quotation from the last slide that what is
building software? And Brooks said I believe -- this is Fred Brooks from No Silver
Bullet, I believe the hard part of building software to be the specification design and
testing of this conceptual construct, not the labor of representing it and testing the fidelity
of the representation.
And so the views of software process that we see described in, you know, in this model
or even in this model places source code at the center but leaves everything else out of it.
Like source code is it. This is what we are making. And so when you interrupt
somebody to ask a question, they feel like you're interrupting their work. Or that if they
have to go to a meeting to figure out what the requirements are, they feel like this is not
really my job, you're preventing me from coding, which is really what I want to do.
I see wrinkled faces, so that means it's time to stop and have people ask questions. Yeah.
>>: So I strongly agree with your final conclusion that there's much more to software
development than just the coding, but I think I disagree semantically with what you're
defining as hardware, software, algorithms and programming. So I think I would define,
for example, software -- well, the hardware is the physical pieces, where the software is
more the changes in the algorithm. And there might be an input which is -- which doesn't
affect the algorithm that affects the performance of the thing.
So, for example, in the difference engine, I would say that there is programming, but all
the programming was of the hardware and there -- to my knowledge, there is no change
in the algorithm you could do on the fly without changing hardware. But there are inputs
that people can do to -- and then I think for the -- like the ENIAC, for the running the
wires, I would distinguish -- there's someone who comes up with what wires should go
where to do the algorithm that we wanted to compute. And then there's somebody who
actually plugs in the wires, and I'm not sure if they were the same person ->> Susan Elliott Sim: They're the same person.
>>: Okay. And so then I would say the person coming up with the algorithm is the
programmer, and that, again, is my definition, I'm not sure how well that meshes with
yours or others', but the programmer is the person who comes up with the algorithm, and
then there's someone else who might be the same person who puts it into action in the
wires and wiring things up, it could be the person -- my nine-year-old last night wrote a
Web browser by reading from a book and typing exactly what it said. Now, I would not
call him a programer yet, but he created a program.
But I think the person who designed the program in the book was the programmer. And
so my son just sort of typed in the things. And so I'm defining programer as a subset of
what's needed, the person who can sort of take what's needed, the requirements, and turn
it into code. That's what Knuth writes about and certainly is an important part of the
process. But I agree that there's much more to the process, there's gathering the
requirements and the architecture and [inaudible].
>> Susan Elliott Sim: Okay. Does anyone else want to jump in?
>>: [inaudible]
>> Susan Elliott Sim: I know you all want to jump in. I can tell.
>>: [inaudible]
>> Susan Elliott Sim: Okay.
>>: So the thing that I think is missing from that diagram is sort of the shared
understanding of the three people in that diagram of what they're building, which is -- I
mean, the artifacts is one manifestation of what they think they're building, but they
themselves in their heads have some sort of shared understanding when they go to the
scum meeting and the daily standup and they say like, oh, I'm working on this, the other
couple people in the room also have an idea of what -- why are you working on this and
how is it contributing to the overall effort and what is the effort and what is the goal.
That's kind of missing, I think.
>>: That's part of the [inaudible] that you have [inaudible].
>>: I would argue that there is no such thing as shared understanding.
>> Susan Elliott Sim: Um-hmm.
>>: We all have mental models. We don't have a shared one. But we synchronize them
through the conversation. So I think what's missing is your xkcd people [inaudible] those
hats are full of stuff. And they're constantly being synched through conversations and
through [inaudible] and through creating an artifact [inaudible].
>>: I think what's credibly missing from this and the picture of agile or the picture of
waterfall is that they're humans that -- for example, if you go back to the picture of agile,
there's a skilled cardboard box, somebody opens the box and takes that piece of software
out and procreates that software from their own needs.
>> Susan Elliott Sim: I deliberately left that out.
>>: Oh, that feels bad.
>> Susan Elliott Sim: I -- I do -- I ->>: That's like the people ignoring [inaudible] ->> Susan Elliott Sim: No, I -- I ->>: [inaudible] that has to be built.
>> Susan Elliott Sim: I deliberately left that out because that is a huge, complicated -- it's
as complex as what we've talked about in that one hour today. I could spend another
hour on it. And when I bring that up, it actually confuses the conversation about this.
But I'm happy to give another one-hour talk.
>>: I was just going to say, I like the comment you made about [inaudible] the Web
browser code [inaudible] the gentleman that said that, I like the comment he made about
that, and it reminded me also about the projects they're working on BOCU. I don't know
if you're aware of BOCU, but for children programming the Xbox, there's so many
different ways things are changing now into a code.
And I guess, for me, the way that I view it, is more and more now a philosophy or
something that's a bit higher level than just the actual process of writing the code. In fact,
the way I look at it is every step of my life is kind of like -- if I'm a programmer or if I'm
a developer, it will affect every step of what I do. And I think it doesn't matter whether
I'm writing code or whether I'm doing something else. There are only extensions of what
the core, you know, motivation I have to get the job done. I think writing code is only
just another way of doing it. Just like you can see different languages, you could say the
same thing. I mean, that is kind of ->> Susan Elliott Sim: Yeah. No, I agree with that. And, I mean, I started off this talk by
saying we have intuitive ideas about what is real programming, what's not real
programming, whether someone is technical or not technical. And I haven't made up my
mind on a lot of these issues. And the thing of an STS is it's good for raising questions
but it doesn't give you any answers. Right? So I've raised a lot of questions about what
counts as programming, what constitutes programming. And I'm pointing to the parts
that are missing or that might be missing or here are assumptions or here's how we use
terminology in a certain way.
And that was my goal. I'm not quite sure what I'm going to do with this, but that's the
goal, that, you know, I've raised some interesting questions. And I can tell by the looks
on your faces that some gears are turning in your head.
And I think I'm just going to finish off with one last xkcd comic, which is exactly your
point back there, that, you know, who is being programmed? Is it the computer that's
being programmed or is it us as programmers who are being programmed? And as you're
saying, when I'm walking down the street, I can see myself as a programmer. And this is
what I love about xkcd, is that, you know, what is it -- me as a programmer.
And there's an entire ethos about this. I can look at the world. And sometimes I laugh
because I've been reading all this STS stuff and I can -- the joke in xkcd is that, you
know, you kind of step outside yourself and you're analytical about yourself. But then
I'm reading this STS stuff and this part that's watching the analytical part and going, oh,
yes, I just saw you behave as a programmer. And it is like impossible.
The STS reading that I've been doing, it just gets into everything and I see things going
on in the news or I see things going on, you know, in politics or somebody's comment,
and I say, oh, I know why they said that, it's because this, that, or the other thing.
But, yeah, this is the compiler speaking up to the human saying, you know, double-check
your pointers. So who's being programmed? And this is, you know, what Gina talks
about, so who's being programmed, what are we programming people to do? We've
created this software and we say, oh, well, social networking, we've got Facebook, and
saying that this is the box that social interactions happen in.
Is this all of it? Is this the sum total? I mean, I'm not sure, I'm not comfortable saying
that Facebook is it. And I'm not comfortable with ever saying that, you know, all of
human interrelations can be captured by software. And yet software tries. Or at least for
the purposes of banking or for the purposes of walking up to an ATM, I'm being trained,
this is what I'm allowed to do in front of an ATM.
Anyways, there ends my talk.
>> Rob DeLine: All right. Let's thank Sue.
[applause]