 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
At Microsoft I am an architect in the Patterns and Practices Group. I had consulted to Microsoft
on a patterns project and I was impressed that they were investing money in organizing and harvesting patterns.
They said "Why don't you come and join us" and I said "Well that will be different." It was just at the right
time to try something different. Now it's kind of funny that they give me a title of Architect because I spent
so many years trying to explain why we don't need them and now I are one. What I really mean is we don't want to excuse all developers from being architects. Architecture is
so important that everybody has to have it in mind all the time, and to think that we can take the responsibility
for good architecture and concentrate it in one individual is the real mistake. The other thing is the practice
of architecture. A lot of times what turns out to be really important couldn't be foreseen ahead of time, and
so being able to realize that you are facing an architectural issue when it comes up in development, and be
prepared to respond to an architectural problem, is what I think is really at the heart of the patterns movement.
When we say we would like to hire somebody with experience, what do we really think they have that they get when
they have got experience. That [quality] is what we are trying to get at with patterns -- the stuff that is
beyond theory but just what works.
Certainly the movement we started, it is over 10 years ago now, it has been focused on finding a way
to take experience and write it down, and organize it, and make it available so that you could get experience
by reading a book; although nothing beats real experience. To that end, I think we might have gotten a little
too focused on the form and not enough on the real experience. But I always felt that if you put enough stuff
out there, if you get enough patterns written down, that the people who really need them will figure out which
are the good ones and which aren't. The nice thing about a pattern is you take something that everybody knows how to do, and you give it a name.
And a lot of people look at it and say "I knew how to do that only I never called it that." But you can't help it,
[and] pretty soon you are calling it the same thing, and then you can have arguments about "Do you really want that
or do you not want that?" A perfect example is a singleton, that is a very simple idea, but a lot of people learned
singleton, [a] lot of people made way for many singletons. So now it is easy to say "Well I don't think much of
singletons" while you are making a very clear statement, whereas there was no way to say that really so concisely
before. It has a vocabulary absolutely, but that is not the end of what they can do. Of course, the term "pattern language" was coined by Christopher Alexander and quite a number of programmers
had seen his work published and said "Well "Gee! We need that for programming," or "This is the way to think about
programming" because they just recognized how they thought about programming themselves in it. But the breakthrough
for us was to get a group of people together that had that same feeling, and we looked at each other and said "Why
aren't we writing patterns, if we believe this is so good? Why aren't we doing it?" We tried to do a little bit,
personally I tried to do it a little bit and stumbled; they are actually pretty hard to write. It's like writing your
first subroutine before you really understand subroutines. It's the same with classes, trying to understand what is
and what isn't a good class; it's kind of an issue of modularity. You see the same thing with patterns, but we
realize that the way to get more people writing is to have some place for that writing to go, and that is when we
founded a conference: Pattern Languages of Programming conference and kind of a collaborative thing we did. It
was actually Dick Gabriel's suggestion that instead of having people present the patterns that we would get together
and the audience would read the patterns in the presence of the author and the author would not do anything except
watch people stumble, you know trying to read their patterns. And I mean for creating a new literature that is a
great way to do it because every author is humbled when they just watch people struggling to understand their own
words. Workshopping this is called, and it is borrowed from poetrym I guess all writing.
Ted: I know a lot of fiction writers do a lot of workshopping. It is a beautiful invention of that community and we are glad to have stolen it. Ted: Stolen it in the good sense. Oh absolutely. When we started, we were not sure what it was. We just thought, I guess I thought if I got 50 patterns
I would have all of computer programming and then I realized that it was more like five thousand, or I don't even
know how many. And so just getting people to write them and to pay attention to their own experience. And there
are a few rules of what makes a pattern as opposed to a principal; user friendly design is a good principal, I
think all computers should be easy and friendly, but it doesn't tell you what to do so it is not a good pattern.
A pattern could be user friendly, but user friendly isn't a pattern. You have to focus on the stuff. In the
same way I guess object-oriented programming had a real focus on the stuff, so it kind of made sense to be kind
of tied with object-oriented programming. But what other things can it do? If you can get knowledge and experience
out of your brain and on to some form where you can look at it and discuss it in a community, a community decision
making. I think computers are one of those things, in that uniformity in the way computers work is very valuable.
You can go from computer to computer and know something about it as long as they are working well. Uniformity in
computers working poorly is not such a good thing. The real benefit I think long term is going to be agreement
among the community of what is good and what isn't, and I think that as we move from discipline to discipline there
will be a lot of "How much are the patterns from the old discipline to the new discipline [do] we want a bring
along" and "How much is new, and if it is new what do we expect?" And so I think manipulating patterns will help
mature different programming practices very quickly.
Certainly I think we do not need that big a jump for experience to fail us. I think that one big jump is from developing a program that runs on a computer to developing a program
that runs on a network, and that has been a big switch for a lot of people, and now we are facing in the future
developing computers that run over the whole world. Programs are not just on your local network or in a small
community, there is the stuff that has to work together everywhere. Anyway that is going to happen when people
really understand the meaning of the information that is flowing, and understand it in every nuance, and some
things like vocabulary become very important.
I am certainly disappointed anytime anyone doesn't get value out of patterns, but I do know that it
happens and sometimes it is because you are not looking at the right pattern, or you do not have the right
attitude about what you have to bring to it. But there are plenty of examples. I was working with one company
and they told me that when they set out to make the new product, they just bought the one book available at that
time and they said "We are going to design the product based on this book." And the product had a very healthy
run,, took over their marketshare and so forth, and they attributed it to the flexibility. It was the first
pattern book, the so called Gang-of-4 book, [which] was really about how to write a flexible C++ program, and
that is what they needed and they got it. I got involved with them seven or eight years later and they said "Well gee! Our product has kind of run
its course, we want to take it up to the next level. Where do we get more patterns?". So the limitation of a
single volume becomes pretty obvious then. There is just an awful lot out there. Computers are amazingly
versatile in what they can do and so writing down all those patterns [is important]. But I think there is
also a degree to which pattern authors are writing patterns for other pattern authors. It's like poets; in
poetry it is important. I know, that poets write for other poets. And I don't really understand much of their
poetry unless it's put to a good rock-n-roll tune or something. I think that makes sense because the body of
work is not complete. I try to encourage people to write patterns and learn patterns by learning to write
patterns, and then we will appreciate patterns more and there will come a day where the body of work is more
complete; and that will just lead to better training whether it is self-paced or instructor or whatever, or
built into the tools we use. I see the challenge now, is we have enough patterns, that now is a good time to
kind of bring order to the patterns we have, try to look at how they fit together, and basically rebuild a
new community of users more than a community of pattern writers to filter through the patterns and find the
good ones. My first cut at it was this web site called WikiWikiWeb and we really didn't know much about patterns
when I made that, so I didn't build much in the way of rules into it about what you could or couldn't do. It
turns out that has been more interesting just because of the fact that it worked at all, [rather] than the
patterns it collected. But I think that a logical next step is to understand how a community really wants to
interact with a body of patterns and that's going to take some leadership. I feel like I have been away from
patterns for a few years because I sort of stopped writing them myself or I became a user. I had enough people
who were writing and I just read them and focused on other things, but I was glad to work with Microsoft on this
book. This is the first one I wrote. I wrote the foreword for it and I sort of believed my own foreword that
talked about creating a community, and that patterns would be a good way for people to talk to a big company;
in terms of patterns. And now I have to make good on that. So they made me an architect and said "How do we
do that?" Of course, Kent and I go way back and helped found this pattern movement and a lot of stuff with
object-oriented programming. Before that and I had met Ron in his position before Chrysler and was there in
spirit if not in person. A lot of the ideas there were floating around in the community that kind of organized
the patterns. We had a group, [that] still exists, called the Hillside Group, and we would meet regularly on that.
Kent and I were no longer working for the same company, but honing the ideas. At heart it was the set of values
that have to do with really developers, what a developer needs to be effective and something as simple as feedback
on what you are doing; feedback at every level. You do something you should see what happens so that you can adjust.
Some people call that a learning environment. That is so important. There is courage or confidence and things,
because you need courage to go off in some other directions that you might have to do. Maybe that's where
architects come from, they are just foolish enough to think that they, you know, are full of hardy confidence.
But we wanted to develop something where there was confidence grounded in seeing a program work everyday. That's right, I have been in the research labs for 10 years and the last few of those I was using Smalltalk,
which had been spun out of Xerox Parc. And I thought well this thing's totally amazing! And I thought if I am so
good I shouldn't be teaching others, I should go make programs. That was kind of an education in its own right as
I became a commercial developer. I learned immediately why none of those people in the product groups cared about
my research. It's not that they didn't understand it or didn't find it interesting, it is just that it was not the
problem they had that day, this is the problem they had that hour. And in research you can grab hold of a really
interesting problem and work it for a few months, a few years maybe. In development you get to hold on to a
problem for a few minutes, you know you got to put that problem behind you and get on to the next one. I
became very interested in how it is you do that and still have intellectual integrity. You really are using
your mind and you're not just guessing. The idea of getting the code to help you do your work: testing,
programming tests, watch over you came out of that, and working closely with your peers so that your buddies
become your safety net. At the same time when you are at the end of the week, you don't have to write up a tutorial
on how your code works, because they were there when you did it. This is the idea that is a very social thing. So
out of naiveté as a researcher; I was not a developer, but I knew what I wanted. We just ran a project for
three-and-a-half years and when a problem would come up, we would say "What's the simplest way to solve this
problem?" That remains true to our vision of basically objects being powerful, that our code is something we
want to live with. No, cult is too strong a word, but I know exactly what you are talking about. I think .NET got it pretty much covered. The one thing that was beautiful about Smalltalk was that it
was 98% about creating abstraction, and abstraction was something that is very important; that's how you can day
in and day out work on the next thing while keeping everything you've done working, because you build up these
abstractions in your head; Smalltalk was all about that. The way it made that work was it lived in its own little
world. When you are developing a Smalltalk program I can't imagine a better way to make a program than in Smalltalk,
but what we find now is that you are not just making a program, you are making a piece of a system and the system
is enormous. And so the complexity that enters our lives is not so much because of the language. I could quibble
about how many punctuation characters you need, but Smalltalk got a few surplus ones too. But it's really how many
things you have to keep in your head, how many APIs you have to know, how many systems you have to talk to, how
many things on the far side of the wire could misbehave, and you have to adapt to that kind of thing. I think
it's a social thing. You have to talk the same language everybody else is talking. I have heard this stereotype many times, but I don't actually think it's true. I do know that a lot of
times if the programmer gets good, while he is getting good, he learns that most people do not understand what he
does. So that's really separating for programmers. Programmers are kind of driven apart by that realization that
they are dealing with things that most people do not understand, and after a while they give up trying to
communicate. They say "Just stop bothering me, let me think." The magic of just programming together, just walking
up to a screen with nothing but the editor and [to] start typing, is that it is not as boring as it sounds and
more importantly, as you are programming together you have all this short term memory about what you're doing.
You point or have a conversation, so you know, right now I think what we need to do is just what we did over
here and we will point to the spot on the screen, where we did it. Maybe the window is closed, there is a
probably a blank spot on the screen; but because we have that shared experience all of a sudden we have lots
to talk about and all of a sudden programmers become pretty good conversationalists. There's nothing isolating
about it. It's actually a very welcoming environment to have that experience together, and the other thing is
it turns out that the things that we do need to talk about are pretty hard to pronounce. If I wanted to say,
"What we did over here", I would need a noun with probably 30 syllables and it's just too hard to say. So just
saying "Here, and Here', "Like That", or "Do that again" is so much more efficient than even trying to draw a
diagram on a white board and talk about the situation. So that's why we would like to get people into the here
and now. If you think about it, that's pretty closely related to patterns. In patterns what we're doing [is]
the same, let's get people who have had similar experience, get them in a room and see if [they] can agree what
that experience was, and give it a name. And when we ask people to program together, we are saying "Well let's
just go have some experience together." And the kind of things I learn is a few tricks with the mouse. "Did
you know if you double click here that you do not have to go select that", and I'll say "So where did you
learn that?" Then I say "Well it was in chapter 30 in the manual." I say, "Whatever led you to read that?"
"You know it fell open one day." It's not like anybody has time to read the manual but you know how do we
learn how things work other than see other people do it and say "How did you do that?" Ted: The body of myths, legend, and more that is subscribed to ... That kind of activity in the microcosm of a group will take that group, and that group will just develop a
sense of shared experience that is [as] empowering as we ever hoped people reading books would get, especially
because it is right about the here and now. But that's really a laboratory for discovering new patterns.
And at the end of the day you say "What really helped us today" and everybody will know what helped us and you
say "what is that called?" Oh, that's the thing up here. Oh, what should we call that? You make a name for it
and pretty soon it becomes the vocabulary, and the next thing you know you would want to know how to write in a
pattern form and get your forces and your solutions and all that, properly punctuated; and you become a pattern
geek. It is closely related. Pattern mining sort of makes the assumption that the wisdom is out there in the
code or in the development community and an independent researcher is going to go out and find it by talking to
the people. "How did you do this" and "What was important there" and a lot of times you have those conversations
and it is not what you would think. That takes a lot of skill to learn how to do that well, you have to be
technical and you have to be patient, and you have to know how to ask the right question. I think the people in
the social sciences have figured out how to do that long before programmers, who are more about engineering,
about making stuff than asking and recording. But extreme programming says really our customer is what's most
important and it isn't really a goal to find patterns other than the patterns that we need to do our job. We
just say well it's meeting the customers need and we try not to work beyond what the customer actually needs.
So if we don't need a pattern we might chat, I mean if we are programming together, I say "When I program this,
this reminds me of something I did back in graduate school" and we could start telling graduate school stories.
Then I would say, "Well! Let's stop. What we are doing for the customer has nothing to do with graduate school
even though next week it might, but today we are doing this. Let's not think about the cool stuff that we could
be doing and just solve the problem." Architecture design is so important we have to do it all the time. There is a little resistance to
doing it before we're sure what to design, especially producing what is called the big design up front where
you write a document and then someone tries to hold you to that design; "We don't care if you made a mistake, we
want you do what you said." That is foolishness, but there is no resistance to thinking. There is resistance
to "if I have kind of an idea how this is going to go and you have kind of an idea how this is going to go,
instead of having the argument today let us just to do the part we need to do today, that [part] we agree on
and we will wait tomorrow to see what we have to do [then]. If we need to have an argument tomorrow, it will
be about tomorrow's stuff. Because we're creative people there is a real tendency to want to imagine what the
system could be and of course we can only do it based on the patterns we have in our own head. And so we'll
imagine a system, and you will imagine a system that will be a little different, and we will end up arguing about
stuff that just does not matter and so all of a sudden we get mad at each other and decide to be alone again.
So, being in the here and now really helps us communicate because we just agree about what's on the table in a
sense. It's also a great way to work with customers because sometimes the customers change their mind, or
sometimes the customer is not articulate of what they really want. But when they see what you did today,
then they say "Now I understand what I want you to work on tomorrow" and you just say "Great!" None of this,
"You didn't say that so I am not going to do it." You just say "Great! If you understand more I want to hear it"
and that's the advantage of staying in the here and now. If you're working alone late at night, working on an art
program, I encourage people to see how far they can go, see what you can imagine, be wild and crazy. It's just
that it's not a group activity and it is not serving a customer. That's using your own computer in your own way
to make something beautiful. Sure, go for it! It's just that when you need to produce code on a regular basis, I haven't seen anything better than just
working in a team, getting the people together, staying clear on what you are doing and show something tangible
everyday. Yes to degrees. I mean all these things are ideas that you have to sort of fit to your situation. With
the advent of modern programming languages, particularly the radical modularity that you get with objects, it's
surprising how independent parts of the program can be made and one thing we would like to emphasize is that the
cost of change. We were taught that a decision made correctly early is better than a decision corrected late,
and that induced us all to try to figure out every question, the right answer, before we even start. It turns
out with objects you can figure out half of the questions, write those objects and then say "Well now that we
are here what about these other questions" and it turns out that you don't reverse much work. In fact you
reverse probably less than you would have if you tried to guess it all ahead of time. This premise that there
is a curve of increasing cost of change is actually surprisingly flat. It certainly does not have to be the case. The wonderful thing about the radical modularity of objects is
you can ask yourself a bunch of questions and answer half of them, make those objects without even considering the
other half and when you answer the second half of the questions you go back to the objects you made and there is not
that much to change. It doesn't take long to change that. Now, when you start deploying software it turns out
that it is the actual deployment that creates additional cost and we are discovering with networking and so forth,
ways to deploy software that is just simply less costly. I think the challenge here at Microsoft is they deploy
so broadly that they are going to have a cost to change curve that has some slope to it, and they learn to deal
with that. But I will say that as I learned about Microsoft, I remember this great book called Microsoft
Secrets that talked about how Microsoft developed software. At the time it came out we found some encouragement
because they described an evolutionary process and that wasn't what the academic take on software was at that
time, and I think the academics were horrified. But we said "Oh no. Now we understand how they can get the
stuff out the door." One of the things I look forward to is just being close to that large of a deployment
situation and discovering, as the company does, as it continually reinvents itself, how to deal with the software
in the coming generations. I am happy to be in the Patterns And Practices group because that gives me some
grounding working with enterprise customers where I do know that I have some way to help as I'm learning about
Microsoft. That is an interesting question because there are so many possible answers and if I think for a moment
there is probably a lot that he's going to learn automatically. One of the hardest things to pick up I think, is
that the way to grab hold of the really good ideas. There are a lot of ideas, but really good ideas are hard to
snatch because they look so humble when you first see them. You expect the solution to be beautifully complex and
a good solution is pretty plain until you see how that plainness plays in a complicated way to make something
better than you could get in your head all at once. Exactly, and it takes a sense to, [or] a way to develop that [such that] every time you do see something
that works out that is kind of surprising that it worked out, you must take the time to find out what the history
of that idea is. If you could talk to the person who came up with it or even when it happens to yourself, go back
and think, "What did that look like when that idea first surfaced", because I think there are a lot of really good
ideas but we just walk right on by because they were not what we were expecting; they just looked too simple. Ted: Thank you for your time Ward and good luck with Microsoft and the Patterns and Practices group and take
care. Thank you. |
