 How many of you have ever heard of Kent Beck? How many of you have ever heard of Ward Cunningham? Kent Beck and Ward Cunningham had a long partnership, many, many years. Most of the innovations came from Ward Cunningham. Kent Beck was the one that published everything and stood on stages and so on. I'm Dave West, aka Kent Beck. And Rebecca Rickner is Ward Cunningham. So responsibility for everything that goes on here today is hers, but I'm just the voice. So we're going to talk about design, design thinking, kinds of concepts today. When the word design comes to people's minds, these are the kinds of images that might be conjured up that kind of capture the popular conception of what design is. Something that's fancy and embellishment, pretty, makes things beautiful. And the technical realm, we probably think of design in the terms of user interface design and more recently in the notion of user experience design. Design became a real strong buzzword, of course, with the success of the Apple iPhone. Everybody says, wow, they're selling billions of these things. Why are they selling them? Well, it must be the design. It must be those really sexy patented rounded corners that makes all the difference in the world. Not true, but these are kind of popular conceptions of design that did bring the notion of the idea of design to the forefront. Today, almost everybody is using the word in some kind of a context or another, but it's not always clear exactly what they understand or don't understand or where they're trying to take the idea or notion of design. These are examples of the popular interest in the business press, primarily. Business, the enterprise side of things has jumped on this design thing six, seven years ago and started talking about, well, if we're going to be a sustainable, adaptive, innovative organization, we've got to get a handle on this design thing and they published hundreds of books. Probably a very 1% of the number of books have been published on it, putting design into this arena. So what is design? These are three kind of common definitions of what you might see in terms of design. A designer might talk about it using those first kinds of definition, taking a whole thing, taking a form and helping it express itself as a shape or enhancing the shape which is an expression of the form. So you're taking a whole thing and you are making it wholeer in a sense. This makes a lot of sense to designers. Hard-core techie engineers think it's a little bit mystical. We can also look at design and this is what the business community has primarily looked at design as an alternative approach to problem solving. One that is particularly suited to a class of problems also known as wicked problems. These are characterized by lots of variables, no ill-formed content or ill-formed requirements, missing requirements, lots and lots of ambiguity, very dynamic, very difficult kinds of problems to solve, kinds of problems that engineers don't usually try to solve. Engineers are really happy with clear definitive articulated requirements. They are happy with a world where there is a formulaic relationship between these elements and they can run it through a finite mesh analysis or similar kind of a thing in order to prove that their solution or their design, their outcome is somehow tenable. An alternative one that Rebecca and I have been using a lot lately is this last one. The informed alteration of a system by amending some element or some component of that system. This is the one that we will be using as we go forward and you'll see the way in which we do so. The last definition of changing the elements of a system gives a grounding or a theoretical basis for recognizing why there are differentiations in different fields of design. The different specializations within the design community are characterized by the set of elements that they typically use. If you look at a graphic designer they build systems which are composed of color, shape, font, spatial relationships, things of this sort. A landscape designer might use some of the same kinds of things but instead of fonts they use trees and bushes and flowers and stone and things of this sort. But that's the components, the set of components that are typically used that define that specialization. Engineers, steel, concrete, cable mesh, software designers are the most impoverished kind of designers out there. They have the smallest set of elements with which to work. We write programs. Programs are algorithms plus data structures. How much design can you do with two components? We can throw in some control structures from our programming language. We could make some arguments, small arguments that programming languages afford different kinds of elements because they give us different kinds of expressibility. It's easier to articulate something in one language simply and easily than it is in another language but ultimately they're all identical. So we really have this very impoverished set of doing things. Which is not really a problem because we shouldn't be in the business of writing software anyway. We should be in the business of doing systems design. We should be in the business of defining a new specialization. So all of you should leave this room no longer calling yourselves agile developers or software engineers. You should leave this room saying, we are reality constructors. And don't laugh because in a very real way you are. The people in this room are creating the things and creating the environments and creating the very literal worlds that everybody else has to live, play and work in. And you're making everybody miserable so stop it. Christopher Alexander addressed UPSLA a number of years ago. Christopher Alexander of Patterns fame was talking about architects and how architects also are in the business of world creation or world building. But he noticed a couple of things. Less than 10% of the built architecture around us is done by architects. And that software developers, the people in this room, they are building almost 100% of the world. We're getting there. So we're doing this kind of reality design or if you want to be a little bit less grandiose, a software driven systems design. We're building systems that just happen to have software components in them. So this requires rethinking a little bit about what we're doing and what design means and what Agile is expected to accomplish. It requires a change in attitude. For 60 years, ever since the first computer science programs were founded and the first software engineering programs were founded, we have been fascinated with the artificial. The idea is to go out and build some kind of an artificial entity which is a replica of the real world. So data of Star Trek fame, that's our ultimate ideal. It's to build something that is so realistic you can't distinguish it from the real thing. Nevertheless, it'll be artificial and therefore it'll be subject to all of these kinds of formal rules and mathematical analyses and we'll understand exactly how it works unlike the real world where we have no clue. So the picture is from Simon's Sciences of the Artificial which is kind of an indicator of that kind of an attitude that we have had and I would suggest to you that we need to change our attitude more to this kind of systemic approach. That diagram up there that I have up there, yeah. It's labeled Ars Magna, the great art. So that's another good thing that we get. We get to quit calling ourselves scientists and engineers and we start to get to be designers and artists again like we were back in the 1950s. But the diagram and the title Ars Magna comes from the book that was written by the founder of computational science. So the real roots and basis of our profession was not Leibniz or Descartes or any of these people. It was a Majorcan mystic named Ramon Lull and he built a computational device somewhat like that diagram where he could compute the word of God, the intent and the meaning of proper actions to be consistent with the word of God. That's what we're really kind of doing. Some of the reasons for using design and design thinking to accomplish this task is that there's some very definite value added that comes from this. In the case of something like Apple and I should say, I'll get corrected immediately, the popular perception of Apple is that the success of its products was due to this kind of value add that comes from design. Those rounded corners really did make a difference, but not really the critical difference. This is a shallow perception because it ignores the fact that Apple from the day that it began was very consciously and deliberately involved in design. Apple was the very first one to publish and force or try to coerce developers into developing products that met their style guide. So they had a designer think about what the user interface should look like, how things should be experienced, and this drives the entire product. So it's a much deeper commitment and recognition of the value of design than just the superficial kinds of things that people see. Design has the advantage of forcing us to think about what it is that we are doing. It'll come up in a slide in a second. Most of us are always constantly making design decisions. We're designing things all the time. Everything from our life to the products that we develop as professionals. We don't do it on purpose most of the time. Design forces us or helps us stop and think about what it is that we are doing and making it perhaps more optimal in nature. A fit is a big one. A number of different attempts have been made over time to try and get the things that we do build and that we do design to fit into the world in which they are deployed. And we really are bad at it. Some of the major advantages that we're claiming for things from objects to SOA to Agile was that it was going to somehow or other force us to think about this fitness issue and how to make the two things congruent in some form or another. It's the design thinking that is going to actually enable that. And then habitability. Habitability is a term that was used a lot in software development. I kind of dissipated it a little bit. But is this a piece of software that you would really, really like to use and in fact is easy for you to use and you find this kind of mind meld between you and the product just like you do with Word? Habitability is important. It can go all the way down to your code as well. So what is to be designed? The target is the system. According to the definition that we are using as our working definition what we're going to do is play with the system. There's a lot of different kinds of systems in the world. There are mechanical systems. The universe is a mechanical system according to physics. According to non-quantum physics. There are biological systems. There are software systems. But all systems have this thing in common is that they are nothing more. Every system is simply a set of elements and the relationships among them. So that's a very simple kind of a construct or a very simple kind of a concept. It has its nuances but it begins with a very simple approach. So what we're going to do is deliver it and informed alteration either by adding, deleting or changing an existing component or an existing relation. That's what design is going to be focused on. The specific target that we're talking about is a composite complex adaptive system. So complexity is another thing that starting in the 90s became a hugely popular area of study, area of focus. I live in New Mexico where the Santa Fe Institute is the home basically of complexity studies and has been for 25 years now. This is important because complex adaptive systems are dynamic. The world around us is dynamic. The business that you are serving or existing service of is supposed to be dynamic as well. They are more biological in nature. They have emergent behavior. They have self organizing behavior. All of these things that we talk about also in the context of agile. The composite part means that they are made up of heterogeneous components. Composite system has human beings in it. Whether you like it or not, it has human beings in it. The human beings are a source of unpredictability, unreliability. All of these kind of fun things but they are there and you need to deal with them. It also has those nice cool square edge software components that you know and love. But this composite nature of a system makes the problems much more interesting to solve and probably unsolvable without some kind of design technique. So what do we mean by deliberative design? Again this is noting the fact that we are all making decisions and by making a decision you are making a design choice. Design is ultimately nothing more than making decisions. Most of the time these decisions are either totally accidental or they are done by habit. So how many of you have written a program lately that had a main routine and a bunch of called sub-routines? Anybody? Anybody that hasn't been programming in small talk almost certainly has. That's a habit. That is the program structure chart that was advocated in 1960 as the ideal way of structuring a piece of software. You just do it by habit. You don't take any self-conscious or any conscious deliberation of that decision. You just do it. Inform design is a little bit more interesting. Deliberative design is thinking about things. Inform design deals with what it is that you think about. Inform design requires options. Requires an awareness of what kinds of available solutions are out there. Understanding the implications or consequences of adopting any particular kind of a solution. Understanding ways that a solution might be itself altered in some way or another in order to produce a better result or a better outcome or ways that you can look at your design and see how it can be improved or altered in order to enhance or to enable different kinds of options. There is a process involved in discovering these kinds of options that are available to you. It's the process that designers go through. This is a depiction of that. One person's depiction of that kind of a process. Look familiar? It should. It should really look familiar. Does it? I'm not going to try to explain the diagram to you, by the way. But I want you to get a mental impression, an overall gestalt impression of the design process. It's messy. It's all over the place. It has multiple different kinds of dimensions. It is ugly. Well, your agile thinking that you're already good at is almost design thinking. The process that you use in agile is supposed to be messy. You're supposed to be using ambiguous domain language story cards as your starting point. They're written in a natural language. They're necessarily ambiguous. They're necessarily incomplete. But that's what you're supposed to start with. The agile has come to be talked about in terms of iterative incremental development. But the original definition was exploratory iterative incremental development. You have dropped the E part of that, for the most part, under pressure from your employers or the people who sign your paychecks. Because they see it as a waste of time. Interestingly enough, if you go all the way back to the 1970s, and the popularity, the rising popularity of what was called structured design, and you were going to build a model of your system, you were supposed to build a model of the system as it currently exists first. Then you were supposed to create a model of the system that had no hint whatsoever of implementation. So that you had a lot of options to explore. Then you were supposed to do a model of what the solution was going to be and how you were going to realize that solution. And again, it was economic pressure that dropped the first two off of that. So the same thing happened with agile. The domain focus. We talk about the domain focus. There's a lot of agile practices that deal with the customer. This is the right thing to do, but again, we have compromised it in many different ways. We can't get an on-site customer, so we have a product owner. Some kind of a surrogate in between the two things. But the domain focus, domain-driven design, behavior-driven design, all of these kinds of things are agile thinking and they're very analogous to what a designer is supposed to do. One of the interesting things about agile is the notion of an on-site customer. Why don't we have Gemba, where you go where the work is instead of the customer coming to you? There's a huge amount of value in that that you will not understand what it is that the customer does, what it is the customer wants simply by them telling you. You will not fully understand it until you actually go there and see the work. We talk about decomposition of complex things into more tractable kinds of things. We try to be a little bit careful about that decomposition. We talk about teams and whole teams. I'll show you a pattern in just a minute that talks about the whole teams from a designer's perspective. We talk about space. This is another one of those things that we talk about, but we are not always allowed to actually do. The space in which you do your work makes a difference. It makes a difference at a very fundamental cognitive level. It is one of the things that makes it a problem for the on-site customer to come to you because they're moving out of the world in which they exist into a world which is alien to them. What they were really, really good at doing in the former environment, they are no longer good at in the latter environment. You can see the same kind of thing in school. You can teach somebody in school to do ratios. They'll ace the test 100% every single time. Take them across the street to the grocery store and say which is the better value, the 64 or the 128 ounce bottle at these different prices. They can't solve the problem. It's the exact same problem that they can solve in the classroom. So space makes a very important way in a lot of different ways. Again, we talk about metaphors so we're almost there. Kent Beck, when the first extreme programming made system metaphor an official practice. So if you weren't doing system metaphor, you weren't doing XP. Nobody could figure out what the heck he was talking about. So by the second volume, system metaphor was no longer an official practice. Interestingly enough, you can't think without metaphor. You certainly can't think about anything novel or new without using metaphor. You can't articulate something that is supposed to be a simulation or a simulacrum of something else without using metaphor. Stories. This is another kind of thing that, yeah, we have stories. They aren't the same kinds of stories that designers think about and there's a reason for that too and we'll come back to it in a little bit. We focus on perception. We focus on the value of humanity. So one of the things that is supposed to be an agile value is this recognition that we have integrity as developers. Our customers have integrity. That we are not supposed to be adversaries and enemies. We're supposed to figure out a way to work as one nice human community. This is a focus on this notion of humanity. Designers also think with a whole variety of heuristics and patterns. There are, when you go to design school, you learn formulas, so to speak. They're really just kinds of patterns. So a color palette, something that tells you that these colors fit together with these other colors in a good way and these things kind of clash is a pattern. It's an empirically derived pattern and it's also just a heuristic because sometimes a designer can get really cool results by violating the palette, by putting in something that is just so overwhelmingly jarring that it actually creates a new kind of a whole sort of thing. So designers use a lot of these kinds of patterns and heuristics to think with. Rebecca and I are trying to finish a book which will have a lot of these patterns in it. So these are some things that I took from that book, some specific kinds of patterns. Just the first part of the pattern description, the problem and the solution sentences. So designers talk a lot about form, that wholeness, that whole system that I mentioned very early on in the talk, that's the form. That's the thing that you're trying to help come into existence. But when you try to actually define in some kind of a concrete way, it's difficult to do. So sometimes you just use the word form as a surrogate for some kind of gestalt awareness of what it is that you're trying to solve. Product backlog is a way of understanding, expressing the form. It's interesting that the world is dynamic, the product backlog is supposed to be dynamic as well. Things come and go, shift and priority, all kinds of different things. It's important to have that product backlog explicitly in your space. It needs to be up there on the wall where everybody is walking through it, they're stopping occasionally reading different parts of it and so on. But they are constantly building this gestalt view. This is the form of what it is that we want to build as a whole. The pieces are not anywhere near as important as that whole. The focus on the domain is part of that. We really try to or should be trying to understand the domain in which our systems are going to be deployed because we really should be thinking about changing that system rather than building the artificial one to replace it. The more we understand about that domain the better. Decomposition. So in theory there is only one system and that is the entire universe. We know from general systems theory that everything in the universe affects everything else in the universe. Same thing is true with any kind of a system. It's big in a hurry. It gets incomprehensible in a hurry. Being bears a very limited brain we decompose that complexity into more tractable chunks and call them our systems of focus. They're still frequently too big so we can subdivide those again into other kinds of a system. Using the same vocabulary at whichever level of scale you happen to be working with is the key to proper decomposition. If you look at a system and you decompose it into anything except other systems you are going to cause yourself unneeded complexity. So you need some kind of a simplifying metaphor. And I would suggest to you that objects are the term, the metaphor that you should be using. And I do not mean in any way, sense or form object-oriented programming. The objects that you are familiar with in your programming languages are a pale limitation if not a caricature, if not a complete abomination of the metaphor objects that exist out there in the real world. Reasons for that. But if you think about an object and you think about an object as something that is differentiated from other objects merely by its behavior that needs to know things that it may have occasions when it needs to tell you things about itself and stick to that, you can decompose a very complex world into a very simple and consistent and common way of doing things. Later on, when you get around to implementing your objects you can say, oh, I don't have to, you're already an object and you already have responsibilities and you already have relationships with the other objects in the system including perhaps the relationship that you are my client and I as a piece of software, a software implemented object are your server or is your server. So object decomposition allows you a lot of latitude and a lot of leeway. Team is one of the things where we fall really short. If you had listened to Jeff's presentation a little bit earlier or if you had looked at any of the design thinking kinds of books that are in the popular press one of the things that they stress is teams and teamwork. We call our pattern actually is it takes a village is the pattern that deals with this kind of team and it really is very literally the fact that you need a full range of skills in order to solve these really interesting problems. You have to have a whole team. For various reasons in the agile community we have been satisfied with a whole team that consists of a product owner, a coach a couple of developers, maybe a tester, maybe a documenter if the technical writing still plays much of a role in these things. Our team is people that we are very familiar with that are part of our realm. The team does not include people from the outside. We try with the onsite customer a little bit to get to that kind of a notion but we don't have CEOs on our team even though we probably should in some sense but there's even another way that we should be thinking about teams is that there are a whole bunch of roles that we don't even think about. So one of the areas where there's a little bit of disagreement in terms of its overall value, Adeo, Tim Brown writes a book, writes several books about doing design thinking. He's behind the establishment of a deschool, design school at Stanford University which when it was first established you had to be a PhD candidate in engineering or computer science to get in which is really interesting. He wrote one of his books he wrote was called The Ten Faces of Innovation and in that he had roles like anthropologist, storyteller, caretaker, hurdler. He had all these different kinds of roles that come from observations of the way a design organization in that case an industrial design organization originally saw as needed in terms of doing a team. You need the exact same things in an agile environment or an agile team. You don't need individuals with that title. You need those skills and those roles and they need to be explicitly acknowledged and addressed. This leads to the caveat at the bottom is that you cannot have a team of specialists. You need, your team has to be generalists and not only generalists in terms of the software development process but generalists in terms of other disciplines, other domains of interest. People that have the ability to come up with new metaphors like let's build our new security system on the antibody model of the human disease systems. You need that kind of breadth and depth which leads me to a question. How many people in the room read a fiction book last week? Very surprising number. How many of you completed one nonfiction book last week? A few more. Alan Kay says if you don't read for pleasure you can't read for purpose. So if you're not reading fiction and nonfiction you're reading the nonfiction badly. How many of you do that every week? Fewer hands. That's the way that you gain this kind of domain expertise. The notion of a modern polymath, again it's something else that has talked about a great deal and some of the roots of it came out of business, some of it came out of design. It hasn't made its way into software yet. Most people don't talk about an Agilist as being a modern polymath. This is the real big one. We gave up on system metaphor because it was difficult to deal with and difficult to understand. But metaphors are the only way that we can explore the unknown. The philosopher V.O. Kline stated that on the fringes of science only metaphor will lead us forward. Same thing is true here. There is a surprising amount of metaphor in best practices. We can go all the way back to again Kent Beck's best small talk practice patterns and things like intention revealing names. This is all metaphor. You go back to Alan Kay and the user illusion. This is all metaphor. That if I look at a name of a function or the name of a variable I should know exactly what that function is going to do strictly by its name and by what is contained in that variable. If I see an icon on the screen I should understand exactly what it does. I should not understand that the Microsoft logo is now the new file menu. That is violating the user illusion. Stories are huge. Jenny Quillian who is sitting in the back is going to be doing a presentation on stories on Saturday and on user stories in particular. User stories, again, stories are the way that we understand, retain and transmit knowledge. We can do facts in any number of different ways including a requirement spec. We can do knowledge without embedding it and embodying it into a story. But we don't even try very much to tell stories. We don't encourage our users to tell rich stories. Instead we have come to rely on templates. As NX, I want the system to do Q because Z. There is so much of a requirement and so little of a story that it is really sad. We aren't comfortable with the ambiguous, but if you want innovation, you better have a story. You better have the ambiguity and the context and the full plot kind of things that are going on in a story. Perception is something I've been talking to actually to a various number of people. When Kent Beck first, the first XP book, and I keep referring to that one because it was the first published Agile book as well. It's an explosion the same year, but that was technically the first to market. I said that there were three stages of XP and Agile is substantially XP even now. The first was out of the box, just do what you're told and do every single one of it and every single thing that you're told and do it exactly as you're told to do it. Step two was adaptation. Now that you really know how to do it, now go ahead and give yourself some latitude and leeway to take into account your specific circumstances. The third stage was transcendence. Didn't explain what transcendence meant. Christopher Alexander, when he was talking about patterns and pattern languages, in his companion volume, The Timeless Way of Building, pointed out the fact that a pattern language also was but an intermediary step. It was a gate and until you passed through the gate you could not really practice the timeless way. Transcendence is something that's not unfamiliar to most of us. That little moment where you're kind of in the zone and you can write a hundred lines of flawless code in a feverish 90-minute session. You're Michael Jordan on the basketball court and you cannot do anything wrong. These things are not alien to us, they're not part of our standard way of being or our standard mode of operation. This no whole motion of perception is being transcendent. The third stage of being agile and we're just barely starting to explore ways and ideas that we might become transcendent agilists. The illustration on there is from a Zen Japanese, a Zen painter called Seshu lived a long time ago. One of the things he's famous for is his long scroll. It's about 14 inches high, 50 feet long. It has this kind of detail. It's a landscape, a big long landscape painting of a journey through Japan. There's a lot of brushstrokes in that sucker. He painted it according to the inscription at the end. He painted it on a summer afternoon, summer day, give him a whole day, a summer day when he was 67 years old. He had zero time for any conscious thought. The goal or the end, the objective, the system that was going to be designed, is to load through him and express itself on paper and he was just the transmission mechanism. We need to be in the same way. It's not really any different than being a master chess player. If you are going to be a master or an adept or a transcendent agilist, you need to be in that same kind of state of mind or frame of mind. The end word goes back to the humanity. So I'm going to preach to you for a second. Why do you hate people so much? Including yourselves. We have this fascination with the machine and with the mechanical and the predictable and the deterministic and we choose way too often to focus on that and making that an optimal kind of a construct regardless of the consequences or the effects that it has on machines. We think absolutely nothing about using our technology to create a job that has to be one of the most mind-numbing things in the world. So there's a McDonald's in the mall over here. There's McDonald's all over the United States, of course. When you drive your car up to a McDonald's window and you give them your order, I would like a Big Mac with fries please, but there is an increasing chance in the United States at least that that order is not going to a human being inside of the store. It is going to a call center in Fort Collins, Colorado where some poor sucker is sitting at a desk eight hours a day asking, would you like fries for that? It's your technology that made that kind of thing possible and you don't even consider or think about those kinds of consequences. So the biggest thing that I believe the design thinking would or should contribute to what it is that you do as a profession is to refocus your attention on the world in which people live and make it a better place. Focus on the humanity. That's it. What's the time? Quarter past. So I finished as I planned. We have time for questions if there are any. And I noticed on the schedule that there's nothing after us until seven o'clock. So ask away. Yes. In design thinking, are they used as a stepping stone until you have something that you can then articulate in the natural curve of that domain? Or is it something that should last the entire process or the entire existence of whatever you're creating? I often find that that's the first that you attempt actually quite weak and they break down on a certain idea. So just your opinion on that? So if I am getting the gist of it is that people are not able to articulate what they want and you have to engage them. So when you have a design client, do you ever talk to them? How much do you talk to them? It's a difficult task when you have many people, many things going on. One of the, what do I say, not to constraints, but Steve Jobs said that people said often that he was some sort of dictator because of the design. I was particularly asking around the use of metaphors and when you find a metaphor that is quite weak and doesn't hold true, do you just toss them around and you just pick up on another one and does that mean reset and start again? No, no. So that's one of the beauties of metaphors. So the beauty and power of using a metaphor is that it gives you a real simple statement like the solar system or an atom which I don't know anything about is like a solar system. So that's the metaphor. That, now you can keep that in your head, right? And you can keep it in your head through the whole process of development. So, but the metaphor can evolve. So you can say, oh well gee, if an atom is like a solar system, then there should be something at the center like there is a sun at the center of the solar system. Aha, there's a nucleus. Well, there should be something orbiting like electron, well, like planets, electrons. So as you, the metaphor suggests all of these different kinds of reference that allows you to keep a holistic concept in your head even while you're exploring details. And you can always come back to that centrality of the metaphor. That's what it was supposed to be in extreme programming. If I came up with a system metaphor, a very simple way of expressing what it is that we were trying to build, a common view, common idea. Like on the C3 project, the Chrysler payroll project, the metaphor was a cafeteria tray and a steam table. So instead of having some kind of a big monolithic decider of what your paycheck should look like, which was a very complicated decision, they said, no, well let's turn it around, let's pretend like your paycheck is this little table and it's moving down this little tray, it's moving down the steam table, and you can pick this and you can pick that. So having that as a system metaphor then meant that when any team was off doing something, very specific, very concrete, and have the potential of losing track of how what they were doing coordinated and connected with what everybody else was doing, they could always ask themselves the question, well, am I still being a tray? Am I still being an entree option or a dessert option or whatever? So the system metaphor allows you to keep a great deal of complexity and coordination in your head. That being said, it is still very true that you cannot keep all of this stuff in your head at the same time. So one of the values of having user stories and product backlog and things like that up on the wall is that they are evocative triggers. That even if I don't remember right now exactly what was supposed to happen with this story, I can kind of look up at the wall and say, oh yeah, I remember, or I can look at this whiteboard diagram over here and I say, oh yeah, I remember. So we can use the environment, the space around us as a external memory that is really nothing more than a set of evocative triggers which does recall to your mind everything it is that you do know and you know a lot. So the two things together address that complexity. Thank you for that question. Just a second. So when there is an idea in the head and you try to give it a form or a shape and that's where you start decomposing, right? There is some sort of a loss. When you try to give an object representation, I'm not talking in terms of software but just in terms of an idea. There is definitely some kind of a loss. How do you deal with that kind of a loss? You may not have arrived at a crisper object or a crisper yet, abstraction yet. So how do you really deal with that kind of a loss in the translation process? So I have an idea or a construct. I have this image of the wall. I don't even necessarily have an image. I have this sense. Yeah, exactly. This implicit sense of what it is that I want. And any way that I articulate it is less than what it is. Yes. I find that trouble. I have that gap. I cannot do that completely. So how do you... Yeah. What you're describing is the classic paradox of a mystic. I have experienced reality. Anything that I tell you about it, however, is false. Doubt, doubt, not doubt. That's the problem that you're dealing with. And there's no formulaic way of getting from this inarticulate or inarticulable ineffable kind of a concept that's inside of you to the design except trial and error. So you do something. And then you look at it. You evaluate it. There were two words on that model that I had up earlier. One of them was exploration of the space. The other one was imploration. So you evaluate your product. And then you either say, yeah, that's almost it. If I adjust this, it'll be closer. So you just iterate through that until you say, ah, that's it. Or at least, ah, that's as close as I'm ever going to get. So it's an iterative process, right? A couple of years ago, Richard Gabriel did an onward essay that was called the Designed as Designer. And it talks about this kind of iterative process. It talks about how the thing itself, in the example he used, it was a cathedral. How the cathedral tells the designer, the architect, what it wants to be. As long as the architect is listening, of course. So all this stuff sounds very kind of fuzzy, but it is the only way that you do it. Designing software, however you want to do it, is a wicked problem, right? One where there's things that are changing, the problem changes on you as you learn more about it. There's a lot of elasticity that are occurring. There's all kinds of stuff happening. And when we're designing products, there's stuff on the product side that are unknown. There's stuff on the implementation side that are unknown. And the metaphors that we use, the things that we hold in our hand and say, ah, this is what I'm going to do. There's more than one metaphor that exists. There's usually a product metaphor that exists, as well as the instantiation of how we're going to solve that. And I think he's juggling when you're in a space where, again, it's wicked. We don't even know what the products really are yet, what the things are going to give us success, and we don't know exactly how we're going to go about doing it. I have an answer, but I want to hear you say it. You're the designer. You're better equipped to answer this than... I think that there is something implicit in the idea or notion of a system metaphor. Well, actually, back up, never mind. There is... That out there is the metaphor. So if you're building like an architecture of a system, it should be the architecture of that out there. Now, the... And if you do those kinds of things, and if you use objects, and objects are represented by things out there, whether they're tangible or intangible, it doesn't matter, but they are out there. There's something that somebody out there has bothered to articulate in design. So reality is your metaphor. Your experience of reality is your metaphor. But only if you recognize that what you are supposed to be doing is changing that system, not building a duplicate of that system over here. If you're trying to build a duplicate of that system over here, then no metaphor in the world is going to help you. Yet, to form a metaphor, might form a metaphor against it, there's something that describes it that I want to be able to look at first and say yet, if you want to write a graph. Those things aren't changed, and they influence one another. The iterative possibilities here, there's some kind of engineering possibilities here. How do you maintain both of them? A finished product or an innovative new kind of a product. There is also a sense that there are patterns out there, which could definitely be a valued source of things. Again, if you're aware of the patterns, there are young's communal mind and all the iconography and stuff that comes along with that. So you have within yourself things to remember. No. Patterns have come to be regarded as a template of things that we have solved before. Patterns should be something that we have observed, recurring in nature that can be implemented in a similar fashion. Patterns are of the world, not of the... I don't know. I've had a lot of things to solve. Yeah. Yeah. I think you had a... I don't know the language. The pattern language? You know how he jumped? That was a brain-oriented tool. Out of the blue. Do you know why? So the person that could actually tell you first hand just left the room. So I will tell you what I know of it. And that is Alexander... So why did Alexander go from this mystical kind of thing and looking for these things into a very formulaic kind of a pattern language? Alexander has... Opposite. When you wrote the scenes of what? Yes. Right? Right. In essence, it's a rescue. Right? Yep. The architects all over the world would cite you to help you. And then what was his response? He wrote a book. Alexander was conflicted. Alexander was conflicted. Right from the very beginning, from notes on the scenes of the reform. So ostensibly, notes was supposed to be a... the discovery and articulation of a science of design. There's all kinds of mathematical looking formulas. Yes. Yes. So on the one hand, I really want this science. He was trained as a mathematician before he was trained as an architect. So I want this mathematics of design and this mathematics of beauty. At the same time, he's got all these little weird diagrams that don't make any sense whatsoever. This is his... I want to understand beauty, what he later called the quality without a name. I want to understand the mystery. And I don't want to articulate that. The contract, because he feels that... it's also in notes that if I do... if I was successful at creating this mathematics of design, it would be... it would take me into this thing that he called the self-conscious process, where it now starts to lose all relationship to that which was going to be described or designed or beauty or anything else of this sort. So he was conflicted. When he got to a pattern language, he wrote... Yes. Yes. Yes. When he got inspiration, he got inspiration from something. He got inspiration from the works, the virtual works. He spent all his money by his virtual works. No, he also liked the slums in Brazil too. Yeah, yeah, yeah. Yes. Yes. Algebra. Do you see all of this? No, algebra. No, algebra calculus, either one. The left side of the brain or the left side of the brain? Well... No, really, this is serious. If I'm a student of algebra, I think with the right side of my brain, if I am an inventor of algebra, I probably started on the left side, and then articulated on the right side. I equivocated. No, really, the left side of the brain, the left or the work of the left side of the brain, the right side of the brain, the left side of the brain, the right side of the brain, the right side of the brain. And then, but this is important. It was for example, as an architect, I had to study the domestic rules. Wow. And then, it was really hard to recognize them who knew the domestic rules. And then once I found the book, oh, the book was fantastic, except what I wanted perfectly. Except what I wanted perfectly for architects. And then, I met a colleague, a mathematician, that was a colleague of this guy. And he told me that this guy has a wife, that would make love to all his friends, he would always drink it. And I said, oh, this is right. He's able to drink with the right side of the brain. Right? No, really, I'm not sure. It's true. I was really curious. Oh, the guy was so different from the other mathematicians. They were left-side brain-oriented, right? And then, what we saw was left-side. And when I was doing my post-doctorate research, my supervisor, one of my supervisors was the director of the Institute of Mathematics in Brazil. And then, oh, I was delighted, yeah? Because he got the label, you know, the label. Oh, then he said, oh, now I'm going to show you. Like this, the people of the night, how you're going to fight the generators of the sub-breast groups. Like this, you know, you're in there, it's all numbers, you know, but I didn't do it, you know, there's a point to it. So, algebra is also there, too. You can do it with track, though, without this recursive system, right? So, Alexander faced the exact same problem of everybody else that believes that they have perceived an ineffable truth. You don't want to keep it to yourself. So you write a book. And even when you write the book, you sit there and say, yeah, but to yourself. But I don't think he ever really ultimately came to a satisfactory conclusion for himself that anything he said was, in fact, what he believed he saw. Okay, so we're officially past our time. We will continue this discussion if anybody wants to hang around the table. And thank you.