02:26 – Will Read Introduction
03:11 – Extreme Programming (XP) & Development Practices
05:00 – Manifesto for Agile Software Development
07:22 – Project Management Practices
09:07 – Purpose and Attractiveness of XP
17:56 – Pair Programming (Particular Practices)
21:09 – Team Structure
23:54 – Remote Pair Programming
29:22 – Hiring People for XP
30:56 – Sustainable Pace
37:27 – Design
43:11 – QA (Quality Assurance) Teams
45:55 – When XP is a bad thing
47:46 – Team Size
51:21 – Tools
52:50 – Physical Workstations
56:44 – Resources
Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson! We will be recording with Elisabeth on June 19th, 2013 and the episode will air on June 26th.
ActiveRecord with Ernie Miller
AVDI: We’re talking about Windows XP today, right?
CHUCK: Yeah.
JAMES: That’s it. Windows XP. [Chuckles]
WILL: Yeah. That’s why we’re using Skype.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]
[This podcast is sponsored by New Relic. To track and optimize your application performance, go to RubyRogues.com/NewRelic.]
[This show is sponsored by Heroku Postgres. They’re the largest provider of Postgres databases in the world and provide the ability for you to fork and follow your database, just like your code. There’s easy sharing through data clips or just for your data. And to date, they have never lost a byte of data. So, go and sign up at Postgres.Heroku.com.]
[This episode is sponsored by JetBrains, makers of RubyMine. If you like having an IDE that provides great inline debugging tools, built-in version control, and intelligent code insight and refactorings, check out RubyMine by going to jetBrains.com/Ruby.]
CHUCK: Hey everybody and welcome to Ruby Rogues Episode 109. Before we get started, I just want to make sure that you know, many of you have complained that we don’t have all of our episodes in the backlog. I am fixing that. About half of you have moved over to the original feed, but half of you are still stuck on Feed Burner. I’m going to turn off the Feed Burner feed after this episode is released. It should redirect you to the new feed. But if you don’t get any episodes after that, keep that in mind and please re-subscribe in iTunes. That’s my big announcement.
JAMES: We’re going away?
CHUCK: Well. then I can turn it on so that people can get all of the back episodes, which is something that a lot of people have been asking for.
JAMES: Woohoo!
CHUCK: Yay! I fixed it. Just as a side note, the same problem just barely happened to JavaScript Jabber. So, I’m going to be fixing them, too. Anyway, let’s get the show started. This week on our panel, we have Avdi Grimm.
AVDI: Hello, hello.
CHUCK: We have Josh Susser.
JOSH: Hey, good morning everyone from sunny and cheerful San Francisco.
CHUCK: James Edward Gray.
JAMES: I am still included in our RSS feed.
CHUCK: I’m Charles Max Wood from DevChat.TV and we have a special guest this week. That is Will Read.
WILL: Good morning.
CHUCK: Did I say your name right?
WILL: You did. You got it.
CHUCK: Awesome.
WILL: Eight letters.
CHUCK: So, do you want to introduce yourself for the folks who aren’t familiar with you?
WILL: Sure. I am a Pivot, which means I work at Pivotal Labs, one of, I guess, several shops across the country or globe that are strong practitioners of extreme programming. And I actually worked, overlapped with Josh Susser for a while, back when he was a Pivot.
CHUCK: Nice.
JOSH: But you don’t hold that against me.
[Laughter]
JAMES: Hey, he still came on the show.
WILL: That’s a part of the code.
[Laughter]
JOSH: Yeah. So, we had been talking for a little bit about wanting to do a show on XP and I said, “Hey, those Pivots are pretty good at that. So, let’s get someone from Pivotal on here to talk about the Pivotal style XP.
JAMES: So, Josh won’t ask because he’s an ex-Pivot and I have to do his job for him, but can we define XP?
WILL: Yeah, let’s do that. So, I pulled up what Wikipedia’s got.
CHUCK: It’s a version of Windows, right?
WILL: It’s definitely a version of Windows.
AVDI: Last good version of Windows, right?
CHUCK: [Chuckles] I’ve heard that.
WILL: Short for Extreme Programming where it’s a methodology built on top of the agile values. So, the practices that value frequent releases, Pair Programming usually goes hand in hand with it, Test-Driven Development, and a lot of other developer-focused practices.
JOSH: Where was XP first defined?
WILL: Where was it?
JOSH: Yeah, was that Kent’s book? Kent Beck, his ‘Extreme Programming Explained’?
WILL: Definitely is the definitive resource, right? I don’t know much about its inception, who was doing it first, what it was born out of and those kinds of things.
JOSH: Well, I think that both Kent Beck and Rob Mee were instrumental in defining it.
WILL: Definitely.
JOSH: For those playing along at home, Rob Mee is the founder of Pivotal Labs.
WILL: Yeah, and it works super well for the consulting environment in a place where you’re able to bill on time and materials instead of a fixed bid, here’s the end result, because it’s so feedback-based. I think one of the things that XP’s great at is being able to understand what the customer wants and evolve that definition as work is getting done. Maybe you wanted X when you came in, but it turns out this Y thing over here allows you to pivot. One of the interesting terms that fits well into our name. You may never end up building that thing that was originally scoped, which is good for the customer, good for the user.
JOSH: Okay. So, maybe we should start with the Manifesto for Agile Software Development.
JAMES: Yeah. We’ve talked about it a little bit in the past, but it’s probably good to circle back.
JOSH: So, extreme programming, Will, you just said this. It came out of the Agile Manifesto principles. Extreme programming is practices that embody the principles in the Agile Manifesto. The Agile Manifesto doesn’t really have anything about how to do it. It’s all about the principles. So, that’s individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. I always looked at the Agile Manifesto and looked at it and said that this is all a reaction to not having powers of foresight. If software development managers were psychic and can foresee the future, we wouldn’t need agile or XP.
JAMES: That’s a good point.
WILL: You don’t need to write software, right? We just go bet on a baseball game and win.
JAMES: [Laughter]
JOSH: They have betting on baseball? You could bet on baseball now?
[Laughter]
CHUCK: Go to Vegas, you can bet on anything.
JOSH: Oh, okay.
JAMES: So, I think another way maybe to describe it is the Agile Manifesto lays out this strategy and then XP is a set of tactics to aim for that strategy.
WILL: It’s kind of like that analogy.
JAMES: Should we talk about the specific tactics? What are they?
WILL: Sure. I mentioned Pair Programming being one of them, right?
JOSH: Wait. So, the thing about XP that I think is worth clarifying is there are a whole bunch of things that people call agile and XP is the classic set of practices around doing agile. But there are some other things that people call agile that aren’t quite XP. What is that, scrum, yeah.
WILL: Kanban is another flavor of agile.
JOSH: I don’t know if we want to talk about the differences between XP and those things now, or if we just want to mention there are some and leave it to people to check out on their own, or if we come back to it later.
JAMES: Circle back after we figure out what’s in XP.
JOSH: So, XP has two big components. There’s the development practices and then there’s the project management practices.
WILL: Sure, yeah. None of the development practices, Pair Programming, Test-Driven Development, Continuous Integration, Frequent Deploys kind of thing.
JAMES: We don’t believe in any of that.
WILL: No. I’ve never heard anybody talk about those kinds of things as good or valuable. And then, I don’t know, what would you put into the project management stuff, Josh? I’m only thinking of the Iteration Planning meetings, for example. It’s still very light on that side.
JOSH: And Retrospectives.
WILL: Okay. Sure, yep.
JOSH: Stand-ups. Arguably, that’s part of the development practice, but I think it’s more like keeping a hold of the project.
WILL: Yeah. And I think it’s interesting not to — we said we were going to set this aside, but Scrum I think is kind of the opposite where it is heavy on the project management side and very light on developer practices.
JOSH: Well, very light to the extent of zero. I don’t believe there are any developer practices in Scrum.
WILL: I guess it depends on where you put some of those Retros and Stand-ups, but yeah, exactly. I think a lot of times, you’ll see companies try to marry the two together. SalesForce is actually an interesting example of this where they’ve branded their own flavor of agile implementation that is exactly that, a hybrid of Scrum and XP. I forgot what they called it, but this is what they do across their hundreds of developers or even thousands at this point. So, if that’s the kind of thing that you feel like your organization needs, it’s certainly worth checking out and asking some questions.
JAMES: Will, you had something great to say about this in the pre-show, but I’m looking at this list – Pair Programming, Test-Driven Development, Continuous Integration, Retrospectives, Stand-ups. These all have one thing in common. What’s that thing?
WILL: It’s the feedback, right? Pair Programming, you can think of as a very short loop code review cycle. Same thing for Retrospectives, right? You’re doing this regular team feedback loop. Stand-ups in the morning are kind of a daily what’s going on in the project and what do we need help on feedback loop. Every single piece is built around how do we get better? How do we surface what’s going on and then do something about it? Take action. Keep moving on all this stuff.
CHUCK: So, one thing that I’ve heard about all of these different practices is that any one of them can pay off. So, Pair Programming has its benefits, Test-Driven Development has its benefits, Continuous Integration has its benefits. But taken as a whole, all of these practices — and this is just what I’ve heard because I’ve never actually worked in a shop that did XP, but all of the XP-ers that I’ve talked to — that sounded bad.
[Laughter]
CHUCK: Anyway, they all basically say that all of these practices help, but taken together, they all reinforce each other too.
WILL: Yeah, I think that’s absolutely true. The case I like to make is around Test-Driven Development, which again is a fairly straightforward cell to a lot of developers where everyone says, “Oh yeah, we need to write tests and I start to see the value of writing them upfront.” But then, when you roll that in with Pair Programming, now I’m not just talking to you about code, but I’m also creating this code representation of that conversation as well, where I might say, “Hello,” to you in the morning and you say, “Good morning, Will.” It’s the same thing with tests and actual code where you write the test first as that greeting and then the actual implementation is the response back.
CHUCK: Yeah, I really like that.
JAMES: This kind of grew out of reaction to more waterfall-centric practices where the habit was to go long periods of time with no feedback. That’s the problem. If you can’t get feedback, you can’t course correct. The tighter you make that feedback loop, the sooner you can see a problem and start steering the ship.
JOSH: I think that, this is all philosophizing in my part, sorry about that in advance. But I think that the time when XP developed was an interesting time in software development. We were going through a transition from, the world was owned by, I guess, COBOL and C up until that point. And the development tools that were evolving at that time, like Smalltalk, there were some really cool Lisp environments and other technological advancements, meant the practice of developing software was changing fundamentally, how people operated. Over a course of a couple of decades, people went from writing machine code in assembly by hand and feeding it in on punch cards to, “Oh, we’re developing Smalltalk in this graphical user interface that has a lot of really powerful incremental development tools.” And the whole nature of development changed. I think that rippled through all of the processes in what people were capable of. It used to be that getting changes implemented in software took so much effort that it wasn’t the — like all rest of the project planning and all that, I don’t think had to work as hard to keep up with that part of the process.
WILL: So Josh, can I ask you, let me extend that thought and ask you a question. Would it have been impossible to arrive at XP if the tools hadn’t evolved?
JOSH: Oh, I think so. I think that if we were still in the day where your Product Manager comes to you and says, “Okay, we need to add a salutation field to the user so that we can call them Sir or Madam as appropriate,” that might have taken three weeks to implement in some ancient programming system. And if it takes that long to implement a little change, I think all of the tight feedback loop stuff in extreme programming would be a non-starter because there is no possibility of having a tight feedback loop.
JAMES: I was just going to say I think maybe one of the reasons we’re so attracted to this kind of stuff in Ruby on Rails is that it fits. Rails is almost a reaction against the heavy process of building web apps in the past. So, they’ve streamlined it as much as they can and thrown away all the stuff we don’t think we need or at least we don’t need to worry about right now, so that we can move at a faster pace and get to a prototype quicker and get to working software quicker. Then agile makes all that more attractive. If we can move to those steps and have a feedback loop so we can steer as we go, then all of that just has this great synergy. I imagine that’s why our community more than a lot of others I see, is so focused on things like TDD and Pair Programming and stuff like that.
WILL: Yeah, I think that’s absolutely right. Maybe the anecdotal evidence that I have is looking at the diversity of projects that we have at Pivotal go from web apps, which is our core Rails offering. But then we’ve also got mobile apps, which is deployed software and very close to shrink wrap if you will, and the feedback loop there is a little bit bigger. There’s an interesting level of pain that comes with that when Pivots kind of shift from going from web development to mobile, or even to some of our more dev ops heavy kinds of stuff, where right now, you’re setting up VMs and you’ve got to get hundreds of them working to have a fully deployed environment and that feedback loop is not seconds like it would be for you to test. It’s now minutes or even hours or potentially days, depending on what the scale is or what’s trying to be accomplished. The longer that loop gets, the louder the pain goes with it.
CHUCK: One other thing that strikes me with a lot of this is I’m still looking at the manifesto. And a lot of other technical industries, they really do teach their managers to focus on the things that are on the right side of the manifesto, the processes and tools, the comprehensive documentation, the contract negotiation, and following a plan. And the reason is because if they can streamline their process, if they can make their tools better, if they can document the entire thing and understand it, then they can really save money. And with software, it’s totally different because there’s no process. There’s a process for building software, but I’m not cranking out 10 million forums. I’m not sitting down and making the same thing over and over again. Everything is custom based on what my customer needs. So, in that sense, even if I’m doing an application that’s similar to another application that I’ve already built, there are going to be things that are different and that’s why we need all of the things on the left. All of those things require the feedback that we’re talking about with XP.
JAMES: Yeah. I’d just add to that that I think, I’ve worked on over 60 shipping Rails applications now. And in that time, the horrible projects I’ve been involved with are the ones that had no constraints. It’s a great thing to have to be forced to some kind of time loop where not even the, you have to have everything done by this date, but you have to have something done by this date. Because it really forces you to sit down and say, “This can wait. This isn’t that critical,” or whatever. And as you get that software live quicker, you get feedback from the people actually using the software. And that turns out to be the most valuable thing at all. I don’t know how many times I’ve spent ridiculous amounts of effort on a feature that I could tell eight people were using. It’s pointless.
JOSH: Okay. So, we could talk more about particular practices. There are a couple of other things. Will, you wanted to talk about what it’s good and bad for. I think you talked about this a little bit. But you also wanted to talk about specific situations.
AVDI: I’m going to ask a question about specific practices. We know there’s been a lot of piecemeal adoption of the various XP practices across the industry. I’m curious if there are any particular practices that you’ve seen have fallen by the wayside, that haven’t been adopted as much and maybe should be.
JOSH: This is the ‘XP a la carte’ approach. [Chuckles]
AVDI: Yeah.
CHUCK: I’ve heard the same term for scrum. It’s called ‘scrum, but’. And in honor Dave, I want to coin ‘extreme, but’.
[Laughter]
JOSH: Okay, folks. You heard it here first.
WILL: That’s right. Just to give out one of the things that we do at Pivotal Labs is we pair with the clients that come in. So, we try to teach them our practices so that they carry this forward and reduce the risk of creating software. Because I think in addition to the feedback loop, what ultimately happens, the reason that companies are attracted to these kinds of methodologies is that it takes software out of the risk factor. Or at least identifies what pieces of the software are going to be risky as opposed to, “Well, there’s this nebula of software thing that we sent off to the team and they’re going to get back to us in a year and hopefully, they’ll be able to do what we want.” It’s much more quantifiable. So, I think that’s why they come to us. They work with us and then we try to set them loose with those same practices and they’ll usually take Stand-ups with them when they leave without too much of an issue, which are just these short meetings for those that don’t know any of them. Usually in the morning when you first come in and a little bit of a status, a little bit of what I’m blocked on, or sometimes it’s general information like, “Hey, we added this cool helper class that’s really going to help you guys be more productive later on the day.” They’ll usually take Continuous Integrations as some sort of build monitor that is watching the test run on some non-developer environment over and over again. But a thing like pairing, I think, is the quickest one to drop off. I think that one, for me, has a lot of value as an individual. But I think what’s interesting about it is not every developer out there wants to pair, is not psychologically set up for it. Not that that’s a necessarily good or bad thing, but that if you want to have Pair Programming happening in your shop, you’ve got to hire for it because it’s just a different skill set. It’s not the same person that wants their headphones on and to be working in a nice closed cubicle or whatever. It’s soft skills like in Pair Programming to writing code for eight hours a day plus being at a cocktail party the whole time because you’ve got to talk through what it is that you want and understand and listen to what the response is, to be a social participant there.
JOSH: Right, okay. Will, you’ve started to touch on a topic that I wanted us to get into a little bit more. So, maybe this is a good time to do it. This is actually related to what Sarah Mei was talking about in her keynote at Ruby Conf last year. What was that called — The Insufficiency of Good Design. She was talking about Conway’s Law, where the product of a team will closely follow the structure of the team. The great example is that a four-team project will produce a four-pass compiler.
JAMES: My favorite way to look at that is the statement that all teams are perfectly designed to get the results they’re getting right now.
JOSH: Yeah.
[Laughter]
JOSH: Okay. But there is a bunch of things about team structure that have a big effect on a team being able to implement XP practices.
WILL: Absolutely.
JOSH: Like you need the customer on site and involved. Things like that. Can we talk about, if we want to do extreme programming, what are the things that we need to do and not do in how we put our team together?
WILL: Right. The things that we look for, at Pivotal Labs that works out well, is having — we try to shoot for a customer PM, as you mentioned. A strong representative of what’s actually being built, someone who can be the advocate for that. Not to say that our own developers don’t get invested in what they’re building, but someone’s got to understand and represent the business value, if you will, about that product. Usually, that’s someone that is either conducting user testing themselves as things are going out, or they’re working with one of our own designers to make those happen. But they’re getting feedback both from their own company and from the people that they expect to be using this thing. So, I’d say that’s a big piece. Collocation certainly helps. I think this is largely accepted to be true for anything. But as you’re pairing and engaging throughout the day in this social interaction, that collocation is, I don’t want to say irreplaceable, but it’s tough to get the same value from any other technique. We have a handful of Pivots that are remote full time, and they’re definitely more than functional within the context of what we do. But it’s not the same fidelity as someone who’s sitting right next to you and you can read their body language and you can see that, “Hey, they’re struggling with this,” or, “I need to ask more questions,” because clearly, they’ve got a better understanding than I do of what we’re about to accomplish.
JAMES: Hang on there. I want to push back a tiny bit on that. I totally think you’re right. But I would say that as an industry, we’re trying to push past that. At least, that’s what I feel like I’m seeing. Remote pairing is getting crazy common. Avdi gave that talk and started #pairwithme and it seems to be very popular. I see people doing it all the time, trying to figure out what the right combination of tools is so that they can get a comfortable setup, even when they’re not in the same place. Then you’ve got companies like GitHub hiring more and more people and something like 50% of them are remote. And they pair on everything too, if I remember correctly. So, I think you’re right that it’s easier when you’re face to face, but I would say that that’s a problem we’re heavily invested in getting past and we are making some inroads to. Do you think?
WILL: Oh, yeah. I definitely agree. Just look at the tool chain that’s evolved for remote Pair Programming over the last three or four years that I’ve been at Pivotal. It used to be kind of Skype-ish. You could use screen sharing through OS X. That was sort of the state of the art. And now, there are web-based services that are one click to walk up to and they just work. I’m thinking about other stuff like MadEye that’s being developed through Google Hangout as an add-on and leveraging that stuff so that you’ve got someone’s face as part of the interaction as well, in addition to audio and the screen sharing and those kinds of things. Or C9, based off of the Cloud9 open source project where then it gets all written in Node, but it’s that real-time collaboration in a full-fledged IDE. So, as I type, you see what I’m typing and we can run tests and deploy all from that in the Cloud kind of thing, so in a shared environment that’s neither in my machine nor your machine.
AVDI: Yeah. There are a lot of people using Tmux and tools built on that as well, which the advantage there is the relatively low latency compared to screen sharing tools and stuff like that. And then, there’s Screenhero, which is pretty cool, too. I do want to say, I talk to people about this stuff every week on the Wide Teams podcast. And over and over, one story that I hear is that the situation described as ‘we have a few people who are remote’ is always the most problematic. Those are the teams that I hear the most issues with.
[Crosstalk]
CHUCK: As opposed to fully remote?
AVDI: Yeah. Once you talk about teams that are mostly distributed, maybe they have an office that a few people come into sometimes, or that are completely distributed. And I’ve talked to a lot of people who have been in both situations, they’ve started out at a place where it was a few people remote and then they moved on to a fully-distributed team. And once you’re in that sink or swim situation, you start to evolve, according to agile principles, you evolve and adapt. You use that feedback loop and you start to evolve techniques and strategies to make it work well.
JAMES: I think, doesn’t GitHub talk a lot about how, like I said, I think they’re somewhere around 50% remote or something like that. And they’ve talked about how if there’s any significant communication, then it has to go through their chat room or whatever. And that way that’s for, like if you’re having a conversation in the office then only you two can benefit from that. Whereas if it’s in the chat room, then all the remote people know what’s going on and stuff like that, too. And they have tons of infrastructure tools that are just designed around that, around communication.
JOSH: So, I guess how I would say what Avdi was getting at there is that you don’t want to have the remote people be second-class citizens and having a bunch of stuff happen face-to-face that they miss out on.
AVDI: Yeah. And it’s very, very difficult if you have a group that has been very focused on collocated work for a long time, not to make them second-class citizens. Try as you might, I think that’s a really difficult transition to make.
WILL: The other thing that we tend to do when we do have remote members of a team is we’ll bootstrap that relationship and have them come in for a week, two weeks, something where that face time can happen. And you can actually go out and have a beer with these people and then, now we’re going to go work remote. You’ve got that established rapport with that person. You kind of understand them a little bit better and know some of those ticks and things that you wouldn’t pick up otherwise.
JAMES: That’s a good point, actually. I think that’s a great way to go.
JOSH: And in fact, that’s part of the Pivotal process, is that’s a standard part to put in the conversation with the client is, “Okay, you want to be here for a week at the beginning of the project to get the rapport established and then we can get going.”
WILL: Yeah.
CHUCK: I’d really like to ask a question that harks back a little bit to what somebody already said and that is that you mentioned that if you want Pair Programming or XP to happen on your team, you have to hire for it. And we’ve talked a little bit about bringing people in-house and bootstrapping that. But how do you identify people that will work well in an XP environment?
JAMES: Pair with them the very first day.
WILL: Yeah. That really is what it is. That’s our interview process at Pivotal Labs, where we don’t have a conference room that we’re sticking people in and asking them the Google, Microsoft kind of questions. We said, “Please come sit with us for a morning and then an afternoon with another pair, and you’re going to peel something off the backlog and just work on it.” And there, the interview is largely about, “Can you get out of your own head? Can you talk about the problem that you see?” It may not even be in a language that you’re familiar with. We’ll interview on a Rails project and it may be a .NET developer that we’re working with. So, the language is not important to us. We think that’s something that can be taught. Because you’re going to pick up syntax just by sitting next to somebody without too much hassle if you’ve got the right attitude to learn. But can you be that sociable person that I want to sit next to for eight hours a day? The best way to test for that is have them sit next to you for eight hours a day, it turns out.
CHUCK: Nice.
JOSH: [Chuckles] Yeah, I like the way Rob Mee always put it. It’s like, “Would you hire an actor based on a conversation about how they felt they performed in their last role?” [Laughter]
JAMES: Yes.
CHUCK: Oh, that happens way more often than it ought to, doesn’t it?
JAMES: I was looking through this list that the extreme programming site has, all the different components, the “rules” of XP. I’m not sure I like the word ‘rules’.
WILL: We agree.
JAMES: But I was looking through this. Basically, I was doing it because of Avdi’s question of which practices do you think people have passed on and the system metaphor is maybe one in designing I don’t see as often and I always think is cool when I read about it in XP books and stuff like that. The other one that drives me crazy in our industry is sustainable pace. I think we’re absolutely terrible at that. [Chuckles]
JOSH: Will, talk about sustainable pace at Pivotal.
WILL: Yeah.
JOSH: How many years have you been at Pivotal?
WILL: Well, I started back in 2009, took a year-long hiatus to go work for a startup and then came back, if that speaks anything to what I like about Pivotal.
JOSH: Yeah, I was there four years, about. For me, it was a very sustainable pace.
WILL: Right. The typical developer is expected to be there at 9 o’clock. We serve breakfast to get everyone there on time. And then in most cases, work is done by 6:00 PM. And sort of the understanding there, more than just the strict 9 to 6 or 40 hours a week, if you will, is understanding that there’s always going to be more work. And that on the flipside of that, where that’s daunting and scary, is that we’re always working on the most important thing. Because we use tracker or any other tool that would highly prioritize what needs to be done in a linear fashion. We know that the thing that we’re peeling off next is the most important thing to the software that we’re building. So, if you ship it tomorrow, it’s going to have the top features that we could possibly get done in the time that was allotted. And it’s just so huge for team happiness. I think for creativity, as well, where your fellow engineer can go and either re-energize with his family or go have a hobby afterwards and then bring that same experience back to writing software, where you can relate to what it was like to coach. Maybe he’s coaching little league baseball or something, and he can take that coaching skill and now apply it to working with a new developer who’s trying to learn some concept. Those experiences enrich us and make us better at the things that we do at the core of every work day.
JAMES: Yeah, just to be clear. I wasn’t attacking Pivotal there. I was speaking more to our consulting culture, I think. It seems like the pace of a lot of projects is a race to see if you can finish the project, or the lead developer who has a heart attack first.
WILL: Right.
[Laughter]
WILL: What I was trying to highlight is that it’s easy to get wrapped up in doing everything, doing all the things that you think you needed to do and what XP steers you towards, Pivotal or not Pivotal, is doing the most important thing. So, you can find a place, somewhere in there, that’s short of doing all the stuff, that is going to produce value for that end user. And that’s what makes it sustainable. You can stop if you need to.
JOSH: I think this is the heart of doing XP well, is discipline. It’s like any other craft that you get good at, it’s like — oh, I always forget the name of the painter, it’s not Picasso, who said something like, “I spend 14 hours a day practicing for 30 years and now they call me a genius?”
WILL: [Chuckles] Right.
CHUCK: [Laughs]
JOSH: It’s hard work. But I love the conversation that Rob Mee has around crisis and reacting to the inevitable firefighting that you have to do. He says if you’re going to get brain surgery and the neurosurgeon is operating on you and there’s a problem, that’s not the moment when you want him to throw all of his discipline and standard practices out the window and panic and run around and do something crazy. That’s the time when you really want him to get down there and just do everything right and follow the discipline and not lose his cool.
JAMES: Another good example that it’s in a Malcolm Gladwell book, I can’t remember which one, but he talks about how airplanes don’t crash because one thing goes wrong. That we have way more than enough safety checks and stuff built into airplanes that if one thing goes wrong, you’re okay. It’s when ten things go wrong, that’s when your airplane crashes. So, he gives scenarios where there’s this set of events and they keep making the wrong decision at every turn and that leads to disaster. And then, he gives an example where it’s a ridiculously complicated flight. It’s getting worse because of things that are happening, but people are countering by going and waking up people that are asleep to help them and all that kind of stuff. It’s that you can build then that cushion.
WILL: Absolutely. I think the other thing too that XP does well is helping you build up the things that let you respond in that crisis more quickly or more effectively. If your deploys are fast, then not only are you getting that feedback every day, but then when something does go wrong, you could fix the bug, get it out there and not have to worry that, “Oh, man, every minute we push this out, we’ve still got another eight hour deploy ahead of us where we’ve got to go merge it in with six other teams,” or whatever it is, right?
JOSH: Yeah. I used to work in an organization where it was literally three weeks from the moment we said ‘we want to deploy this software’ to when it showed up in production.
WILL: Right and how can you respond to a crisis that way?
JOSH: Yeah.
CHUCK: [Chuckles] Wait! Rollback! [Chuckles]
JOSH: Yeah. Okay, Will, I brought up design. I think that’s one of the things that I’ve seen Pivotal do particularly well and it’s not a very common way of operating in the web development community. And that’s how designers get integrated into the agile process.
WILL: So, you’re actually talking about the visual representation, the user experience, those things, when you say this. You’re not talking about software design.
JOSH: I’m talking about the — I mean, design is such an ambiguous term, right? Yes, but the visual, the interaction, and the graphical designers, basically, people doing the frontend design.
WILL: So, it’s a newer practice for us and it’s still growing and still getting better, I would say. It’s trending in a really interesting way for us. On the last couple of projects I’ve been on, we’ve gotten, we’ve had a few designers placed on our teams that not only have the Photoshop shops but they’re familiar with HAML and SASS and those kinds of things. So, I can actually sit down and pair with them as a developer, as an engineer, and find that common intersection where I might go as far as working with them to go through wireframes and things like that. And they’ll come as far back as the controller and learning about variables and that kind of thing. What I really like about that interaction is, on both sides, we understand, we start to learn, get an appreciation for the impact of good UX for me as a developer but then also, they can make informed choices about what UX they actually want and the cost that’s associated with it. Because it might be that they set up this hot new slider and for them in the wireframe, it’s draw two images of when it’s slid to the left or slid to the right. But then, when we sit down to implement it, they start to realize, “Oh my, gosh. This is X amount of JavaScript and X amount of images.” And they have to think about all these different transitions and how does that play into the form state and all these other things. And they realize that there is a lot of complexity here and all I really needed was a radio button but I thought it’d look nice. So in the future, I’m going to make a choice to simplify that piece. Or if I decide that it’s really key to that experience, I’m going to say it’s okay to go ahead and incur that cost.
JOSH: I loved listening to that.
WILL: So, it’s no longer an ‘us versus them’. I think the other experiences that I had prior to Pivotal or even earlier days of Pivotal design or working with client designers, they’d show me, they’d hopefully sliced up some PSD for me and I’m like, “Oh my, gosh. Yet another crazy design from these designer folks.” And we’d go implement it without — because we weren’t the experts, we didn’t feel comfortable in challenging it and saying, “Hey, this is super expensive. Did you really mean to do this or not?” And then vice versa, I think they didn’t feel comfortable reaching into the engineering process. So, it just builds up trust between the two groups when you actually sit together and have that overlapping area that you can work together.
JOSH: My favorite bit is when you get to the point on the project where there’s enough common ground between the design part of the team and the development part of the team that the designer just hands you. Once there’s trust there that you can do their designs, they’ll start getting a little more abstract in the designs and say, “Okay, we just need a form that asks for their first name and their last name.” And you’ve done enough forms where you have a style guide for what forms are going to look like that they don’t feel like they have a need to mock up the screen.
WILL: Absolutely. To further build on that and bring up tools again, one of the things that’s been developed by one of our Pivots was just that, a style guide. A living style guide where it pulls in all the CSS files or SASS files or whatever you’re working with and highlights each of the elements. So, right at that point, you just need a wireframe that shows what the fields are, what the text is and you know it’s going to look like because all those things just click into place once you plug them in.
CHUCK: One thing that strikes me about this, because we’re talking about the disconnect that you sometimes have between your designers and your developers and your process for overcoming that. But at the same time I see a lot of organizations that may or may not have that dysfunction, but they have a very similar one with their customer or their product owner or their product manager for things like that and XP addresses a lot of those as well.
WILL: And if it doesn’t address it directly, it certainly highlights the pain, which I think is another great thing that XP does, where it’s easier maybe in waterfall to assume that, “Hey, this is going to get results somewhere down the road and we’ll work around it. We’ll do some of these other lower priority features to get there or things that are clear.” Whereas in XP, since you’ve got the highest priority thing and you want to work on that and you have clear business value attached to each thing that’s being done or not being done, it’s a really interesting and pointed conversation around, “This is what we need to be effective. How can we get that thing?” Or does it make sense to do something else instead, if we can’t get that thing? The conversation is focused and honest and driven by actual facts.
JOSH: The other side of the pipeline, I think, you’ve got the designers on one side. The other end of the pipe is, in a big waterfall-type shop, you always have a QA team at the end to make sure that you built what was specified.
WILL: [Chuckles] Right.
JOSH: I was at Pivotal four years and I never saw QA teams. I’ve worked on a bunch of agile projects and there’s never any QA team. How do you deal with that when you have a customer come in who has a bunch of resources dedicated to QA and they want to do XP?
WILL: This happened to me, I guess last year on a project. It’s certainly challenging, where you’re accustomed to writing not only a unit test, but also automated acceptance tests and that’s really what this QA team has been focused on doing, is the same kind of acceptance test except by hand and through scripts that they read and then go and click through your app. What we ended up doing was turning that QA team into a group of exploratory testers instead, doing things that weren’t automated yet or that were hard to automate and new features came out and we certainly reduced the number of people that needed to be there, first of all. And then, turn them into almost story acceptors but more like at the fringes of that story where maybe they were delivering feature X but then how does that play into these other things or even treating them more like a first pass at user testing, if you will. If you were to put this on the wild or on the street and do some guerilla testing that way, there’s almost an in-house resource for that, in many ways.
JOSH: That reminds me to plug Elisabeth Hendrickson’s book that we’re reading as our Book Club offering this month. It’s ‘Explore It!’ and she opens talking about that. What was that conversation she had with somebody about QA where she says that all of the high value stuff that the QA team discovered? It’s like no matter how big their script of test suite is, the value is always the stuff that’s not on script. So, I think that’s really cool that the approach you’re taking is let’s formalize the QA resources into people whose mandate is to do exploration of the code, rather than just following these easily automatable acceptance suites.
WILL: Yeah, because we’ve got humans available. Let’s have them do stuff that’s hard for machines to do.
CHUCK: I like it. I really like it. We’re getting close to the end of the time. Is there anything else about XP that we really should cover for people?
JAMES: Will, you mentioned that you think there are some areas where XP is a bad thing. You want to talk about that a little bit?
WILL: Sure. We touched on this a little bit in terms of who you’re working with. If pairing is something that your company values but you haven’t hired for it, then that could certainly present all kinds of challenges. I think the thing to do in that situation is to find people who are interested, whether they self-select or you go through some sort of mock interview process, I don’t know what it would be. But find individuals that are interested in working that way and get them to get started. Then if you’re already in an organization, then you can start to make that change more gradually. I think if you want to do an overnight switch, you should definitely expect that some people aren’t going to be interested in working in a pairing environment where they’re expected to socialize their ideas with somebody constantly and have to defend or at least be a proponent, a champion of their own propositions. So, that’s one place that it can be interesting. I think the utility of XP maybe diminishes if you know exactly what you want to build. A situation like that might be you’re turning down some old software and rewriting it in a different language. For example, your whole company just switched to using Rails or maybe you go in Java, I don’t know what it would be. But then you’re just cloning something and having high priority stuff maybe doesn’t make sense because it’s all high priority and you’ve got to reproduce each feature line by line that way. But those are the two that certainly come to mind first. You guys have any other examples or thoughts of when it wouldn’t work for you?
JAMES: Hasn’t there been quite a bit of talk in the past about team size and how that relates to the various agile practices? Do you have any thoughts on that?
WILL: Yeah, that’s a good point there. I think I was poking around on the Internet and someone put a line in the sand about 12-ish people on a project. That’s definitely been my experience as well, that somewhere in between like eight to 12 for a specific team, a single team, with one backlog, things start to get interesting as far as being able to populate that backlog with meaningful stories and have everybody understand them to the point where they could peel off any of those 40 stories in a week. The thing to do in that situation is just start breaking up the team into smaller groups so they can reduce their communication cost. If I could draw in front of us now, think about if you have a single pair on the team, there’s just one communication line between those two people. If you add another pair, so now it’s four people. Then you’ve got six communication lines, if you will, or six brains, as Rob Mee likes to talk about. And that’s ideal. That’s a nice size. You add another pair, and it’s exponential from there, where I think it’s 12 lines or something for six people and then eight. It just keeps going up. So, by the time you get to 12, there’s just a bunch of different virtual brains in this pairing scenario that you have to keep up to date. If you’ve ever been in a conference room where there’s 12 people and you’re trying to get them all to one, understand, and then two, agree on what should be done, it can be super taxing. Whereas in a smaller group, it’s just going to, things naturally arrive at their conclusion more quickly.
JOSH: The other side of that, which is literally, the other side of the PM, is sometimes there’s an impedance mismatch with the hosting organization, that if you had a client that was like Ford or General Motors, some giant company that’s used to using a very different process and has 20 different stakeholders that have to sign off on any change, then you’re trying to run an agile project within this organization or with this organization as a client, there’s often some challenges managing that impedance mismatch.
WILL: You bet. And this happens to us from time to time when we’re engaged with those kinds of clients. I think what’s interesting is that one, as practitioners of XP, we come off looking faster than what they’re used to anyway, but maybe not as fast as we’re used to working with a client that doesn’t have those impedances. So, it can be frustrating as a developer who’s used to going at 110 miles an hour and now they’re back at 60. But comparatively to the software that that large company was used to, it was like 20 miles an hour kind of thing. So, it’s still a win. The other thing that, the value that this offers, like I mentioned before, is it highlights that, hey you’ve got that 20 stakeholders that all need to sign off on this and this is slow and busted. Start thinking about how you can fix that part of it. Now that we’ve fixed the engineering piece, there’s now another level above that that needs addressing, and those kinds of things. And we can always make recommendations on what we think would be best, but that company’s going to have way more context around what makes sense for it on how to solve that problem.
JOSH: Okay. What about tools? I don’t think we spent much time talking about tools. We’ve mentioned Pivotal Tracker. You mentioned something about the design style guide tool.
WILL: Yeah, in the Pivotal GitHub repo, there’s a style guide floating around.
JOSH: I remember working on some scripts for doing Git for pairs, just little things like that.
WILL: One that just recently came up is git-duet. I think that one came out of ModCloth maybe? I haven’t looked at what [inaudible] does, but there’s also a Git pair script for your commit messages so they have the dual author on there and you can appropriately attribute things back. What else? Certainly CI. Anything at work. We tend to use a lot of Jenkins for our Rails-type projects just because we’ve got something interesting on top of that. It’s ciborg, formerly called, what was it, Lobot. So, if you’re familiar with that, it’s just a bunch of shell scripts that get you a Jenkins instance running on native US real quick. Really nice for us because we can then hand that off to our client instead of putting it on some Mac mini or physical server within our structure and then try to move that at the end of the engagement. We can just swap who the account belongs to and away we go.
JOSH: I remember the days of the Mac minis.
WILL: Yes, yes. Certainly and then physical workstations are important. I think there are a handful of shops that do a fair amount of Pair Programming but it’s maybe not 100% or 90% or whatever, maybe not because of, but one of the things that get in the way is just desk setup. You’ve got to have something that two butts can comfortably sit at where you’re not up in someone’s face. Like corner desks that you’re on the inside of, very awkward to be at and try to pair. So we tend to have either one large iMac and a side monitor that’s a good size or we’re moving more and more to a second display and then two keyboards, two mice, so it’s easy to reach in. You don’t have to physically grab and wrestle away someone’s keyboard from them.
JOSH: And then there’s my favorite, which is the tete-a-tete pairing setup.
WILL: Yeah. I wish we’d had more of those desks going on. I think they’re maybe a little more space-consuming as far as floor goes. But yeah, those have been awesome.
CHUCK: Do you have any images of some of these different desk setups so that we can compare them and put them in the show notes?
WILL: Josh, you’ve got to have something for tete-a-tete, right?
JOSH: Yeah. I read a blog post at Pivotal a couple of years ago that showed some of the setups and I’ll put a link to that in the notes.
WILL: What’s nice about that one was you could look through the gap between the two displays and see each other’s face. It wasn’t this [inaudible] left and repetitive stress, if you will. But even just the separation between looking at screen of code and then physically turning to look at your pair, it was more of a, “I’m going to glance slightly off to the right now to see the emotional reaction of that pair.”
JOSH: Yeah, you can tell when your pair is cringing really easily. Plus the high fives are better.
WILL: Oh, yeah. Definitely. Definitely. So, those kinds of things. And then even the machines, this is what I wanted to say, are owned by the team, I guess is the right way to think about it. That it’s not an individual laptop assigned to you, Will Read, at the beginning of your start. So, I know that it’s going to be customized for the team and not for the individual. So key bindings and things like that are universal, at least within the team, if not the whole company. So, it’s easy for me to walk up and join a new project or rotate and work with anybody out there because I won’t feel like a dumdum sitting down and not knowing your particular vim key shortcuts when I’m like, “Hold on, I’ve got to resort this out and I don’t know how to type.” So, it gets over that social awkwardness as well, where the picture of your baby or whatever in the background. It loses some of the personal-ness but it also makes up for it in just comfort and familiarity with the developer environment.
JOSH: We’ve talked about that before on the show, I think. And one of the issues is also power dynamic. If it’s one person’s office and their personal computer, and someone else comes into their office, into their space, into their environment, into their setup, into their key bindings, it can have a negative impact on their ability to operate effectively as a team of equals.
WILL: You bet. Yeah, I think it’s super important to make it feel like it’s everybody’s space. Or if you will, on the other side, nobody’s space at the same time. I think everybody’s space is the right way to think about it because I see Pivots cleaning up after other Pivots because the desk is a little bit gnarly, or there are too many index cards laying around and they get straightened up and put into a pile. So, it gets taken care of the same way that the code gets taken care of. It’s not a ‘Hands off. Nobody owns it’. It’s a ‘Hands on. Everybody owns it’. And the first one to get to it takes care of it, both in the [inaudible] space and not.
CHUCK: Alright, I hate to cut this off because there’s a ton of good stuff that we’re getting here, but I’ve got to go take care of some other things.
JOSH: Maybe we could end with talking about resources and other places to find information.
CHUCK: Yeah, that’d be great. And then we can get into the picks.
JOSH: Will, what are other good resources?
WILL: Definitely, if you’re interested in getting into, if you just want to read if you’re a reader, Kent Beck’s ‘Extreme Programming Explained’ is the place to start. And then from there, I was going to throw these in the picks, but they both work, the Pivotal Labs blog, I have to plug that. We’re always talking about a nice mix of code and what our extreme programming practice looks like as it continues to evolve. Every project’s making different choices about, do we need CI? Does it make sense? What does it look like to engage with designers? That kind of thing. What do our designers think about engaging with developers? So definitely, go check that out. If you’re looking to do more of that, there are a couple of educational places to go. These nine-week intensive ‘learn to be a developer’ classes are coming up all over the place. And the one that I can speak the most to because I have the most familiarity with it, is Dev Bootcamp. It’s really how to be a Pivot in nine weeks because they go into Pair Programming, how to do Test-Driven Development. It’s Rails and Ruby focused. Even Rob Mee has gone over there and spoken a couple of times. So, it’s one of those things that we’ve hired a couple of Bootcampers. So, if you’re interested in really getting into and working that way, it’s a great way to get exposed to it in a classroom-type setting.
CHUCK: Awesome.
JAMES: Cool.
CHUCK: Alright. Well, let’s go ahead and do the picks. Avdi, what are your picks?
AVDI: So, let’s see. Today, my picks are, I’ll start off with a fiction pick. I occasionally listen to the Escape Pod podcast, which is a podcast of short science fiction.
JOSH: Yes, founded by a Rails developer.
AVDI: It’s a good podcast. They’ve been going for a long time and they get some really good stories, including, I just listened to episode 398 and the story is called Subversion. [Laughter]
JOSH: Is Git the hero?
[Laughter]
CHUCK: He’s the dirty little git.
AVDI: So, it’s actually closer to what you’re thinking than you might think. It’s apparently a new author. They got the scoop on this story. Basically, the big idea of this little sci-fi story is, what if people could be version controlled and could fork off branches of themselves? And then, what happens when you have one of those long-running branches that no longer merges cleanly?
[Laughter]
JAMES: Wow.
CHUCK: Interesting.
JOSH: That’s pretty cool. I like that.
AVDI: And another pick. I tend to get the Humble Bundle games bundles when they come out, even though I have no time to play games. Usually with every bundle, there’ll be one, maybe two games that really captures my interest, which means I play it for more than five minutes. But I got one of the Android ones recently and I just started playing the game The Room, which came with that. And it is, for fans of very bad movies, this game is not what you’re thinking. It has nothing to do with the movie The Room, unfortunately.
[Laughter]
AVDI: Although I understand that there is a video game version of The Room. Go look for that. But it’s an interesting game that I can play on my tablet and basically, you’re confronted with this room, with these puzzle boxes. And really, just one big puzzle box in it. And the whole game is just this atmospheric exploration of the puzzle box as you slowly find little things here and there that enable you to open up other parts of it and it reveals more of itself. And a back story reveals itself along the way. It’s slow-paced. It’s something I can play in the dark as I’m trying to rock the baby to sleep. It’s surprisingly engaging. That’s it for me.
CHUCK: Awesome. Alright. James, what are your picks?
JAMES: I want to point out a couple of cool events that I think people ought to know about. First of all, Rails Girls is doing a Summer of Code all their own. So kind of like Google Summer of Code, or Ruby Summer of Code, but designed on getting Rails Girls students and other novice programmers into open source, which I think is totally awesome. Sadly, I just learned about it too late and the campaign is going to end before this thing goes out. But still, I think it’s important to point it out because they’re looking for coaches and stuff. They’re going to have, in addition to the usual mentor-mentee model, they’re going to add in coaches to sit in IRC and are available and stuff. I’m sure they’ll be looking for people to help with that. So, that’s something that our listeners could get involved with. And I think it’s just a great goal. It’s a good movement and adds a recurring big purpose to Rails Girls and gives them a way to funnel people in with the carrot in the future, “Yeah, get this app going now that you’ve learned all this, you should do Summer of Code next year,” and stuff. I think that’s just awesome. So, this is a great project we should keep an eye on and do our best to help support, in my opinion. And if you want to give them money, I bet you could probably get in touch and give a last minute donation. I’m sure they’d be appreciative. So, that’s one awesome thing that’s going on. The other awesome thing going on in July is the LoneStar Ruby conference. You should come to this conference anyway because it’s typically great. I’ve been there five year, I think, maybe four. It’s always a good conference. The lineup this year is incredible. Lots of great keynote speakers, including some of us and Sandi Metz. So, great lineup. They’ve been announcing their talks. It looks like the best, including speakers we’ve had on. Nell is going to be there talking about regular expressions like she did for us recently. As icing on the cake, all of us Rogues will be there. So come out, say hi to us, and we’d love to see you all there. Those are some cool events going on this summer which I think programmers should know about.
CHUCK: Yeah, just to add to that, if you’re interested in doing some kind of meet up on of the nights, I think that’d be way fun. So, just tweet at us and let us know if you’re going to come. Josh, what are your picks?
JOSH: I have one pick this week and that is one of my favorite authors. His name is Steven Brust. I know I’ve talked about him with the Rogues, but I don’t think I’ve picked him as one of my picks before. But I’m reading one of his recent novels and really loving it. So, I’m going to pick Steven Brust. He’s writing this series of novels set in a fantasy world about, basically a human assassin living in a world of elves. If that sounds a lot like an old D&D game, that’s because Steven Brust used to play the precursor of Dungeons & Dragons with Dave Arneson, that guy with Gary Gygax who created Dungeons & Dragons way back when. So, the game very much feels like you’re running a D&D campaign. Everybody’s running around with artifacts. People die and get resurrected all the time. But the writing is excellent. Brust is not afraid to get philosophical or political in his writing, but he always makes it topical to what’s going on in the novels. There were a couple of downer novels when Brust was going through a difficult divorce with his wife, that showed up in the novels all over the place. But other than that, the novels are just tons of fun. And it’s like reading an Ocean’s Eleven or The Sting. It’s that level of complexity in the plots very often. I like those. His latest book is Tiassa. That’ll be the pick that I put in because that’s what I’ve been reading like crazy lately. He’s a lot of fun. Really worth checking out. He’s also good on twitter. That’s it for me.
CHUCK: Awesome. Alright. I’m not sure if I’ve picked this before. I probably should go look at the picks list. But if I have, I’m going to pick it again anyway. There’s an app for the iPhone that’s been helping me get in the habit of doing things that I really want to do. It’s called Commit. It’s by Nathan Barry. If you’re interested, go check it out. Besides that, I really don’t have anything to pick this week. So, I’m going to pass the ball over to Will. Will, what are your picks?
WILL: My pick is The Crucible. It’s an awesome place if you’re in the bay area and you’re into making stuff. It’s kind of like tech shop meets fire. I think that’s maybe the best way to describe it, where you can do all kinds of things like woodworking, blacksmithing. They have glass flame working, which is a class I took several years ago. And I recently took an Arduino class over there and learned how to hook small electronics up to large electronics. And now I’ve got a mad science project going on that my fiancé is like, “Oh my gosh, why?” I’ve created a monster, essentially. So, if that’s the kind of thing you’re looking for, definitely check it out. It’s in West Oakland.
CHUCK: Alright. And we stole your other two picks when we asked you for resources.
WILL: Yes. Pivotal Labs blog, definitely check it out. And then, go to Dev Bootcamp if you really want to get into that kind of development.
CHUCK: Awesome. Alright. Well, thanks for coming, Will. It was an excellent conversation.
WILL: Thanks for having me.
CHUCK: Alright. We’ll wrap this all up. We’ll hopefully see you at LoneStar Ruby Conference and we’ll catch you all next week.
