I am sitting here with Kent Beck at OOPSLA and we are going to talk a little bit about his new book "Implementation Patterns". So Kent can you tell us about the book?
The premise of the book is that it's important for programmers to communicate with other people with their code, so it's not enough to just instruct a machine to do something that you need also to think about what will people read in what I write here, so it's programming more like a writer would write, than just thinking of a set of instructions for a machine. The primary motivation for that is that three, four, five times as much investment goes in the changing programs as goes into writing them in the first place, so it makes sense to take care while you're writing because people are going to be reading and understanding it for many more hours than you spend writing originally.
So why are they described as patterns?
The thing I like about the pattern form is that it gives you a way to talk about the motivation for what you are doing. So there is a lot of Java style books, and good ones, out there people with lots of experience, people who've thought carefully about how to program, but when I read them what I hear is a set of commandments, "Name variables like this, arrange your code like that, etc" and all those are good things to do in certain circumstances, but what doesn't ever come true for me is why? What's the context, what stage needs to be set before that's the right thing to do, and what are the consequences? If I do that what other thing should I do so that the whole system works well together? So there are different personal styles.
People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn't necessarily working well. So by writing a pattern kind of format I get a chance to say: "How do you name fields?" Well, let's see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don't work well for a variety of reasons, but why? Really long names don't work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don't really get it in the same sense that I care about, and more importantly when that is not the right rule, they don't get any sense of what thinking was behind that rule, so they don't know when to break it.
So how was it to dig into yourself and find those rules, find those values and describe them?
It takes a lot of work. I had the fortunate experience of having written a similar book for Smalltalk that was my first book 10 years ago and that experience was very painful because I felt like I was a good Smalltalker and I just programmed smoothly and flowingly and I really stopped myself and wouldn't type a character if I didn't know what pattern I was following and doing, and that was just awful because I was used to this very flowing experience and all of sudden I was like the ... thinking about his feet. So I write 5 characters and then I go write a pattern and then I write one more character and then I go write another pattern. It took me 2 or 3 weeks, that was just really painful, but then what I discovered then was my programming flowed much more smoothly because I didn't have this constant internal debate. "Yes I was going to name the variable this", but a part of me was still thinking "Is that really the right thing to do?" because I carefully thought about those issues.
In writing "Implementation Patterns", I didn't go through that same kind of dogmatic "stop myself and then write" , because I have thought about the patterns, the constraints in a Smalltalk are very different then the constraints in Java. So many of the patterns are very different between the 2 languages, some of them are very similar, some of them are very different, but I have gone through that process, that introspection, so I didn't have that kind of thinking about my feet experience. But it's still very challenging, especially with deeply held beliefs and the more emotional I am about my opinion on something, the less good reason I have for doing it that way. So for instance - braces... To really dig into that would be really hard and so for implementation patterns I didn't get into code formatting which is something I did get into and in the Smalltalk Best Practice patterns just because I couldn't come up with the reasons for doing one over another, even though I think code formatting has a big impact on readability.
Would you like to have a compiler that requires a certain code format, like Python (which is whitespace sensitive), but harder? People hate reading "yet another code style" document when they come to a new place. Everybody would hate the compiler for a few weeks, but then accept it and write production code. Would that be a good idea?
It makes sense that if whitespace matters to people, why doesn't it matter for the compiler? I realize there is technical reasons why it doesn't matter the compiler, but I kind of wander if that is a really good thing, so I think Python is certainly a reasonable direction to go to to have whitespace mean something. There was an old language called Uclid, that was the same kind of way that I learned way back at the dawn of my programming and it makes sense, but I go back and forth. Part of me thinks as a craftsman that I want to format my code in a way that expresses myself very quickly and part of me, if the automatic formatter's good enough, just to hit Control-Shift-F and it'll be fixed.
Are the patterns described as a pattern language as well, or if not how come?
In "Implementation patterns", the sense of pattern language isn't as strong as it was with the Smalltalk patterns. There is not an explicit linkage that says: "When you've made a variable like this, then you need to go do this." I think a lot of those connections are obvious and don't need to be spelled out, so I didn't include the explicit connections between pattern, so in a technical sense I suppose that this isn't the pattern language, syntactically isn't, certainly semantically it is, the patterns are intended to go together and in fact when the context changes a bunch of the patterns need to change at the same time. So one of the revealing but difficult experienced in writing the book is having a conversation with Eric Gamma about an early draft, and he said: "Yes, but I don't use these patterns, this whole set of things, because I am writing frameworks and frameworks are very different and I we had to go back and forth on this before I realized yes, the constraints on framework development are very different.
So there is an explicit chapter in here that says: my assumption through most of the book is writing an application even that it's a large application if you need to refactor something, you can just refactor it and change all the colors, you can change all the declarations at the stroke of a button. But if that is not true, if downstream changes are more expensive then you are willing to spend some complexity now, in order to gain flexibility in the future, because you can't change all the users of the framework in the same way you came with an application, so the chapter spells out, here is all the ways that the patterns change that I can think of, for framework development as opposed to just application development.
So what are the central patterns of this book?
The canonical one is Compose Method which says that the most effective way you communicate the logic of what you are doing is to compose methods out of other methods. Don't have big long blocks of code, that you have methods that say what they say at a similar level of abstraction. So I wouldn't have a big shift operator and in the next line have an object creation for something that goes off and does something big. It doesn't communicate well to mix level of abstraction like that and if you compose methods out of other methods in that style because you are working in an object oriented you automatically language, you automatically get a whole bunch of flexibility for free.
You have to work at composing the methods which is why they‘re "for free" in quotes, but once you've done it people can read an understand what you have done, people can extend what you've done more easily, people can modify what you've done more easily and it's easier to eliminate duplication, because of these little bits of functionality where the way you compute X is these 2 or 3 operators. If that's in a method somewhere then it's easy to change, the assumptions in one place is easy to change. If you just say, that is just going to be a one line method what's the point of making it into a method of its own then you get this proliferation of the design information that assumption that "here's how you compute..." whatever it is goes a bunch of places in your code and if you want to change it you're stuck. So for me the central pattern in the book is Compose Method. There is 76 other ones, they are obviously really important or I wouldn't have put them in, but that is the one that's kind of the heart of it.
What's the style of the patterns in this book? How did you describe them? Can you elaborate on that?
I've grown increasingly disenchanted with the rigid definitions of what a pattern should look like. I know that Alexander and his original stuff had a very specific: "this section, this section and then the three dots, and that section" and so on. And I don't find that kind of formatting helpful. If I have a pattern and I don't have anything to say in a section, I'd rather not make something up just to follow the form, so these patterns are in a freer form. The phrase "ad-hoc" literally means build for a particular purpose. So I tried an ad-hoc style here, where each pattern is presented in the form that I think works best. So sometimes if there is a pattern and then 3 variants of it I will have 3 separate patterns, explicitly named and so on, sometimes if the variants are small enough I will just leave them in the original pattern.
What I try to be careful about is that the intent of the pattern form was followed in each of the patterns. I say "here is the context in which this makes sense, here are the alternatives, here are the forces impinging on this decision and clearly here is what to do about it in a very specific sense". So the composed methods are a good example. By the time you get to the answer, the answer is fairly clear, it says compose methods out of other methods and have the statements in the method be at similar level of abstraction, that is the commandment part of the patterns and each pattern here has that kind of clear expression of the: "Ok, here is what you do." To me that is one of the beauties of patterns, as opposed to just talking about abstract principles - the pattern tells you to do something. If I just said: "Communicate clearly", there is a lot of people that do a lot of things with the intent of communicating clearly, some more successful than others. With patterns there is this sense of accountability, "Ok, you are telling me to communicate Kent, but how am I supposed to do that". Well here is Compose Method, this is a way you can communicate. Here is Guard Clause, here is a way that you can communicate.
XP is a rather practice oriented methodology. Can you describe the relationship between implementation patterns and XP and how they work together?
I think the easy part of XP is practice related, but there is 3 legs on the stool: practices, values and principles and I think people who are successful applying XP are paying attention to all 3. This gets back a little bit to some of my disenchantment with the direction of agile development in general, people are now asking the question: "How am I going to do agile development?" and agile development isn't a thing you do, it's an attitude, it's a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.
That is agility. Yes, there is a lot of practices that come out of that but to me that is where it starts, it's this attitude. If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and it's a disaster because you're acting out of harmony with what you really believe when you do that.
So you're more or less saying that you have to be agile to do agile, but you can't do agile if you are not agile?
That is my opinion, yes. The times when I have been closed off, when I haven't really listen to what is going on in the real world, when I built a fantasy picture in my head of how things are, I haven't been agile. And I have all the same skills, I program the same, I know the patterns and I have the tools, but without connection to what other people are saying about what's going on in the world, then you can't really be agile.
So in in most situations when people learn agile, they just learn how to do it, but they don't really change their belief system?
I was going to say that I think that that's the easy way to teach agile development, but I don't think it's actually easy at all. I think it's very hard to pretend that all you have to do is learn TDD and learn continuous integration and learn to use JUnit and learn to answer the 3 questions at the daily stand-up and then you're agile, because it's not connected with reality. It's easy in the sense you don't have to think very hard to come up with a set of Powerpoint slides that let you explain agile development that way, but I think it's really hard to deliver that with a straight face, because pretty soon you are getting a lot feedback that doesn't work that way.
I think that all 3 legs of the stool have to be there or it falls over. I think that you do need to understand how to program well in order to program well, and that is where a book like "Implementation Patterns" comes in. Here is a set of skills you can really master, and it doesn't have to be these patterns, but I think understanding your own programming style at this level is very important to being agile because it matters whether you technically do a good job or not, but that's enough. I think you also have to understand and hold the value system that is consistent with agility: communication, simplicity, feedback, origin, respect is the one from XP, I think that value system is very much in harmony with being agile and then to have a set of principles so when none on the practices really fit you quickly back up and say: "None of the practices fit but in principle the XP way to solve this problem would be "blah", so let's go do that". Once you have all 3 legs of the stool then you have the chance to really be agile.
But don't you have to start by what others are doing, not really understanding it? Alistair Cockburn talks about Shu-Ha-Ri levels. You start at the Shu level and work up. Aren't the practices and the pattern stuff a way to get the belief system?
I think Shu-Ha-Ri - this just copy the rules, then break the rules, then transcend the rules - is a naïve and simplistic view of how people learn. It's nice because it's this nice little box I can say which level am I at and I can understand it all, but I don't think people really learn that. Even Martial Arts don't really learn that way. I watched my kid learning karate and that is not how he was taught at all. Yes, there are forms that you follow, but they begin sparring very quickly and in sparring it's completely improvised, but that is not something that they way didn't tell they completely mastered "blah, blah, blah" to do, I think there is lots of cycles involved and in my own practice of programming, there are times when I am just following rules and there are times when I'm breaking rules and there is times when I'm just programming and the rules are irrelevant, but it's not like it cycles through any kind of: "Well it's not time for me to brake the rules yet" so I don't think people learn that way. I don't think people perform that way at all.
So, if there is a time to just teach practices I think it's very brief. It's true that there are different learning styles, there are people who want to have the values and the principles laid out before they do anything and I think as a teacher helping somebody who's avoiding experience gain experience is something that is valuable, but there are other people who want to just do stuff they are wishing for the commandments. "Somebody brought these down from the mountain, all I have to do is follow these and then I am a good programmer and I am not really responsible for what I am doing", and as a teacher in that circumstance, helping them to understand the motivation as important contribution to what they are doing. So when I hear that question, I am imagining 2 years from now somebody making a posting on the web, saying: "I have taught 1000 programmers implementation patterns and you know what, just teaching them 77 things to do and then for the ones who are interested coming back and explaining to them: "There is some reasoning behind it" and very proudly "Here is my contribution to software engineering" " and am just making: "No, don't do that". I think to really master the topic you need to understand what you are doing at a variety of levels and I believe that the conversation experience that goes into that needs to start very early and continue essentially forever.
So can you tell us a little bit about how patterns entered the software community in the first place?
Sure. When I was an undergraduate at the University of Oregon, when I was a freshman and poor, I ran across "The timeless way of building" in the university bookstore and I couldn't afford it, so I read it standing up in the bookstore like going and reading a chapter, 2 chapters and then put it back on the shelve and then I'd come back and read a couple more chapters, so I was familiar with the whole Alexandrian style and attracted, frankly, to this "Here is the commandments". If only there could be commandments and I could just follow them, then somehow I wouldn't feel so responsible for what I was doing, which doesn't really work but, anyway that is where I was.
When I got to Techtronics and I was working with Ward Cunningham we both had exposure to Alexander's work and we talked about patterns and how they could be applied to software development. Lots of people were talking about it, but nobody was really doing stuff about it at the time, so we started experimenting with patterns, original patterns were for user interface design. A big part of Alexander's message that I think is completely lost is he made a very radical political statement about people being able to take responsibility for their built environment, for the things that were around them, that it wasn't something you'd say to an architect: "Oh, design me the place that I would love to be" and then they do it and you don't have to do anything about it. The original "Timeless way of building" was talking about this timeless way of building where a farmer wants a barn, he builds the barn, he designs and builds the barn and it works really well for his place, partly because he understands his own life and work and partly because he has centuries, sometimes thousands of years of examples, of stuff that worked better or worked worse, so you just design a barn and it would really fit both the physical environment, the available tools and skills that people were building and the activities that need to happen in it.
I think that political statement, that this is not smart architects marking places for people, coming down with the design, I cared very much about bringing that same political shift to software engineering. What I saw was programmers pretending that they were smarter then everybody else, coming down with the design that you should love because I listened carefully at some point and then built this fantasy in my head about what should happen and handing it, this finished completed thing to somebody who really shouldn't complain about result and I thought that was just garbage and I still do. The sad part of patterns for me is that that part of it has been completely lost. It's turned into just another layer of expertise, of jargon, that's used to place further barriers between the people with needs and the people who can actually make stuff and I think that is really a shame and something that I love to see brake down, where people can take more responsibility for their experience of computing.
Everybody complains about it, it's like Microsoft is like the weather, everyone complains about Microsoft and nobody does anything about it. What if the application that you're using wasn't imposed on you by somebody from the outside and importantly Linux is kind of going in a different direction, it says:"Well it's open source if you want to change it you can. What are the chances in my real terr, being able to actually change something?" It's turned into this very elitist activity where you serve a long apprenticeship before you can even imagine making a change and an even longer apprenticeship before you can imagine making a change at anybody else could possibly use. I would like to see computing open up. That experience of programming and the power that is available thorough it open up to a much wider range of people, but I think that's a big job.
What do you think about the current state of describing patterns? Are people are doing it in a good way or is it going a wrong direction currently?
Patterns are just a technique and it's what is in your heart as a writer that matters. Are you opening yourself up to possibilities when you are doing it or are you trying to create this sense of separation? Are you trying to say: "I know better than you"? Are you trying to open a conversation that says: "Here's what I believe and here is what I care about". What I've discovered is that's really hard to write those ones that are more like:"Here is what I really care about" because then if someone disagrees they are really disagreeing with you. If I just laid out the rules for whatever, say "patterns for Eclipse applications" and I don't care about Eclipse applications, which isn't true so it's not a good example, but if I just lay out: "Here is the rules for using EJB". If I just lay out the rules for EJB and I don't care then I think that is the wrong direction. It's not scary in any sense, somebody could say:" Oh that is not how you use EJB" and I say: "Fine, I don't care." But if I say "programming really matters", and I am afraid it's not true and then I write about that then I feel really exposed. And that's what I think: patterns will make a difference when people write about stuff they care about.
6 comments
Reply