157 RR Book Club - Object Design Book Club with Rebecca Wirfs-Brock

00:00 4983
Download MP3



01:38 - Rebecca Wirfs-Brock Introduction

02:57 - Unofficial Rogues!

03:32 - Object Design

  • Tactics & Strategies

04:52 - Responsibilities

08:03 - Thinking Through Design

18:43 - Naming (Vocabulary)

  • Role Stereotypes

21:53 - Patterns

  • Singleton
  • Iterators
  • State Machine

31:13 - Design Thinking and Making Software

33:36 - Consistency

  • Removing Roadblocks
  • “Fed-Ex Day(s)” (Debt Reduction)

44:21 - Object Neighborhoods

49:54 - Modeling

  • Inventing Objects

56:36 - Balancing Trade-Offs and Design Decisions

01:03:28 - Getting Better at Design

  • Pair Programming


Book Club

Refactoring: Ruby Edition: Ruby Edition (Addison-Wesley Professional Ruby Series) by Jay Fields, Shane Harvie, Martin Fowler, and Kent Beck

Refactoring in Ruby by William C. Wake and Kevin Rutherford

Next Week

Rogues Only


JAMES:  Alright, we’re talking about Object Design today? DAVID:  Let’s design some objects. JAMES:  Let’s do it. Let’s design objects. REBECCA:  Okay.[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]**[Snap is a hosted CI and continuous delivery services that goes far beyond letting you do continuous deployment. Snap’s first class support for deployment pipelines lets you push any healthy build to multiple environments automatically and on demand. This means with Snap, you can deploy your staging environment today. Verify it works and later deploy the exact same build to production. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many, many more. You can also use Snap to push your gems to RubyGems. Best of all, setting up your build is simple and intuitive. Try Snap free for 30 days. Sign up at SnapCI.com/RubyRogues.] **CHUCK:  Hey everybody and welcome to episode 157 of the Ruby Rogues Podcast. This week on our panel, we have Avdi Grimm. AVDI:  Hello from Pennsylvania. CHUCK:  David Brady. DAVID:  I’m against the objectification of code. CHUCK:  James Edward Gray. JAMES:  Woke up to a new Ruby today. It’s like Christmas. CHUCK:  [Chuckles] I’m Charles Max Wood from DevChat.TV. And this week we have a special guest, and that is Rebecca Wirfs-Brock. REBECCA:  Hi guys. CHUCK:  Do you want to introduce yourself really quickly? REBECCA:  I write a book about once every decade. The last two have been on object design, not that I’m stuck in a rut or anything. I gave up Smalltalk in 2000 and have moved onto other things. My last client was in Smalltalk. But a lot of what I learned about object design was inspired by my experience discovering Smalltalk. DAVID:  You gave up on Smalltalk in 2000. There are 12 people that are still calling you a quitter. But everyone else knows you’re a die-hard right? CHUCK:  [Laughs] REBECCA:  Actually [chuckles] actually it was a financial concern. Clients pay you to do certain things. So, I just had to get over it. [Laughter] REBECCA:  And it’s quite fine. There is life beyond Smalltalk. In fact, there are some really good libraries out there in many different languages. CHUCK:  So, those 12 people are actually calling you a sellout. But we still love you. REBECCA:  Okay, great. [Laughter] JAMES:  Rebecca, have you seen some of the recent Smalltalk developments? We were talking about, was it Pharo recently on the show, that has the new version out. It’s pretty nice. REBECCA:  Yeah, and I have some old Smalltalk friends that are still doing that. But I’m in a different space these days. JAMES:  Gotcha. CHUCK:  So, before we get started, I want to mention that we had two Unofficial Rogues sign up. Now, if you go to RubyRogues.com/Parley, you can sign up for Parley. And one of the options is an Unofficial Rogue signup, which is $50 a month. So, the two people that signed up, one is they signed up on behalf of their company or product and that is Logdown. And that’s a markdown blogging platform for hackers. You can find it at Logdown.com. And the other is Russell Jennings. So, thanks a ton guys for supporting the show. We really, really appreciate it. JAMES:  Thank you. AVDI:  Thank you. JAMES:  Thanks Russell. Thanks Logdown. AVDI:  So, let’s talk about object design. Can we start our just by defining some terms? What do you mean when you talk about object design? REBECCA:  In a nutshell, no object exists in isolation. So, if I’m building any sort of software, I have to think about objects that interact with each other. And the way I think about design is strategies and tactics for making them work together. So, that’s how responsibility-driven design came to bare, was basically thinking about what’s a way of thinking and strategizing about distributing the work amongst a set of collaborating objects. JAMES:  So, I like it that you used the words strategies and tactics there. I’m a tournament chess player. So, we love strategies and tactics. So, tactics would be the line by line or small-scale maybe method by method techniques you can do to improve things. And then strategies is more of the overall vision of the system or at least subsystems, right? REBECCA:  Yeah, a set of objects. Yeah, and the devil is in the details. A tactic is also, besides just factoring out methods, it is, what do you choose to reveal or encapsulate? AVDI:  You used the word responsibilities a lot. And the subtitle of the book that we read was ‘Roles, Responsibilities, and Collaborations’ I believe. Can you talk a little bit about how your focus on responsibilities differs from some other approaches to object-oriented design? REBECCA:  Well, responsibility-driven design was my reaction. Originally I read a paper with Brian Wilkerson when I was at Tektronix. And I was a newbie to objects. In fact, I’d come from writing in Assembly language in PLM, god forbid. And it seemed to be that in the day, early days, people didn’t have any sort of sense of how to structure an application. And when I came to the Smalltalk community, I felt very much like an outsider, someone who was, I’m going to say discovering what the good people did that could go fast. And what seemed to me is that what you focused on, what you emphasized, really had a significant impact on your design. And so, if I want to worry about hiding details, then I should think about the interfaces first, or what objects offer up to other objects as their set of responsibilities. And, if I had a focus on let’s say data, then everything is open and transparent and there’s no hiding or encapsulation or abstraction that happens. So, that’s where I started with thinking about it that way, the difference between what do I emphasize first, what am I thinking about? AVDI:  So, if I’m designing a banking system, what are some small-scale examples of looking at things in terms of data versus looking at things in terms of responsibilities? REBECCA:  Well, if I think about, yeah actually let’s use a banking application. If I’m thinking about just how do I represent accounts and account information or banking transactions, then I pretty much end up with a bunch of data structures that are manipulated, let’s say an online banking system through a GUI. And I might end up with something where I don’t really think about the issues of, do I need to have this view of this data? Do I need to have different behaviors? I just might end up with data from the database, filtered and streaming to the UI and back and forth. AVDI:  Okay. JAMES:  When we talk about responsibilities, obviously we have the responsibilities of the inter-object communication. But also, in the book you talk about the external actors on a system which can actually be buried, so users or even other software that is interacting with your system and stuff. REBECCA:  Yeah. And how do I want to represent those things inside my system? Yeah, that’s another aspect of sources for objects. And instead of just using let’s say a native API to something, maybe I want to wrap it in something that provides a better abstraction to me. AVDI:  Reading your book I was really struck by something. It actually made me look back at my career a bit. When I entered the industry it was late 90’s, early 00’s. And I started out in a very big defense contractor. And the way we did software development was pretty regimented. There was requirements, there was high-level design, there was detail design, there was implementation, and then there was testing. And of course implementation, I was always supposed to be a minor detail. JAMES:  [Chuckles] The uninteresting part? REBECCA:  Sound very un-agile too, by the way. [Chuckles] AVDI:  [Chuckles] Yes. Yeah, this was long before the defense department started talking about doing agile and actually mandating it and stuff like that. Long, long before. I think agile was this crazy stuff that was way out on the periphery. And I think this was just after   had started writing about extreme programming and stuff like it, or at least publishing about it. But there were a lot of whiteboard scribbling and tossing ideas around for design at that point. Now, I’ve moved on from that world and also I think that the industry has moved on. There has been, I think what could easily be called an agile revolution. And at this point, very few other programmers I know would even dream of doing anything remotely like that. The projects I’m familiar with now are usually, “Let’s just get down and start coding right away.” And it was interesting reading your book because you’re talking in that book a lot about thinking through designs before you start writing code. And you make an interesting statement about how it’s easier to throw away a CRC card or move a CRC card around or something like that than it is to move code around. I wonder if you could expand on that a little. REBECCA:  Sure, and I just want to correct one thing. I think if you get the impression that I am not a fan of thinking while you’re coding, design thinking while you’re coding, and that you can go that way too, I want to correct that. But one of the things that I do want to say is that I’ve seen people these days, and I spend a lot of time working with agile folks, where they don’t really have a vocabulary to discuss what their options are as they’re furiously coding. And so, I tend to think that I love of what I brought to the table in my book, in our book, was essentially a vocabulary for talking about the tradeoffs that you’re making. Do I want to make this structure do this? Do I want to move out control from here? Do I want to… Shouldn’t this domain  object have some responsibility to do this? And so again, I view what was brought to the table .It’s pretty much a lightweight thinking set of tools that you could apply whether you’re doing a lot of it upfront or on the ground as you’re programing. AVDI:  Right. Yeah, I don’t see that dichotomy. CRC Cards… AVDI:  Well, and I don’t want to say, I’m not saying that I think you’re representing one side of anything. I want to get your perspectives. REBECCA:  So, CRC Cards actually are something that is an artifact of trying to get people that aren’t even familiar with objects familiar without getting lost in the weeds, and taking a higher level view of something. But if I’m doing a CRC modelling session with a set of objects, I can take half an hour [chuckles]. It doesn’t have to be a long, drawn out kind of thing. AVDI:  What I was struck by there was that I’ve moved into a very, very agile mindset of, “Let’s get started.” But when you wrote that about how it’s easier to move a CRC card around or throw it away or change the name or something, it really struck me, because I think there’s a real truth there. REBECCA:  Well, the thing that I find, and lately I’ve been [inaudible] in Java [chuckles] and JavaScript is you get this mental investment in whatever you’re creating. And I don’t ever get mentally invested erroneously in a CRC card. I view it as a scaffolding for my thinking. And maybe if I were, I don’t know bolder, I would just throw away stuff. But if you think about what TDD practiced says is, “Let’s write the next test. Let’s make it fail. Let’s make it pass. Let’s write just enough code.” And so, you do get an investment in the interface and the set of responsibilities that you’re putting into those objects. And so, to break away to do any sort of refactoring or even rethinking takes stepping back a little. JAMES:  You have a good quote in your book that I think sums this up. It says, “If you insist on using a computer, don’t be lulled into thinking your candidates are well-formed because type responsibilities look neater. At this stage, exploring options should be fun, easy, and low-cost. That made me think about the value of things like spikes where you sit down and throw out the rules and just try to figure out how do I hook this thing to this? And you’re just noodling with code and stuff like that. REBECCA:  Noodling and thinking. And actually, the original intent of XP design spikes, I don’t know if you’ve gone to the ancient [inaudible] website, he talks about it. An XP spike is where I may explore for a while and failure is expected. [Laughs] And I don’t know that I see people doing spikes in that way, just to play around with ideas that when something is sticky and not working so well. But trying something and just for the fun of it and figuring it out and saying, “Oh, that didn’t work,” is okay, I think is a good thing. But most people I think are a feature/get-that-next- story-done-driven right now. DAVID:  I don’t know if you’re keeping track of all of our titans, but they’re having an epic battle right now over TDD. REBECCA:  Oh, yes. DAVID:  Yes. And yeah, one of the common statements made by one side of this battle is that yeah, TDD focuses you on writing well-factored methods but it leaves you with awful architecture. And because I’m pretty solidly on the other side of this camp, I’m like, “No, you fool. That’s like saying you can’t do calculus because you’re so good in arithmetic.” CHUCK:  [Chuckles] REBECCA:  Right, right, right. DAVID:  You can get from one to the other. But I think you’ve really touched on something here, which is this investment. When I first played with CRC cards, I’m a programmer so I’m obviously thinking about optimizing. And I’m like, “We should get special printed CRC cards.” [Chuckles] DAVID:  And the person that I was talking with, I don’t remember who it was, but they turned to me and said, “No, because these are throw-away. We have to do these on index cards, on crappy index cards, so that you will never stop thinking that they’re crappy. You will never elevate them.” And it’s like design tools, like Balsamiq, or like just sketching on the back of an envelope. You don’t get invested in it. And I ended up carrying that into the TDD world. A great term that I use is the phrase sketch code where we’ll be throwing stuff back and forth and we’re like, “Okay, this is great. We should ship this.” And we’re like, “No, no, no. Hang on, hang on. This is sketch code. We can throw this all out and rewrite it if it doesn’t work right.” REBECCA:  And that’s a great phrase. But how many people do you know get into this investment and down want to throw it away? DAVID:  I have adapted the term sketch code, or adopted the term sketch code specifically as a defense against this, because you’re absolutely right. What you spend time on, you unconsciously invest in, sure. AVDI:  We’re throwing the term CRC card around. For any listeners who don’t know what that means, can we get a quick definition of that? REBECCA:  So, like all good things CRC cards were invented by Ward Cunningham and Kent. [Laughter] REBECCA:  And Ward has said that I’m famous for popularizing techniques that would have never, that would never have been so popular if he had had to write or talk about them. But they’re a light-weight technique for understanding what responsibilities, the methods if you will, but at a higher level, of a class and who it’s collaborating with and why is it existing. So, it’s the lightest weight modeling tool I know, other than programming. AVDI:  And it’s typically just an actual physical card of paper, right? REBECCA:  Yeah. AVDI:  And one of the things about it is that you’re constrained in what you can write on a 3 x 5 card. REBECCA:  Yeah, which forces you to abstract a little. Actually, there are some side benefits of that. If I just get invested in a long-winded set of methods in a class, I don’t necessarily see its overall shape. And so, the fact that… tiny cards are very good [chuckles] rather than sheets of paper. JAMES:  I think that’s been a source of some of my failures in the past when I work with tools that do UML modeling or things like that, is that they give me so many options and put all those doodads in front of me. So then, when I’m modeling I think, “Well, I just came in here to understand this relationship,” but I see they have these tools for modeling this. So then I end up going down the rabbit hole and doing more than is really valuable. DAVID:  There’s a downside to that, too, which is you open up this tool and it’s got all this stuff. And it’s got this wizard for building an ERD from your database, entity-relationship diagram. And so, you’ve pulled in this big UML thing but yet you came here to design one thing. And it turns out that now you can’t edit any of the things on the ERD because that would be wrong, because that’s not what’s in your database. And suddenly your computer program is telling you, “No. Don’t design new things. Draw pictures of your database.” And ugh, it makes you want to punch the computer. CHUCK:  [Laughs] REBECCA:  Yeah, yeah. So, I tend to not use tools like that one you’re talking about. If I am drawing anything, it’s the sketching tools as well, because it allows me to leave out what I don’t want to think about. AVDI:  Rebecca, you mentioned the value of giving names to things earlier. I wonder if you could expand on that a little bit. One of the things that I thought was cool about your book was that you actually have names for different styles of control in programs. REBECCA:  Yeah. And again, I think there are different kinds of names. Talking about control styles being whether I have a delegated style where I don’t have a god-like object just sending to everything and telling it what to do. That would be a centralized control style. And I might have something where I’m using lots of tiny little agents communicating to each other and I might have a very dispersed control style. So, having vocabulary to talk about what style I want to use is very helpful. For example, if I’m picking up a framework to use, what style does that encourage me to do? Frameworks don’t necessarily dictate but they tend to lead you to certain styles of plugging in and adding your behaviors to them. So, that’s one aspect of vocabulary. I think another equally, probably more significant for people who are serious about objects, is the notion of role stereotypes and how they fit together. And originally, this was back in the last century, came up with six role stereotypes that were pretty common and mentioned those. And that’s probably a new addition of thinking about objects and how they fit together. And in fact, thinking about whether something is an information holder or a structurer or a service provider or a controller or a coordinator, the distinctions between those two might be a little subtle, and whether you have a certain kind of interface or roles for certain objects, is very helpful of having a vocabulary, particularly when you’re making changes or trying to pick up some framework and see what it’s doing for you or against you. Those are useful ways of thinking about the objects that you’re building up. AVDI:  I was really struck by that, too. I enjoyed the use of the role stereotypes over the course of the book. At first I thought, “I’m never going to remember all these,” but you used them over and over to apply to different things. And I started to see them as really helpful ways of looking at patterns from a higher level, because a lot of these encompass many different patterns. REBECCA:  Patterns or digging into the elements of a pattern. I might say dissecting any sort of set of classes that I’m looking at can help me characterize these objects. And so, I tend to look at the lens of [inaudible]. I use these ways of looking at design as in a way of dissecting any code I see, whether it’s in Ruby or any other object-oriented program. It’s very helpful for me. JAMES:  Since we’re talking about patterns, this has also come up in the recent TDD debates. Any pattern can be your friend one minute and the straitjacket that’s holding you back the next, applying it too much or in not appropriate places. So, the value of them I think has been called into question again recently. But I like what you just said earlier about the six different roles that you like, or stereotypes. To me, another advantage of loading these common patterns and stuff, you’ve talked a lot about the terminology it gives us so that we can have these conversations about them and without having to clarify a whole bunch of things upright. But also, I find that loading a bunch of them into my brain gives me jumping off points for when I run into a problem. Well, it’s kind of like this pattern. So, I can start from that and then I have somewhere to go off from. Whereas if I don’t have that, then I have to figure out everything by myself and that’s harder for me. REBECCA:  Right. So, I guess maybe you’re asking me to weigh in on my opinions on patterns. JAMES:  Sure. REBECCA:  It’s interesting. I always feel myself as being a late-comer to anything. I was a late-comer to objects. But it’s probably [laughs]. There are people who had been doing Smalltalk programming for five years before I started. But similarly, when the first inkling of patterns started I thought, “Oh, I don’t like the stylized way that they’re explained.” But now I view it again as if I know patterns, then I do have the design shorthand for looking at something and being able to see more quickly what’s there or what’s not there. And also again, if I share that vocabulary with someone else then I can have a conversation that starts in, “We need to put an adaptor here because this interface sucks. I need a gateway. I don’t want to have my service directly called. I want to have this external process.” I can have these higher level conversations. So, I view that as helpful, not harmful. But again, it requires you to have this, I don’t know, urge for shorthand so that the details can then be worked out a little more quickly. So, you have to learn these things and see them in practice, I guess. Not all patterns are my friends. There are certain ones that I find totally useless. [Chuckles] AVDI:  Oh, do tell. CHUCK:  [Laughs] REBECCA:  Oh, okay tell. People like to rail on singleton and I’m going to say, yeah rarely is that a useful thing. But I don’t need iterators. Anyway, yeah there are many, many patterns I could complain about. But [they know]. JAMES:  That’s interesting. You’re not a big fan of iterators. It seems like they’re moving into more and more languages these days. REBECCA:  Yeah, no I know, as a separate thing. Well so, that’s the point. It’s now built in to certain languages. So, I don’t need to have a pattern. Patterns were originally intended to talk about things that I had to build up myself because languages didn’t provide them. JAMES:  Ah, I see what you’re saying. REBECCA:  Okay, okay. JAMES:  Yeah, yeah, yeah. DAVID:  Like how in Ruby we have no respect for the observer pattern because… REBECCA:  Right, everything. DAVID:  Observer is built into the core. REBECCA:  And that’s exactly right. And I remember Neal Ford giving a talk at some conference about how some of the original Gang of Four design patterns were useless because you could do all these things in Ruby anyway. And I thought, “Well no. You still can talk about what this thing is,” but yeah. DAVID:  I like that you pointed out that it gives you a shorthand and downplayed maybe perhaps the implementation side of patterns. I worked at a shop where we were madly in love with patterns just on the face of them. We just loved patterns, period. Capital P. And by the end of a year and a half of that love affair with patterns, we had observers that were being visited by visitors. And those visitors were being visited by other visitors. And they had to implement them. We literally had a visitor that visited the observers of the visitor visitor. REBECCA:  Okay. [Laughs] DAVID:  I left that shop and two years later somebody asked me, “What do you think about patterns?” and I said I think they’re a bad idea. [Laughter] REBECCA:  Well, so yeah. Any sort of overworking of things and levels of indirection, which it sounds like you’re doing, is something that makes it harder to comprehend. Or things that have delayed side effects. I remember my very first bad Smalltalk program was reading in fonts, different kinds of fonts and font families. And I fell in love with blocks which are the moral equivalent of closures these days. And so, you fall in love with cool things but then after a while you say too many observations and indirection with events. And I can’t make sense of it. DAVID:  Right. REBECCA:  And one of the things we have to do as developers is make sense of a lot of complex things. And patterns are there for a purpose but when it makes it harder to make sense and write correct code to do responding to changes of a state or whatever, then you got to look for simplifications. DAVID:  Exactly. AVDI:  I have to thank you for jogging my brain, because one of my favorite parts of the book was where you went through a design process and I’m not going to go into the application. But basically, you started out by applying the state machine pattern. And the state machine pattern’s one of my favorite patterns. And I’ve used it a bunch. And I was like, “Yeah, that totally makes sense.” And then you thought about it a bit more and came up with a completely different design that made a lot more sense. [Chuckles] REBECCA:  So, we were also at the same implementing that. So, it wasn’t like it was only a CRC card design. And implementing it in several different languages at the time. Because when we started out doing this we thought, “You know, state pattern sounds pretty cool here,” I’m going to say. And then we said, “You know, this is not so cool.” [Laughs] And you have to throw it away and rethink things to make it more… AVDI:  It seemed like in that case, the state machine pattern put all of the focus on I guess the control flow. REBECCA:  Right. AVDI:  But what it didn’t do is it didn’t put the focus on the actual domain concepts that were at work. Those were just mixed in to the control flow. REBECCA:  Yes. And oftentimes when you see, Martin Fowler in their Enterprise book talks about anyway, the patterns of anemic domain model. Yeah, thinking about control flow can lead you to that. And it’s startling to me actually, when I add just the right amount of behavior to domain concepts, that it just becomes a lot easier, a lot simpler. DAVID:  Can I provoke you into discoursing a little bit more on that? The state machine pattern. I love the state machine pattern. But the problem that I see that it runs into all the time is that it encapsulates nothing. [Laughter] DAVID:  If you implement a state machine, I’ve never seen a state machine implemented that every client of the state machine did not know all of the states in the state machine. Does that make sense? And I wonder if control flow, does it help address that? Can I tease you into talking about the tr-… Because everyone, we see the state machine and we go, “Oh, that makes sense.” And we don’t explore it enough to see what tradeoffs are there. What other tradeoffs do you see there? And how does looking at the control help that? REBECCA:  Well, in some sense I think that reacting to state is a natural think for something that has control responsibilities to do. Reacting to requests and changing state is really what we’re talking about here. And in that case, knowing how to transition from one state to another and what to do becomes a very much on the actions and the post state transitions. And that’s your whole world when you think that way. But you should also consider that sometimes that might not be the right way to frame what you’re doing. I don’t have anything against the state pattern per se. but in this case of the design that we were talking about in our book, it was leading us to this control as the most fundamental element of our design instead of looking at ways where we could use polymorphism to not just change state and get the next state but to actually do the work of the application. And so, if I view everything as a control problem then I’m… the state pattern to manipulate those levers is probably a good thing. AVDI:  I want to jump up a level of abstraction. REBECCA:  Okay. AVDI:  And say this kind of design thinking is clearly very helpful and probably more helpful the larger the project. In this current modern world of largely very agile processes and very code-centric processes, even the user stories are code and stuff like that, where do we fit design thinking into the process of making software? REBECCA:  I think you fit it in wherever you can. For example, if I’m trying to think about how to implement a story, there’s nothing that says that I don’t’ want to develop a set of objects that interact together and to think about those a little bit. As I’m writing tests, I can be thinking about design. If I’m creating some new capability in my system, I may want to take a little bit of noodling time to think about design choices or how I’m really going to use this particular piece of technology or should I have this kind of common way of doing things. So, it’s opportunistic I guess I’d say. AVDI:  Are there red flags where you say, “Oh that’s a sign that I should probably step back and do some noodling”? REBECCA:  Well, oftentimes I get called in as a consultant or something to look at design in code when things are in trouble. So, the red flags are all over the place usually when I see it. But when I see that there isn’t any consistency and that’s really slowing people down, then that becomes an issue. When I see that we don’t have a standard way of solving a problem and everyone’s going five different directions and that’s causing us to have inconsistencies or increasing risk of not performing at a certain way, then those are also red flags for me. It’s when you see that what you’d been doing isn’t going to be sustainable. And so, maybe some people have this tolerance for, “Oh this is just the way things are.” But when I see that things start slowing down or getting complicated, then I want to stop and step in. AVDI:  Can you expand on consistency a little bit? Because I found that a really interesting theme in the book. REBECCA:  Consistency is everything in my mind, from the sense of knowing if I’m going to implement let’s say and actually have a rich domain model where I have objects behave. It’s consistency in how I check constraints in objects, or it’s consistency in how I implement a service layer and the general responses and the general interfaces that I design to services. It goes across almost anything I’m thinking. It’s, how do I report errors, how do I recover and handle an exception? Those kinds of things are, design consistency is, I don’t know, a hallmark of I guess I’d say a mature team. I need to know when I want to break the rules. But the more I can be consistently doing things in the same way, the better it is for anybody to walk into someone else’s code and know what’s going on. JAMES:  There’s actually a great list in the book that says, she gives the points of a consistent, comprehensible design. And they are, objects are grouped into neighborhoods, and we should talk more about that because that’s one of my favorite parts of the book. There are a few lines of communication between neighborhoods. No one object does or controls too much. Objects perform according to their designated role. When one solution is designed, variants will be applied to other parts that are similar. And there are few patterns of collaboration that repeat throughout the design. I thought that was a cool summary of consistency. AVDI:  One of the things that I enjoyed or found interesting is the idea that it seemed like you were advancing the idea that if you solve a particular problem one way in your codebase and then you come upon another problem which is similar but  a little different, it’s better to solve it in a consistent way with the last problem than to be like, “Oh, I’ve come up with a brand new way to solve this problem which is better than the way that it was solved in this other place in the codebase.” REBECCA:  Yeah. And there’s always this tension of, “I discovered a new way and it’s better. Do I go back and refactor?” Ward Cunningham again would say, “Yeah, you probably should,” because technical debt is when you don’t reflect what you’ve learned, new learnings, into your existing code. And that’s a great ideal if you get to noodle around and tinker around. But a lot of people I know don’t get that luxury to do that. They’re just always, maybe they need to take that time to go back and clean things up. But if I discovered something that’s really a new, better, significantly better approach, then I might go for it. But if it’s just a little, subtle difference, probably not. So, that notion of consistency in and of myself, I tend to be someone who goes back and cleans up stuff that I learned. But I think that takes a little bit of discipline. JAMES:   Whereas if everything in the system, if you pretend like you’re starting with a blank slate every time, then when you design three different parts of the system, you’re doing to do it in three totally different ways instead of trying to be consistent with each other. And then as somebody’s reading that code later, potentially you, then you get your handle of one of the three and you’re like, “Oh, good. I’m starting to understand how this works,” and then you step into a different part of the system and it’s like, “Wait. The rules have totally changed. What’s going on?” REBECCA:  Well, so yeah. Have you ever heard of the Windsor House or whatever, that it had 97 rooms and some mad person… DAVID:  Oh, yeah. REBECCA:  Yeah. Right, okay. So, designs where you’re gratuitously different just because remind me of that. And it requires you to get in there and go, “Oh, okay. This is what they’re doing.” And so, if we’re trying to be agile about it, collective code ownership and actually pairing and doing things where I’m actually not just dwelling in one place, developing a consistent style should be easier if we have this trust and this belief that that’s an important value. But I also hate it when someone goes in and in the name of consistency goes and, “Oh I’ve got the better way,” and then they go back and hack over my code so that I don’t quite understand it as much. AVDI:  [Laughs] REBECCA:  But maybe I should stop thinking about it being my code as opposed to the system’s code. Maybe that’s what I should be doing. DAVID:  As long as the person who hacked over your code was also thinking it was the system’s code, I think that’s a fair [inaudible]. JAMES:  [Laughs] REBECCA:  Yeah, exactly. AVDI:  [Laughs] REBECCA:  And I know that I collaborate with someone who does that. And we’ve had discussions about that. And you have to have this sense of trust. And that’s what collaboration with your fellow developers and designers should be all about anyway. DAVID:  Rebecca, you said a few minutes ago when you sensed things slowing down, then you step in to clarify the metaphor. That’s a statement that I understand intuitively and I react to it implicitly. And then I realized this is a really good question to talk about. Can you get a little granular? How do you quantify things slowing down? What are the symptoms that you feel or that you notice when you’re running into this kind of pain? Well, I won’t give it away, but one example is there are three ways to solve the problem and you solved it one way today, you solved it a different way six months ago, and you solved it a completely different way two years ago and all three ways are still in the codebase. REBECCA:  Well, when I see something like that, there may be reasons for having made those conscious leaps not to go in to something, to not go back and retrofit. I was writing some patterns, I think it was a year ago or maybe it was two years ago, with Joe Yoder. We were talking about patterns for sustaining muddy architectures. DAVID:  [Chuckles] REBECCA:  And there’s always this tension between going back and retrofitting or coming up with a new better way. And if it’s significantly better, I would go with that. On the other hand, there is a sunk cost to deciding to leave things the way they are and when we have to go back and actually work on code that was in this other style. And I think a lot of Java frameworks are in this category. Tell me if Ruby ones are in that same vein as well. Anyway, it can make it really hard to make what you think is something like an easy fix that you go across let’s say a number of stories when they’re cutting across different technologies. And what you thought had been easy takes a lot longer, then those kinds of indicators really say, “Oh, okay. Do we really want to have three different ways of doing this thing?” DAVID:  Right. CHUCK:  Isn’t there a risk tradeoff though? If it’s already working… REBECCA:  Exactly, sure. CHUCK:  Then you go in and change it. I mean, if you have unit tests and stuff around it, maybe some integration tests that call from the top and make sure that it all behaves properly then there’s less risk. But you’re making a tradeoff. You’re taking the risk that you might break it as opposed to just having it continue to work, especially if you’re never going to have to touch it again. REBECCA:  Right. So, I’m not a design purist that says everything has to be consistent. I recognize that we live in this sloppy, haphazard world sometimes. But I want to make sense of what is impeding me going as fast as I can, given the choices I’ve made. And so, in some sense we tend to not invest in, I’m going to say reducing technical debt until it becomes really a bad thing. JAMES:  Until it becomes back-breaking, right? DAVID:  Yeah. REBECCA:  Yeah. And I used to, in the day, and this is what I think, why Ward says you don’t reflect what you’ve learned. I used to, in the day when I was doing coding all the time, before every iteration, this was back before we had, calling it agile, would go and do my cleanup, more major cleanups that I learned about, just setting the stage before I could do any predicting of what I would do. So, that was one way to sneak in that not a daily noodling but a way of cleaning the decks if you will, so I could go forward. But yeah, I think we need to, it’s always a set of tradeoffs. And I don’t know. People tend to, I won’t say accept mediocrity, but they accept more pain than they should. [Chuckles] CHUCK:  I really like the idea though of just removing the roadblocks. So, if it is code that you’re likely or you know you will be touching again, then yeah. Go refactor it while you have all of the information still clear in your head so you don’t have to go figure out, what did I do three months ago when I refactored this code? But if it’s not clear that it’s going to clear a roadblock for you down the road, then there may not be any value in going to change it. REBECCA:  Right. Well, so I don’t know if you’ve heard the term, and you probably have, called a Fed-Ex day, which is a practice some agile teams do where we do a day to innovate. I think we need, I don’t know, what the moral equivalent of a debt reduction, things that I can do. JAMES:  [Chuckles] REBECCA:  And maybe it isn’t a day, because maybe it might take a couple or three days to figure it out. But we probably need to have a moral equivalent of that from time to time. And an opportune time is right after I have released stuff. Because, at least for me, I like to clean. Every developer I’ve ever worked with, we have this list of things that we’d like to fix up at the end and we never get to them. Well, let’s pick some that we like as a group and I don’t know, maybe we’ll call that instead of a Fed-Ex day it’s more like a weed whacking day. AVDI:  [Laughs] DAVID:  Neighborhood cleanup, yeah. REBECCA:  Yeah. Right. CHUCK:  I hate yard work. JAMES:  [Chuckles] CHUCK:  Fed-Ex day, that’s my thing. REBECCA:  Okay. Well no, so we don’t like… You’re right, you hate yard work. You need a better name. Well, don’t you like to, let’s see, I don’t know. It’s a cleanup. CHUCK:  Yeah. REBECCA:  It’s like making things shiny again. Maybe it’s polishing. I don’t know. That’s probably a bad word. JAMES:  So, I want to go back to this concept of object neighborhoods if we could, because this was something I really got out of this book. You talk about how in a system, it’s not just, I think we tend to envision or at least I guess I should say I tend to envision just these set of objects and there’s this spider web of communication between them or whatever. But that’s not really the structure of most systems. It’s actually that systems are composed of these subsystems. And these few objects that are parts of these subsystems, they’re the ones that talk to each other. So, if you have a travel application for example, because that’s what I’m working on recently, you have a system that’s concerned with nodes, stations, places people travel from. And then you have a system that probably is concerned with path finding. So, how will I get you from this node to this node? And then you have probably a pretty unrelated system that’s concerned with, “How do I sell you a ticket?” or things like that. So, the objects organize themselves naturally into these neighborhoods, these groups. And you talk a lot in the book about this concept, this organization, and inter-object communication and how objects communicate a lot in the neighborhoods but then not as much from neighborhood to neighborhood. That’s more like, I envisioned it as almost an external API call even though it’s probably in the same process or whatever. REBECCA:  It could be, or it could be in a separate component or whatever. JAMES:  Sure. REBECCA:  Yeah, so this notion of neighborhoods was actually interesting when people from Japan wanted to translate our book into Japanese. The word object neighborhood was I think, “Well, there are four different meanings for neighborhood. Which one should we use?” JAMES:  Oh. DAVID:  [Chuckles] REBECCA:  And it’s actually interesting because they talked about, is it a business neighborhood? Is it something where people are living on a common street? And the answer was yeah, it was probably more towards that commerce of we’re working together on something. So, it’s a joint effort neighborhood, not just things that happen to be packaged together. And that was an interesting discussion. But I tend to think that unconsciously, when we’re structuring complex systems, we do have to break things down. And domain-driven design had the notion of domains. I’m not exactly sure that a neighborhood is equivalent to domain, but it could be. It could be some functionality that’s complex enough that there’s quite a few objects actually implementing it that’s really part of the same domain, but something that I would like to think of in isolation about how it does its job. And so, one of the things that having neighborhoods allows me to do is I might want to choose a different control style for that neighborhood. And certainly I want to care about the boundaries and borders of communications with that. And some of the other things that we touched on in the book were the notion of trust regions and patterns of communication between neighborhoods. If I’m crossing those boundaries, what do I do on the borders? JAMES:  Yeah, that’s a really good point. So, you design a more coarse grain for communications between the various neighborhoods much like you would do with systems. So, if you had an SOA architecture or something, service-oriented architecture, you design coarser grain APIs for those services to communicate back and forth instead of allowing them to touch all the internals of that [particular thing]. REBECCA:  Right, right. Back in the day, this actually doesn’t really have much to do with, I can say this applies to non-object technology as well. Anything where a distributed process, whether it was implemented in object technology or not, it’s the same thing. But in the early days, people thought that objects were chatty things and that I should be able to talk to any object. And that’s just wrong [chuckles] for so many reasons. JAMES:  Yes. REBECCA:  Performance being a significant one, but just the notion of the granularity of what I’m talking to and how I think about things. JAMES:  Right. I’ve actually been recently breaking up this large-ish system into two pieces, two systems that have separate concerns. So, one of the things there, since these systems will now be communicating with each other, you have a scenario where you’re in a tight loop and in this loop you’re doing something with each object. REBECCA:  [Chuckles] JAMES:  And then if I just split that apart at the seams, so then you’ll have a tight loop and in every iteration through the loop you’re going to be making an API call, well then that’s a totally different scenario. So instead, we change things to where before we even go into the loop we make one API call to get whatever we need. And then in the loop we use the pieces we need. REBECCA:  Yeah, so it’s more intelligent based on proximity, if you will. JAMES:  Right. AVDI:  When I was being introduced to object-oriented design, one of the emphases that I saw then was on this idea of modeling where you’re modeling the world. REBECCA:  [Chuckles] AVDI:  I feel like you have a very different approach in your book. And I really liked it. I wondered if you could talk about that a little bit. REBECCA:  Yeah. Back in the early days, we had to find reasons to sell objects to people. And some people said, for example, “Smalltalk, it’s an AI language.” And other people say, “Well, it’s so easy because objects are just representations of real world things.” And so, since we know what real world things are, then it’s easy to put them into our programs and we know what to do. The translation between the two is just seamless. And I’m going, “Baloney.” From my perspective, I am creating a set of objects. They may have some tangential connections to things in the real world, but oftentimes what I have to have them do in my system is quite different. So, if I’m representing vehicles, you were talking trips or whatever, I don’t do everything about them. I have the essential ingredients to make them behave the way they need to in my system. And so, I think this real world connection is indirect. There are domain concepts and we need to understand what to represent to make our application do what it needs to do. But it isn’t the same as just plucking objects from the real world and putting them into our design. AVDI:  You used the term invention a lot, which I love. You talked about inventing objects. REBECCA:  Well, so I think in order to represent a domain, if I want to have rich domain objects, I have to come up with clear terminology and concepts in how they’re going to behave. And oftentimes I find when I do that kind of system, that even people that are domain experts don’t have, well their terminology may be purposefully ambiguous. But in our programs, we have to be totally unambiguous. So, what do you mean here? So, I have to do inventions. I have to enforce this set of behaviors onto something and so I have to create concepts that are lacking. Or I have to add clarity. Domain-driven design talks about this a lot in capturing the ubiquitous language. But it’s not just capturing it. It’s trying to make sense out of it so that I can meaningfully do work of the system that way, add that level. So, that’s the goal, I think. It’s not to just replicate from the real world. So, a model is a simplification. And that’s what’s key. Anytime I’m building an abstraction it doesn’t do everything, it’s a purposeful simplification. AVDI:  When you are inventing these concepts or inventing new little objects to fill in the blanks or to make things specific and unambiguous, where do you draw your inspiration from? REBECCA:  Oh, goodness. Probably a lot of years of seeing a lot of code. [Laugher] REBECCA:  I don’t necessarily use the notion of a metaphor. That’s one of the XP practices that I find somewhat hard. I don’t come up with little, rarely do I come up with a metaphor that leads me to inventions. But oftentimes, inspiration comes from trying to think about probably role stereotypes helps me a lot. But also, thinking about lots of other code and systems that I’ve seen. So, reading a lot of code I guess. AVDI:  Yeah, I ask because in working with younger or less experienced programmers, I think one of the hardest things that, one of the hardest problems they run into is just when you step off the rails a little bit and need to… REBECCA:  Pardon the pun there. [Laughter] AVDI:  Yeah, I realized. That was pretty unintentional because this really doesn’t necessarily have anything to do with Rails. REBECCA:  I know. But, but… AVDI:  But yeah, it does push you to think of things. Rails has this set of, and that’s actually a good point, Rails has a set of invented concepts which can constrain your thinking. REBECCA:  They do, right. AVDI:  So, a controller, okay controller didn’t start with Rails. That obviously comes from much earlier. But a controller is an invented concept. That’s not a thing in the real world. REBECCA:  Right. AVDI:  But it’s certainly a thing in our programmed way of looking at the world. JAMES:  And the Rails idea of a controller I would say is even one step beyond the… REBECCA:  [Chuckles] JAMES:  MVC idea. DAVID:  Yeah. AVDI:  Well, yeah. Right, right, yeah. And so, that’s just one of the things that less experienced programmers have the hardest time with, is how do you come up with something to fill in that blank between, the spaces between the obvious domain objects and then the less obvious objects that need to be created? REBECCA:  Yeah. AVDI:  And I guess there’s really no [inaudible]. REBECCA:  Yeah. And so, if I have to do some work, so again I think back to service providers and various different role stereotypes, if I need to do some work, it’s becoming too complicated, I think about factoring something out into a domain-specific service provider as long as I can give it a name. So again, it’s having these little conceptual parts of your toolkit that allow you to try something out. Usually, when I come up with, if I’m designing very incrementally, a new concept it’s because I’m uncomfortable with my current implementation. So, something’s forcing me to step back and say, “Well, this is… so maybe I need a filter to get what’s relevant out of the stream before I then make these calls,” as you were talking about earlier, to API calls. Well, this notion of some kind of service that could do that for me, I don’t know whether you do that or not, is an invention that I would do that’s based on, what’s the fundamental thing I need to do here? And you just get more comfortable with that over time. But I agree. It seems like magic. AVDI:  [Laughs]. REBECCA:  To people when they’re first programming. It’s like, I’d really rather see everything all in one place or know where to plug in, if you’re using an event-based set of frameworks. And when I have to step outside of that to do more work, I don’t know where to start. [Chuckles] JAMES:  So, this is kind of leading toward I think one of my big questions after reading the book, and that was, you go through and you talk about at each level how you’re thinking about design. And you’re weighing all these tradeoffs at various levels. And there are days when I wake up and I do things like this and it makes me feel great that I can think through all this stuff. And there are days when I’m considering all this or reading a book like yours and I think, “This is terrible. There are all these forces that are working against each other and I’m expected to know at any given moment which force is the more important force, and so I can ignore the other 30 so I can get something done.” And you have this quote in your book that really summed it up for me. And it was kind of depressing at the same time. REBECCA:  [Chuckles] JAMES:  It says, “The best strategy isn’t always obvious or satisfying. Compromises don’t always feel like reasonable solutions, even if they are the best you can do under the circumstances.” And so, that led me to think, how do we balance this eternal war of all these tradeoffs and all these design decisions? Obviously, you can’t follow them all at once. If I followed every rule of programming, then the only reasonable solution would be never type anything. REBECCA:  Right, right. It would be a very simple design, wouldn’t it? JAMES:  Right. [Laughter] REBECCA:  Well so, you were talking about this, even the best things seemed like compromises at the time. You brought back the pain that I had actually implementing this system where we were doing, it brings back the pain of actually solving that design recovery when we had state mismatches between systems and had to put things on problem queues. And it was just, oh it was awful. Anyway, and it seemed overly complicated. But then it was the best we could do because programmatically we couldn’t decide how to fix things when these systems that were trying to talk to each other were inconsistent. So, in some sense I think the goal isn’t to make every day hard. It’s all these things in your toolkit, or [inaudible] of shiny objects you could pull out when you need inspiration. And rather than be depressed about it, I view that a lot of concepts in responsibility-driven design or design patterns or things that we’ve talked about are tools I can apply right now to a problem that I have at hand. But I don’t get twisted up in a knot about, “I’ve got to get it right before I make progress.” This isn’t reality. I was inspired when we were writing our book to come up with a little storyline to introduce each chapter. And that turned into a theme and helped guide us as we were writing. But the one that I’m pulling out about responsibilities was, in that chapter, was a quote by Christopher Alexander who says, “Form is part of the world over which we have control and which we decide to shape while leaving the rest of the world as it is.” The measure of a design’s goodness is how well the form fits into its context. But I’m going to end by saying, “And we do the best we can.” JAMES:  I like that. DAVID:  Yeah. There’s a great quote by Alan Perlis who said, “One can’t proceed from the informal to the formal by formal means.” REBECCA:  [Laughs] You just have to fake it ‘til you make it? DAVID:  Yeah, yeah. There is space in this world for spikes and failure. And when you screw up, all you can do is stand up, throw your hands in the air, and go, “Tada!” and go find another way to do it. REBECCA:  Yeah. “Gee, I learned something.” DAVID:  Yeah. REBECCA:  Or, “Yeah, this is okay.” JAMES:  Sorry. I just wanted to add to her, “I learned something.” We started with, at the beginning, talking about these spikes and trying things and stuff. And then it seems we’ve almost circled back to that. And I will say that some of the smartest programmers that I know are heavy users of things like git-reset. REBECCA:  Whoa. JAMES:  So, they’ll just start coding and get to the point where they have that key insight and then git-reset because that’s it. They loaded the thing they needed into their brain. And the code was just a means to doing that. And then… REBECCA:  You’re sort of arguing that refactoring is not necessarily always the best way to clean up a design. Sometimes, you might want to start over. JAMES:  Yeah. I don’t even know if I was arguing specifically that. More like, so if I’m looking for a bug in a complex system, say, and I start digging in. If I don’t know what’s going on very much, I probably start looking in the wrong place. And then that leads me to drop a layer of abstraction or three. And then I finally end up in the right area and I’m toggling the right thing. And then I eventually understand what’s going on. Meanwhile, I may have changed various things along the way trying to get it all in my head. But then when I finally understand the bug and what it is, it may be actually a simple thing to undo it. And all my fiddling may be pointless. And at that point, I can git-reset because the knowledge is in my head. And I understand the bug at this point. And then I can go in and do this simple thing that’s actually needed. REBECCA:  Yeah, which is saying not getting too invested in your tweaks along your way. JAMES:  Right. Yeah, yeah, yeah. DAVID:  Yeah. It’s sketch code. AVDI:  Yeah, don’t fall into the sum cost fallacy. It’s like, “I spent all that time on that. I’m not going to throw it away.” DAVID:  Right. AVDI:  Here’s a little brain hack for not feeling so bad about it. If you can’t bring yourself to do a git-reset, just do a git-stash and then [never unstash]. [Chuckles] REBECCA:  Never unstash. [Laughter] CHUCK:  It’s still there if you need it. AVDI:  Yeah. It’s like the Recycle Bin. It’s still there if you need it. REBECCA:  Well, that’s one of the things when I wrote my first book, is that Brian and I, Wilkerson and I were talking about how do we keep track of the design decisions that we made to not do something a certain way? And that’s actually something we didn’t really come up with. And I don’t think I came up with that in this, the second book I wrote on object design as well. But maybe stash is a good thing to say, “Well this didn’t work out,” or, “Here’s why I did this.” We can do it that way, yeah. AVDI:  I want to talk a little bit more about the process of getting better at design. I finished a book recently that talked about the fact that practice doesn’t necessarily make perfect. You can actually practice something over and over and over again and do the same thing over and over again and not actually make any improvement. I’m curious if you have any insights on getting better at design as opposed to just making the same designs over and over. REBECCA:  Well, I think the one insight I have is that design solo without feedback is, for the rare individual you may improve, but learning from questions and comments of a concerned set of colleagues and peers is really a good way of getting better. And so, what that means though is you have to have this, I’m going to say cone of trust or area of trust and really do kick over things and just expose yourself to comment and critique. So, to me one of the best things that I can do to get better is to accept that I’m not always going to do things the best way. But I know that someone else will have an opinion. And so, I go seek those out. So, that helps. The other thing is I think getting better at design might involve being more conscious about the choices you make. And so, if I’m going along and say I’m doing TDD, it’s like, “Can I go through every 15 minutes and write down what kind of choice I made and where my path went?” just taking little notes. Those are useful things. JAMES:  I love that point you just made. And I think for me, pair programming helps here a lot. Because if I’m doing something kind of unusual or going against the grain, my pair will often say, “Hey, isn’t that weird? Shouldn’t we probably do something like this?” and then one of two things either happens. I either have an answer and like, “Oh yeah. I’m purposely ignoring that here because,” and I have this reason which then we can debate whether or not that makes sense. Or it’s right. They’ve shown me that I’m going off track and probably not taking the best approach or whatever. But I like that. Oftentimes, like just the other day, I designed a system where I have this structure of objects and they communicate with this remote thing at a couple of different levels. And one way I could have modified it is I could have modified about three different objects to, “Here’s the part where you connect to the remote. Here’s the part where you connect to the remote,” that kind of thing. But instead, I chose to pull out this remote thing into a separate concept. And you pass the, whatever, into that. And it correctly wires it up. And so, it probably wasn’t the most object-oriented kind of thing, but it let me keep all of the remote logic in this one place instead of spreading it out over these three places. REBECCA:  Right. JAMES:  And to me, that felt more correct. REBECCA:  Yeah, better design. And I would probably agree with you. And now I’m going to say, “And why isn’t that object-oriented?” because this was, if I think about an object should know what it needs to know and not any more, spreading it out into those three places maybe that’s overstepping their responsibilities. So yeah, I do things like that, too, whether it’s pairing or not. So, for example I’m just thinking of some Java code we were working on to build this reference application, my colleague and I. And I’m thinking about how to do error reporting back from our services and various different kinds of RESTful API. Anyway, a bunch of errors can happen. Many errors can happen. And so, rather than totally going and banging back all the error recovery reporting in one way, I just did it for one case, threw it out there, because we were not pairing. We were meeting up at various times because we had different schedules, and said, “Jim, let’s talk about this.” So, sometimes I do, I’ll say partial improvements that are out there for others to look at. And I accept that we’ll come to a better discussion after that. So, that’s an approach I use oftentimes. And it wasn’t sketch code. It did do more error handling reporting than we had been doing. But I didn’t go back and say, “Everything should be this way.” I just want your opinion before I go on. JAMES:  That’s really great, I think, just thinking through all of this stuff. It makes me want to go out and redouble my efforts to design great code. REBECCA:  Good. [Laughter] REBECCA:  And by the way, I’m going to say this kind of thinking just about how I’m structuring communications, how I’m handling what work is being done, can apply to things other than objects as well. I’m going to say for those functional folks out there, there’s nothing particularly object-oriented about some of the stuff that we’ve been talking about at the latter part of the game here. DAVID:  Yeah. JAMES:  [Bad] design applies everywhere. Good point. [Chuckles] REBECCA:  Well, some of those things like communications and visibility and the work being done, it’s pretty universal. DAVID:  Or talking with your coworkers? Yeah. [Laughter] DAVID:  That’s our idea, you functional people. You can’t have it. [Laughter] REBECCA:  I guess I’d say there’s this design thinking about, what are the tradeoffs that goes on whatever technique or mechanism I’m using? So, it’s good to have those kinds of conversations from time to time. JAMES:  Absolutely. AVDI:  So Rebecca, it noticed that it’s been about a decade. Do you have another book in the works? JAMES:  [Laughs] It’s time. REBECCA:  Well, probably two in the works. It’s time, yeah. It will be on object design. Yeah, I have a couple of things that I’ve been working on lately. And one is about agile architecture and practices around that. And another one has been collaborating with Joe Yoder. He and I write patterns together because we just enjoy working together. We’ve been lately coming up with a collection of patterns on being more agile about quality assurance and system quality. So, that likely could turn into a book. The thing that I’ve been thinking about lately is that books may not be the most effective way [laughs] to communicate and spread ideas. So, I think you need a website and a presence and a community around it. So, maybe books still are useful. But they’re probably not enough. JAMES:  That’s an interesting point. DAVID:  I just want to point out that even though your confidence in the medium is dropping, you have two books after ten years. So, your rate of output is increasing exponentially. [Laughter] REBECCA:  Ooh, yeah. No, it’s about once a decade. Or I could say, well one was in the last millennium. [Laughter] REBECCA:  They’re still selling, which is pretty amazing. AVDI:  Very cool. DAVID:  It’s your own fault for having good ideas. REBECCA:  I guess. [Laughter] CHUCK:  Alright. Well, sounds like we’re winding down. Is there anything else to cover before we go to the picks? JAMES:  I’ve done lots of hard thinking. Now I’m exhausted. REBECCA:  [Laughs] JAMES:  It’s nap time [chuckles]. CHUCK:  Well, we know what James’ picks are going to be. JAMES:  [Chuckles] CHUCK:  Alright, well let’s do the picks. Avdi, do you want to start us with picks? AVDI:  Sure. You know, I think I just have one pick this week. And it’s not technical. It’s a new show, a new Netflix show that I’ve gotten into. It is ‘Parts Unknown’, the latest Anthony Bourdain show. And it is amazing. Just started watching it recently. I hadn’t watched any of his stuff before. And it’s like, I guess it’s documentary. Well, it’s food oriented travel log I guess is the format. A lot of stuff about food but it’s not a cooking show. And it’s fascinating because it focuses on a lot of places that are out of the way, or hard to get to, or even extremely dangerous to get to. The one that I just watched was the one on the Congo. [Chuckles] AVDI:  And there’s a lot of really, there’s some really good commentary just on food and on people and on society and on history. I’m learning a lot and really enjoying it. So yeah, that’s my pick for this week, ‘Parts Unknown’. CHUCK:  Awesome. David, what are your picks? DAVID:  So, last week Avdi picked outdoors as a pick. [Laughter] DAVID:  And I went outside. AVDI:  I picked lilacs, okay? I was very specific. DAVID:  Yeah, but they are outdoors. In all fairness, they are outdoors. AVDI:  Generally speaking. DAVID:  I’ve been outdoors. Sir, I gave you the benefit of the doubt. And I got burned. [Laughter] CHUCK:  Literally. DAVID:  Literally. JAMES:  And now he’s picking 911 emergency services. Way to go, Avdi. DAVID:  I spent 6 hours in the sun with my bald head and no sunscreen. Now, I will admit errors. Mistakes were made. And I spent the better part of this week just… JAMES:  Dead. DAVID:  Dead, yeah, just napping and blistering and peeling. So, for those of us who may have overdone Avdi’s pick from last week, I would like to pick indoors. [Laughter] DAVID:  It’s where all the books are. It has Wi-Fi. Now, the careful listener will note that you can take a book outside, but not if it’s raining. JAMES:  [Chuckles] DAVID:  And you can go outside with Wi-Fi, sure. But not if you don’t have sunblock. So, indoors. It’s just easier. [Laughter] DAVID:  That’s my first pick. My second pick is really quickly, Matt Smith gave a talk at TEDxBellevue in December of 2012. And his talk was called ‘The Failure Bow’. And literally, he just talks about how when an acrobat does a stunt and then falls down and just completely fumbles it, they stand up and they throw their hands up in the air and they go, “Tada!” and they take a big bow and a big smile. And the crowd cheers. And he argues that whenever we make a blunder, when we make a big mistake, using this bow, this failure bow, changes our physiological response to failure. And it helps us be more transparent, available, but also it increases our ability to engage with the next problem very quickly. So, instead of, “Oh, I screwed that up or I said that wrong. I shouldn’t have done that,” you go, “Tada! Thank you for being here and helping me learn. And now I’m in a great positive state for moving on.” So, that’s my pick for this week, is ‘The Failure Bow’ by Matt Smith. CHUCK:  Awesome. James, what are your picks? JAMES:  So, I’ve got two this week. I have a really on topic pick this time, which is rare for me. But I read this great article because a coworker, Nathan, pointed out to me that Ilya Grigorik had been saying on Twitter everybody should read this article 12 times. And he said, that seems important. And so, he showed it to me and I read it. And Ilya’s pretty much dead right. Everybody should read this 12 times. It’s great. And it is, it’s a part of a book online called ‘Game Programming Patterns’. And don’t let that name throw you off. It actually has nothing to do with games, in my opinion. It’s about software architecture and these design decisions we make, and all the other juicy bits we’ve been discussing for over an hour now. And it’s really simple and concise and gets right to the heart of the matters and talks about why this is interesting and hard and what we’re trying to do. And it’s super great reading. Everybody should read this. The article’s called ‘Architecture, Performance, and Games’. Again, don’t let the games thing throw you. That’s not really what we’re talking about here. But I have not read the rest of the book. But I’m definitely intrigued now. The other thing that I would like to pick is ‘Avatar: The Last Airbender’. I have a small child. And so, she’s getting to the point where she likes to watch TV with us. And so, we’ve let her take a rotation in picking the shows. And so far, that’s been pretty hard on mommy and daddy as some of the shows have not been the best viewing for us. But she recently picked ‘Avatar: The Last Airbender’ to watch that. And wow, what an insane show. I think I’ve watched [inaudible] shows that aren’t that good. So, if you have young kids and you can talk them into watching it, it’s pretty good stuff. It’s on Amazon Prime now. So, if you have that, you can watch it for free. So, those are my two picks. CHUCK:  I actually had a listener to the show send me the full DVD set of ‘Avatar: The Last Airbender’ for my birthday and said, “You need to watch these.” JAMES:  Oh, that’s awesome. CHUCK:  So apparently, it is fan-approved. JAMES:  So, wait a minute. Listeners to the show are sending you gifts? What’s up with that? [Chuckles] CHUCK:  Oh, I pair with this particular listener on a regular basis. JAMES:  No, I’m just kidding. That’s so cool. CHUCK:  Anyway, so shout out to Federico. I’ll just put that out there. DAVID:  James, you mentioned that’s a snippet from a games book. And don’t be put off by title, but the reality is game programming is often some of the most intense, resource-intense programming you can do on a small system. And when I worked at a claim, we actually had a team motto that went something like this: “Programming video games isn’t all fun and games. Sometimes it’s just games.” [Laughter] CHUCK:  Alright. So, David mentioned it on the show and I’m just going to pick it because I like it. DAVID:  Indoors? [Laughs] Sorry. CHUCK:  Balsamiq mockups. It’s a really cool tool. The thing that I like about it is that it’s easy to use. You can export your stuff to PDF and you can make the different PDFs link to each other. And it doesn’t look like a real website, so there’s no confusion with my clients as to what it is. So, they don’t look at it and say, “Oh, you’re done.” And so, I really, really like that. That’s the only pick I really have this week. So Rebecca, what are your picks? REBECCA:  Yes, okay. I have two picks. One is by my friend Slim, or Seung Lim. And that site is called RealizingEmpathy.com. And I met Slim at an OOPSLA Splash Conference and he is an interesting guy. And he started this non-profit and he actually did a Kickstarter project where he ended up writing a book, we helped fund that a little bit because he was such an interesting guy, about realizing design empathy. And he was a computer science dude who mid-career went back and got his RISD design degree as well. Anyway, so his whole idea in this RealizingEmpathy.com is that design should be a conversation that doesn’t aim to fix or change or get people to do things. It aims to provide a space, he says, where we can empathize with all the participants involved and affected by the design process, and lets those effects emerge as side-effects. So, it’s not just usability, but how can I have empathy for the tools and the people and the systems I’m building. Anyway, it’s just a very, very cool site. And his book is pretty awesome as well. So, the other pick I have is Edge.org. And I’m going to say that I like to noodle with big questions and people’s opinions. And Edge.org is an interesting place because it essentially gets a set of intelligent, thoughtful people. And very year, there’s a question that they wrestle with but then there’s ongoing discussions between people that are scientists, psychologists, computer geeks, whatever. And this year’s question was what scientific idea is ready for retirement? [Laughter] REBECCA:  And that’s actually pretty interesting reading, because we’re talking about various different ideas that we hold dear. That was just cool. Anyway, so that’s Edge.org. And you can get lost there, reading. It’s a lot of fun. CHUCK:  Very cool. Well, thanks for coming on the show. We really appreciate it. And we appreciate you taking the time to not only talk to us but to write this book. DAVID:  Yes, thank you. REBECCA:  Hey, maybe I’ll do another one someday. [Laughter] JAMES:  Alright. See you in 10 years. [Laughter] REBECCA:  No, it’s about times up. JAMES:  That’s right. DAVID:  Yeah. REBECCA:  Okay. Alright. JAMES:  We should probably mention our next book, Chuck. CHUCK:  We should. Our next upcoming book is ‘Refactoring: Ruby’ and that’s just the regular Addison-Wesley with the red swirly covers that they have. AVDI:  ‘Refactoring: Ruby Edition’ CHUCK:  Ruby edition. We’ll have a link in the show notes. It’s by Jay Fields, Shane Harvie, and Martin Fowler. The foreword is Kent Beck, I think. Or it says, with Kent Beck, whatever that means. And then if you want to do the extra homework, then there’s a ‘Refactoring in Ruby’ book by Bill Wake and Kevin Rutherford. And that one has spaghetti on the cover. So, officially we’re doing ‘Refactoring: Ruby’ but you get extra credit if you do the other book. JAMES:  [Chuckles] I love it. Plus, spaghetti. So, you know. AVDI:  Mm, spaghetti. CHUCK:  Spaghetti code with meatballs.[This episode is sponsored by Codeship. Codeship is a hosted continuous deployment service that just works. Set up continuous integration in a few steps and automatically deploy when all your tests have passed. Codeship has great support for a lot of languages and test frameworks. It integrates with GitHub and Bitbucket and lets you deploy cloud services like Heroku, AWS, Nodejitsu, Google App Engine, or your own servers. Start with their free plan. Setup only takes three minutes. Codeship, continuous deployment made simple.]**[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.