 Writing for Humans, designing better software by keeping humanity in mind by Mike Moore. And that's kind of what I want to talk about. I was planning on having lots of solid, lots of code in the slides and not having any, but I just finished like about ten minutes ago, so I haven't really gone through it yet, so I'm not sure how long this will take. I think it's going to take like ten minutes, but we'll see how it goes. So a small disclaimer, I'm a Ruby guy. This kind of how I come to Agile is kind of through Ruby. And so because I'm kind of apathetic towards Agile, I don't really identify myself with Agile. I love the XP practices, but I'm not really a culture warrior, which is kind of ironic since I'm going to be talking a lot about culture today. But what I found in Ruby is I think there's a worldview that is not held by the majority that informs where Agile came from. And I think that that worldview, like you said, is a minority worldview. It's not the majority worldview. And that's something that I think we've lost, and I don't really hear us talking too much about it. And so those are some of the things I'm going to talk about. And I've heard a lot of talking around this today, but I haven't actually heard someone actually talk directly about this. And that's kind of the point I wanted to get out of this. So Ruby guy, you know, you guys could be like most famous Agile people in the world, and I would have no idea because I'm oblivious to that. All right, so what is software? So what do you guys do for... Actually, before I start, how many people here are programmers? That's like 90%. All right. Another question. How many people here have been in Agile for like more than a year or more than two years? Oh, so like about half. All right, so you're not the old guard. You're not like the, you know, you're not tired of all this yet, right? So that's kind of good because I'm trying not to be kind of jaded and tired of it. So maybe we'll have something to talk about that. So I'm feeling I might be kind of like retreading a bunch of stuff that was like discovered in 2002. All right, so this is the SICP. And the preface of this is, I love the preface. I like the prefaces in general because they really tell you what you're going to wear on the book, and they've got the juiciest quotes in it. So in it, there's a series of quotes that I absolutely love talking about what software is. That was the question I was going to ask before. So let's do some interaction, you know, at the end of the day. So let's kind of wake up. What is software? So if you're explaining it to your aunt and you see like every four years, she's like, oh, what do you do? What do you say? What is software? To save a web site. For me, software is what I tell a computer to do and in a way that other people can understand what I'm telling you. So it's instructions? So it's instructions to the computer and hints to those who have to alter the instructions later. So instructions to the computer and hints to people around you. That's what you're just doing. Okay. Anybody else? Anybody have something other than that? Kind of very machine oriented? Yeah. Usually if somebody asks in more detail what I do, it's usually more effective to tell them what the software does than what I do. And so, you know, it's not just instructions for a machine, but it actually does something useful. And if you're going to help people understand what that is, then you want them to understand why it's useful to them. So you enable some sort of utility for someone to use a machine. Making a computer more than a paperweight is how I always describe it. How great is that? Making a computer more than a paperweight. Making a machine worth something and not just something heavy. What about software on my computer or something more than a heavy piece of junk? Expensive. Yeah, expensive. Alright, so in the SICP, the professor says, again, this is to teach, I'm suspecting MIT people have a program. I outlined our approach to this subject of learning how to program. It's our conviction that computer science is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The word I want to highlight. Can you use the difference between that? Think. Now express. Yeah, it was think. That's kind of a highlighted thing. Think. Yeah, alright. Continues. We want to establish the idea that a computer language is not just a way of getting a computer to perform operations, but rather that it is a novel, formal medium for expressing ideas about methodology. Thus, programs must be written for people to read and only incidentally for machines to execute. So it kind of flips that, right? It's not necessarily instructions, it's really for the people around you. Again, the thing is, what do I want to highlight here? People. That's the word that's highlighted. We believe that the essential material to be addressed by a subject at this level is not the syntax of a particular programming language constructs nor clever algorithms for computing particular functions efficiently nor even the mathematical analysis of algorithms and the foundations of computing. But rather, the techniques used to control the intellectual complexity of large software systems. And the words I really want to highlight here is intellectual complexity. In my mind, that's what software is. In my mind, we are workers of ideas. We are organizers of intelligence. This is what we do. This is what software is. This is what makes software so completely and radically different than everything that's come before, right? Because if you're a structural engineer, you're dealing with, you know, actual materials, right? Here, we're dealing with ideas. And ideas are really tricky things. So, intellectual complexity. Our goal is to create intelligence for our own end, right? That's what we're here for. We're here to put it together and make it do something awesome for us. And like I said, it's not easy, right? Like we crash space shuttles. I mean, look at the horrible things that software has done to the world, right? Because it's very, very difficult. But I think maybe we make it a little more difficult than it needs to be. All right. So what is intelligence, right? If software is intellectual complexity, what is intelligence? What do you guys think it is? The Apple dictionary definition on my computer says it is the ability to acquire and apply knowledge and skills. It's an ability. It's not a possession, right? So it's not even something we really have, right? It's the potential of things that might be, right? That is intelligence. And that's what we're working with, right? And I don't know. That makes me kind of proud to do what I do. All right. I'm going to shift gears just a little bit. What do you often need to have? Invitance is not something you often need to have. It's the ability, right? It's the ability to acquire and apply knowledge and skill, right? It's not a skill. It's not knowledge. It's the ability to do something with it. That is intelligence. All right. So we're going to shift gears because this is an agile confidence center. This is only the second one I've been to. This is the second one last year. And I was on the panel and I said, yeah, I think agile was dying. So like, my agile confidence experience is kind of colored by that. I'm not sure what an agile confidence is supposed to be. It's called the second generation. One of the things that I actually really like about agile, like I said, I don't really like the cultural warrior type thing. But I do like kind of where it came from. I like how it was started. My understanding is where Alistair Covern came from. He was working for IBM. They said, why did some software, why did some teams work and why did some teams not work? And so he got to fly all over the world and observe, right? Observation is pretty cool. There's a lot that we can learn by observation. And when we observe teams that are successful, what do we observe, right? You know, a lot of what I see coming out of agile is a lot of tools and techniques, right? And it's from observation of teams that have succeeded, right? But one of the things this doesn't tell me is what was their thought process going into coming up with a certain technique. Or, you know, what was the thought process in deciding that this tool was necessary, that they're going to create this tool in a particular way, right? We don't know what they were thinking. All we have is the observation of what they did, you know, which you can learn from that, but you're not really going to change your thinking very easily just by copying other people's head. What we really want to learn is to want to know how they think. Like I said, I think agile came from somewhere. Agile didn't just emerge, right? Agile came out of something, right? And if we understand that something, I think it will be a lot better than agile. All right, so, let's see, who knows. Okay, so how can we learn to think like them, right? How do we, if you look at the people that signed the manifesto at, you know, the Aleister Coverns, the Bob Marvins, the Ryan Marys, the Dave Thomas' and Andy Hunt's, how do we become like them, right? That's a really difficult question. I've been struggling for a really long time is how do I emulate that, right? Is it just enough to buy the books and sort of, you know, read their blogs and try and talk it like them? I don't think it is. I think the missing element is culture. This is the thing that separates the men from boys as you will, right? This is the thing that gets you over that conceptual hump. And culture means an awful lot to me. Like I said, I'm a Ruby guy. I kind of fell under Ruby about five years ago at a real low point in my career. I was ready to kind of walk away because the joy wasn't there anymore. And, you know, I saw this, you know, it was pretty early as before Rails 1. I saw this article about Rails and I was a web guy, I decided I should look into it. And that really got me was Ruby, right? I just fell in love with the language. It made a lot of things click and make sense. I'll get into that a little bit later. But the thing that really helped me more than anything was the culture, right? Ruby's got a tremendous culture. They've got a lot of things that just, they're just really, really wonderful. There's a saying in the Ruby culture, minus one. And that means Matt's nice and so we are nice. Matt's the creator of Ruby, right? And because he's a nice guy on the mailing list, we're supposed to be nice to everyone else, right? But that's kind of an effect in the Ruby culture. Ruby is a very, very nice culture because culture matters a lot, right? It's not a zero-sum game, right? There are aspects to the Ruby culture that make Ruby a better programming language. So, it's important. Don't ignore the culture, right? If you're a java shop, that culture of Java is informing your team and how they behave, right? If you're a large enterprise, that culture is informing your team and how they behave, right? Culture is extremely important. You need to learn about the culture, right? You need to embrace it in the most instances. And the thing about the culture that I think was unique and where Agile came from was objects. Agile came out of the object culture. Agile came out of a fundamental understanding about objects that we just don't see very much, right? Those guys came back and that whole crew, they had a much different view of what objects are than I think what we do today, right? And I think it's a real shame that we kind of miss out on this different way of thinking about objects, right? So, the other thing about the culture is, you have to kind of equate it with the small talk culture. I don't think it's like 100% overlap there, right? But I think at that point in time they were really just being attacked on all sides by the C++ and the Geologists. And regardless of all of the pressure that they had on them, they still moved the entire industry, right? They got together up at Snowbird. They said, here are the things that we believe. And because it was easy enough to understand, they moved the entire industry, even though they were kind of losing the language. Okay. Here's a quote from Great Boots. I really like this a lot. Let there be no doubt that object-oriented design is fundamentally different than traditional structured design approaches. It requires a different way of thinking about decomposition. And it produces software architectures that are largely outside the realm of structured design culture, okay? It's going to be different. If you're doing what you think is object-oriented code and it looks a lot like structured code, you're doing it wrong, right? The benefits in the 80s that were talked about of object orientation was like an order of magnitude less code and better performance, right? So that means if you've got a million-line C application, it would be 100,000 lines of object-oriented code and it would perform better, right? So how does that happen? That's the promise. And different studies have shown that, right? And the reason is because it's a completely different way of thinking, right? And sometimes I don't think we have to say that or not. We have to think about it. So, I mean, they're not just smarter than us, right? I think there's a lot of really smart people in this room. I'm certainly not, you know, I'm not even in the top half of the smartest people in this room. I would be willing to wait here. But I can do what they did, right? And it's not because they're smarter, it's just because they get to think a little bit differently. So what is an object? Who can tell me what an object is? Anybody? Sure, whatever. What's an object? Capsulation of state and behavior. And identity. Okay, like that, right? It's like your encapsulation boundary, right? You know, all the operations, working on your data. Is there anything else that we think about about objects as people are leaving the room? It usually represents something tangible, I guess. I don't know what the word I'm looking for is. But it's not just state as in some arbitrary value, but it actually has information that has a value of being something. Yeah? It belongs to a classification. It's a single class. Sometimes we think about objects as a black box, right? Sometimes, like, you know, if you're old school, like an innovative circuit, are you going to reuse that? That's an object. Think of objects as people. This is the big change, the big difference in how I have approached programming, is I think of objects as people. And as I'm in my object, as I'm adding code to it, as I'm adding new features, I'm changing behavior, in my mind is always like, how does this object feel, right? Like, do I just take this object and physically lift it up and put it somewhere, right? Or do I ask it nicely to go clean their room to stop pulling their systems here, right? The key to this is a big word called anthropomorphization. I'm not sure if I said that right. This means attributing human motivation, characteristics, behavior to non-human organisms or inanimate objects, right? And we see a lot of this kind of culture, right? Is Twistory open? This week, I think that's something like that, right? That's like the perfect example of attributing motivation, right? Your toys come alive. Something that's not living comes alive. Or Bugs Bunny is something that is alive, but, you know, lots of talks like a person, right? You can reason with it, have a conversation with it, you can ask it things, right? And that responds. It has a life of its own. So when we're code, we're implementing features, responding to our customers' requests, we need to be thinking like an object or like our object is thinking, right? If this was a living, breathing person, how would they feel? It's really tempting when I code to want to think like a machine, right? I want to think like this is just a sequence of commands I just wanted to do, right? And I want to make sure that I'm not like, you know, I'm not printing memory leaves. So I'm going to do this thing in this special order because I'm manipulating something that's running, right? And I think that's the difference between structure programming and object-oriented programming, right? You need to break out or you need to kind of put away the idea of the machine and start dealing with your code as people, as humans. That kind of is also you should honor their boundaries, right? And we'll talk a little bit about that for a while. The thing about this is it's like super hard though, right? And not only do you have to like get you to do it, but then you have to get like everyone else around you to do it, all your teammates to do it, you know? And it's like the hardest thing in the world to say, well, yeah, we could add this, you know, function to this piece of code, but, you know, I don't think that the class would really appreciate it. I don't think you'd like it. You might just kind of nap. That's kind of a hard thing for him to do, right? Because he wants to be lazy. He just wants to kind of do what he does and not worry about, you know, the responsibility of the user. He must be asked if something will work in this part of the application, you know? And yeah, sometimes people don't like to, when you start talking about code that way. The other thing about this is it's really counterintuitive, you know, but I got news for you guys. Agile is counterintuitive as hell, right? I cannot get people to even try it, right? This way of thinking has informed the culture from which Agile came from, right? A lot of these ideas are just assumed in the literature of Agile, right? But maybe not something that we necessarily realize or something we give enough weight to. And I think a lot of that is because we came from procedural code. I mean, who learned to code using a procedural language or using a C-based language? Okay, who did not raise their hand? One person. List? Job. No, that's a C-based code. C-based language. Everybody, right? We all learned it. This is how we learn. I remember being in college, and I had taken C and passed out and I was taking intro to computer science. And this was before the STL was Alpha C++, so it was basically the C with classes. And I remember just like not getting why you would add so much overhead to your C code, right? Like zero benefits. Why would I add like, you know, 50% more code and give 20% less performance? You know, it just didn't make any sense. It took me a really long time trying to figure out why, you know, or kind of buy and pay as well as your presentation. When you come up in what is essentially a procedural culture, it is very difficult to move to something that's declarative, right? That's one of the reasons I'm really happy to see so much closure going on, right? Because it challenges your assumptions about what a programming language is. We find negative reinforcement a little bit twice. It is difficult, but not impossible to go against the grain. But in my experience, it is very, very, very difficult to go against the grain. And I also think that we're not really learning object orientation today. I think we learned some artifacts of it, but I think that the kind of principles, the ideas that inform what a lot of the new programmers coming up going to school think of object orientation is actually antithetical to what it was meant in the beginning back to the 60s what they were talking about, about objects, they were talking about modeling biological systems, right? I mean, how many of you guys are thinking about modeling a biological system in your code? And it's really sad. We should. All right, so at this point, and I'm sure at times, okay, at this point in my mind, I'm self-doubting myself, and I think you're all like, what is this thing about? That's just stupid, I'm wasting my time, and I should have loved those other 10 people. So that's cool, that's cool. So let's see what this looks like. Okay, so here's an entity relationship diagram, right? We've got a customer, we've got our address, and we've got our account. That's like a banking account, right? And it's got like an amount of money in it. All right, so if we have this and we wanted to, like, ship an order to a customer, what would we do? How would we get the address to ship to this customer? What steps would we go through in our head? I would assume that customer would be an object as well. Let's just assume it does. Okay, I mean, from a strict database standpoint, I would assume there'd be a foreign key to the customer, or there'd be a table that links customer and address. Well, there's a customer ID and an address. And I look up an address that has a customer ID. Basically, the ID that I have would be that. Right, okay. So what you're doing is you're saying, I need an address for this customer. Let's say I've got this, you know, this day-to-day memory representing the customer. So what I do is I say, okay, well, I'm going to ask the customer for this piece of data. Then I'm going to go out and I'm going to say, hey, all you addresses, which one of you guys are valid for this customer? Right? And I need to get all the valid addresses for the customer so I can figure out which one I'm going to shift to. Right? Now, that's great for, like, relational theory and stuff, and you can prove this. It's good. It's an optimization. Let's look at what I said. What if we're going to decrement, like, an account, the amount of money in an account? Right? So let's say this is our customer person and the wallet is representing the account and the money is representing the amount of funds in that account. Right? So how do we go about taking the money? Right? What we do is we walk up to the customer, don't talk to him, we go directly to the account and take funds from him. Now, if I went up to you and did that, what would you do? I'd punch you. Exactly, right? That's, like, really rude, you know? This is not a nice thing to do. We shouldn't be doing that. We shouldn't be reaching in and kind of, you know, manipulating the boundary of this customer, right? The customer boundary is much bigger than just its table, right? We should ask the customer, what if the customer doesn't want to pay out of his wallet, but he wants to pay out of something else, you know? Maybe he's got global wounds in his pocket. That's what he wants to pay out of it, right? We should let the customer decide, right? Do you have a pirate? The economy is crashing right now. Maybe he's, like, a Rebecca student. He's, like, worried about it, but I can't fight you. Look at that strike. No screaming game. Alright, so the reason for this is because of formalism. This is a philosophy that just permeates every part of Western culture, right? Philosophy basically goes like this. The universe, I'm going to read this actually, the universe is a very complex mechanism that operates according to discoverable laws. If man can discover those laws, he can use those laws to his own end and make things happen, right? All of our advances the last few hundred years have been on the basis of this philosophy, right? Computers themselves are on the basis of this philosophy, right? And this is, like, a death nail to writing good software, right? We don't want to do this. We want to challenge these ideas. Why? Because these ideas are facts, right? My computer's on a table. That is a fact, right? Intelligence is not based on fact, right? It's the ability to do something with it. So we'll go there. So formalism is, as much as it permeates Western culture, it's like super heavy in the technical culture, right? It's computer science, right? It's software engineering, right? We live and breathe this idea that everything is just a rule that we can push, right? It dominates even like, you know, if you say, oh, hey, you know, how's your, you know, how's this iteration going? How's your team doing? You're like, oh, it's great. We're a well-oiled machine, right? I mean, the metaphor there is that you're a machine, right? It's very formalistic. On the opposite end of this is a word that I've never heard before. It's called hermeneutics, right? And this is like a counterpoint to formalism. It's a minority point of view. In color post-modernism, it started with the study of ancient texts, right? Like sacred texts, the Bible, the Quran, older texts, right? And what they were really trying to figure out was, well, what does that mean, right? Those words on the page, I understand what those words are, but when you put them together in this way, what does that mean, right? It's really difficult from a scientific proof for meaning. You can call it the study of semantics, or you can say that it is a quest for meaning. And what I'm hearing today is telling you that there is meaning in your software. What you do every single day has meaning inherent in it because it is intellectual complexity, right? I go so far to say that there is truth in it, right? What you guys do every day is a quest for truth, right? It is not just a wrote sequence of steps or instructions to get something, right? There is truth and meaning in what you do. Here's a little bit. Let's talk about metaphor. Metaphor is really important. It's one of the 12, I don't know, steps. 12 steps of XT. It's a really important part of XP, though, right? I mean, it's not something that you would just kind of assume would be an XP. It turns out to be really super important, though. The world is a really, really big place. It's hard to understand, right? And metaphor is key to us to understand the world, right? We think in metaphors a lot. So let's go ahead and explore some metaphors and three of them. Again, it's hard to prove a metaphor, right? An object is a softball diagram, right? Or an object is a black box, you know? It's hard to prove, right? An object is a person. That's tough. Metaphor helps us understand the truth of software, right? It doesn't help us understand, like, the output that we're trying to get. It's not a specification, but it helps us understand the truth. And that metaphor also helps us discover and decompose our application space into our domain, into an application. All right. So we understand this metaphor with objects. I hate command and control. I've been in too many companies that were a command and control structure, right? One of the reasons as a programmer I don't like is I like to make decisions. And I don't like when the ability for me to make decisions is taken away. I like to come up with better ideas. And there's just too much friction introduced in a command and control structure in that type of environment for me to work in. I've decided I won't do it anymore. What about our objects? I think our code is, is your code happy? Right? Does it get to make some decisions? Right? Is it kind of fulfilling what it was created for? You know? I think too often sometimes we are command and control centered in our objects. In our creatures, right? We're creating these things. These are intelligent things that we're creating. The metaphor I want to talk about is theater. I'm actually running late. This is awesome. I thought I was going to be done in two minutes. Theater is a great metaphor for what we do as programmers, right? So our objects can be props. That's cool, right? Here's a pencil. It's on the stage. It's a prop. That's kind of like your value objects. You know, like a string or an integer. Objects can be actors, though, too, right? So if you're going to go somewhere and see your boss in play, you want to see really good actors. So objects can be good actors. And I'm going to use an metaphor. Stakeholders, I guess, can be writers. We're the directors, though, right? We're the ones who are directing the play. We're giving stage direction. We're asking for more emotion. We're telling them to turn it down. You know, this is supposed to be a serious moment, not a funny moment. We inform our actors on what they're supposed to do, right? And then they go out and do it. And I guess to really use it, our customers couldn't be audience because they get to enjoy the life. Now, there are all sorts of plays. You have the one person play. You've got the cast of thousands with the huge orchestra and the spinning stage and all the lights. It takes like a year to prep it. You know, then it goes around the world and plays for 10 years. The great thing about this metaphor, though, is that we can replace the actors in our play, right? If someone gets sick or maybe they're just not very good, you know, we get a better actor. We don't have to go back and rewrite the entirety of the script. You know, we don't have to go back and change the stage direction. We may want to take better, you know, make the most of our new actor, but we're not forced to, right? So, kind of an amusing metaphor. Sorry about that. The greatest thing about this, though, is that, you know, if you talk to actors, you know, the theater actors, you know, they always talk about magic happens on stage, right? There's always something that you're not really preparing for and that combination of actors on the stage responding to something unprepared for is magic, right? And sometimes it's so much better than what you were planning on doing, right? Sometimes that moment is just golden, right? And if we take this approach to our jobs as the directors of creating objects and putting them out on the play, we get to create magic, we get to create these moments, right? The sun is greater than the whole of its parts. I guess another good metaphor would be ads. I'm talking about command and control. I mean, you've never seen like an ad controller, you know, telling each ad what to do, because that's really inefficient and kind of stupid. Now, metaphors can be used for bad as well. One of the things that we, I saw a lot, and I did a lot, an awful lot, is I would create rigid hierarchies. This is how I learned object orientation, right? It's like, oh, Fido is a canine and he's a water pad. He was a mammal, you know, and then you just create this huge rigid hierarchy and that's like really super bad, right? That metaphor doesn't work very well for what we're trying to express in our application unless you're trying to create practical code. I don't need to say that. We should focus on the assets of what our objects have and what they do in our categories. I've seen that over and over and over again and especially the Ruby community is really informing that you don't focus so much on categorization of classes, focus more on behavior. So, I'll wrap it up. We don't need to do more of the same. We don't need more tools. We don't need to do what we're doing today to be a better developer, right? To build better code, to satisfy our customers more. The thing we need to do is we need to challenge our assumptions on what it is that we do and the importance of it. And if we do that, kind of respect the culture of where we came from. I think they're all going to be a better program. Just for my own journey, I'm so much happier than I was five years ago. And the reason is because I really embraced these ideas that were just like shocking and appalling. I would just push away at first. But, you know, if I sound crazy, which I probably do, just give it a try. The thing is, is that we're dealing in intellectual complexity, right? We're not dealing in machines, right? We're not manipulating machines, right? We are creating and expressing an idea. And that's really popular. So I want to end on a quote. I like quotes a lot. Often people, especially computer engineers, focus on the machines. They think by doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something, something, something. They're focusing on the machines. But in fact, we need to focus on the humans. On how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves. You can hear Matsumoto, the creator. I don't want to say real quick. All the good ideas. I think they're good ideas. All the good parts of my presentation. I think they're good parts. Are from this book, Object Incident by Dr. David West. My name is Mike Moore. If you know, it's mygeplomage.com. You can find me there or on Twitter. Any questions?