Bio Tim is a trainer for GitHub, a speaker internationally and on the No Fluff Just Stuff tour in the United States, and is co-president of the Denver Open Source User Group. He is a contributor to the Ratpack web framework, is co-presenter of the O'Reilly Git Master Class, co-author of Building and Testing with Gradle. He blogs occasionally at timberglund.com .
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
Good morning Peter, I have for the past ten months been working at GitHub, I'm part of the training team there and what that means is I spend a lot of time on the road teaching people Git and GitHub, speaking at conferences about other related topics, certainly that is why I’m here. We do plenty of online training too, so sometimes I’m in my home training studio, sometimes I’m on airplane, sometimes I’m in conference rooms, but it’s been great work, I love it.
2. Great, and you were certainly rocking the conferences room last night with your keynote “First kill all the product owners”, so for people who weren't able to attend, could you maybe give us an overview of the hypothesis?
Yes, absolutely, first of all the title, if that is jarring to anyone, is sort of a remix of famous Shakespeare quote: “First let’s kill all the lawyers” and so kind of riffing on that. The idea is that what is now the received Agile orthodoxy that kind of coming from the Manifesto ten years ago and Scrum and things like that, is that there is this person called the product owner, the product manager who is responsible for capturing stories from the business or from the customer getting them into story form, prioritizing them, sticking them in this backlog and sort of a broken way that that has ended up being implemented is developers then, because we sort of like simple abstractions and we can think of a queue as a data structure. Now there is this queue, I know what queue is, I can think about that, and I pull these objects off of this queue and I process them, so I get a story and I code the story with all these great Agile engineering practices that I’ve developed and I’m really good at now. That is too simple and does things to the role of the developer that I think are harmful to product development and harmful to humans, so I want to eliminate product owner as a specialty and push that function down in a distributed way to all of the people building the product, that is developers and everybody else.
Absolutely, so I think if you went to GitHub and said: “Hey, I’m a professional product manager, I’d like a job”, that probably would not work out so well, or if I said internally: “Hey, we need to hire a product owner for this” there might be laughter, that is just not a thing and the way that development culture has grown up at GitHub, since it was just a few people and I joined much, much later and I'm kind of learning how this works. All of the people responsible for building a thing are the people responsible for defining the product, that is developers, designers, that is other kind of roles as we are growing as a company now. There are trainers, I’m a developer but I don’t write code for GitHub and so there are all these other kinds of people that are sort of mutually responsible for figuring out what users will love and building that thing.
4. Now for any given feature or product is there a single wringable neck, is there still one person who primarily is responsible for making sure that this is good and that their taste is followed through for that?
Good question, yes. We call that person the PRP, that is the primarily responsible person, so if there is some new initiative like you think, it could be something bold, like there is some new product that you think GitHub should build for example or there is some new path that we should go down. You kind of gain support for that idea get other people on board with you, convince basically the company that it’s a good idea to do and you'd sort of implicitly be the PRP for that thing. Now you might say if I did that as a non developer, my job is not to write code at GitHub, of course I’m one, but it's not my role there, I could be a PRP for a thing and not coding on the thing, that is ok, but often times it’s developers who are the designers who PRP new features and new directions.
5. [...] And maybe in complex domains like insurance or commercial real estate where it’s much that just capturing the domain and understanding that, it feels like a fulltime job that perhaps you need a business analyst for?
Peter's full question: Now I hear people say, yes, that is easy for you because you are building developer tools, so of course developers knows what they want to use, they are the target audience. What happens either in demands where they are not the target audience, should developers really don’t want the product that they are building for other people? And maybe in complex domains like insurance or commercial real estate where it’s much that just capturing the domain and understanding that, it feels like a fulltime job that perhaps you need a business analyst for?
Yes, really good question. So number one, the objection “You guys do dev tools, that is easy for you”. What I hate about that and certainly it’s true, it’s easy for us to go down that path because I know exactly what this new pull request feature should be because I use it. It’s easy for me to think about, this is my native domain. I hate for people to say “Easy for you, brilliant idea, sounds like a great thing to do, we are going to dismiss you because we do insurance”. I don’t want to be dismissed because of that, so it’s good to kind of chew on this stuff.
What about when it’s insurance, what about when it’s commercial real estate? As a consultant a few years ago I worked with a commercial real estate startup, building a Grails app to be there their site and I started that sort of trying to keep at arms length from the domain. Like you know: “Who cares about commercial real estate? I’m going to help you with your code”. I did a bad job really, I didn’t do well until I realized I’m going to have to love this thing that you do, I love the code, I love the framework, I was working with them for a long time at that point, that was really a great thing, very energized by writing software, but I have to love this thing you do or I’m not going to do a good job building the product. So my answer is: “It's probably not too hard for the kinds of people who are good at writing software, to also learn how to do other things that are hard”. Normally we fill our spare time with things that are hard and we enjoy them, and we do a hard thing as a vocation, a primary way of earning an income and serving people.
So I don’t think it’s too hard for developers to learn things, but you might have to be selective, maybe you work for an insurance company, and learning about insurance just sounds like eating a bowl of sand every day, all day, forever, and you are not going to do that. Go find something you love then, go find a domain that you can fall in love with and something that you really feel energized where you truly believe, deep down, if you build this product in an excellent way it’s making the world better in some way that you connect with and that energizes you. So it might be that you are in the wrong business and have to go find something else to do, but I think once you are there, you can get there. More to say on that but let’s move on.
Peter's full question: It seems like we are broadening the context here so we say not only are you responsible for the development but now you need to be thinking about whether the thing that you are developing is worth building, it’s adding business analyst, product owner responsibilities to a developer. Now there has been some history of adding new roles and requirements to developers over the last decade, you have anything you want to say about that?
Absolutely, so just look back because some of the arguments that I hear, because the basic proposition as I presented in the 90 second elevator pitch sounds crazy, everybody says: “Well that is insane or dismiss that because they are cool kids in San Francisco and they are building dev tools”. Sounds crazy and the arguments that I get back sound like things we’ve heard before. For example, let’s say around 2000, unit testing was not a brand new idea then, people had been doing it for a while but it was very much a fringe thing, and conference talks were starting to push it, saying “Hey, this is a good idea” and we heard: “We have QA professionals for that” or “That is too expensive, devs are too busy they can't also write tests”. Well there are not many people now who say: “Testing is a bad idea, the devs writing automated tests is a bad idea”. That kind of argument has been won, nobody says that anymore.
And funny thing, we still do have QA professionals who do valuable work, it’s just different now, likewise DevOps, this is a more recent development, I would say as late as 2005-2006 maybe had some people like Flickr doing what we would recognize as continuous deployment these days and there is sort of an implicit DevOps sort of thing going on there, but that was fringe, that was weird, nobody did that because devs don’t know how to do sys-admin work and I’m a pretty bad admin so I’m a good example of that and Ops people can do some Bash scripting but they don’t really know how to write code and we see DevOps is still new, it's not anywhere nearly as widely accepted as testing or widely practiced as unit testing. I think the argument is over, people realize there needs to be a fusion of those two things and Ops people really are developers, they just have a particular kind of domain they are specialized in. So same arguments for testing, for Ops, those arguments are over, we don’t have those anymore, we are starting to have this one about product and I think it will be resolved in the same way.
Peter's full question: It sounds great and I understand the requirements, but actually a piece of pushback I still get from people about unit testing or now DevOps which is you know, I’m a let’s say a Java developer, it’s bad enough I’m going to have to figure out about these new lambda things, and now you are telling me on top of that, on top of learning new frameworks and getting used to new configuration options in Spring, I’m going to have to get good at unit testing and Test Driven Development and then I’m going to have to learn maybe Chef or Puppet and start to understand DevOps and DevOps in the Cloud, and on top of that you want me to become a product owner, it’s like ..., I don’t want to. What is the response to that if I really just want to hack some code?
Right, this becomes a deeply personal discussion, I don’t want to, I’m talking about my affections and it’s not about technology anymore it’s about what’s motivates you and so my question is: “Why are you unmotivated to do that?”. It might not be your fault, again it might be that you happen to have a job into an industry that you don’t care about and there is another industry you do care about. Maybe you don’t work in insurance but you really want to, that’s sounds crazy but maybe there are people who are really fired up about that, who could get fired up about that. So maybe you are in a wrong business, maybe and I think this is much more likely, it is aspects of organizational structure and culture that are defeating intrinsic motivations that you would have, because of the kind of thing that you are. You are a human being, you are driven to create things in certain ways but you’ve got this manager who tells you what to do, who is there to make sure you do the right things, you’ve got like I was talking about last night, there is a vacation policy and a sick time policy to make sure you work the adequate number of days. That is crazy, if it is something that you are motivated to do, why does somebody need to make sure you are working the adequate number of days, I mean if this is work that you are connected to doing and fired up about doing and we are tapping into your intrinsic motivation to build things, usually the problem is: “Why don’t you take some time off, you are burning out, you need to relax a little bit”, that is the problem that somebody should be solving in the company not some HR department wagging their finger because you took too much time off. That is a much bigger discussion and we're kind of having this in short form, but the substance of my argument is that there are things about the way that your organization is constituted structurally and culturally that cause developers not to care and only to write work because a lash at their back to get that story written. If that is the case, this will never work. Let’s reexamine the assumption of hierarchy in an organization such as that we can recover some of these intrinsic motivations that are being defeated and that probably sounds a little more revolutionary than I even intend it to, I think there is always hierarchy in human groups but it tends to be what we want to see as an emergent kind of authority structure and not an imposed top down one.
Peter's full question: So if somebody buys this argument, it’s fairly compiling, who wouldn’t want to build work that they are proud of, who wouldn’t want to build awesome software that they care about and get away from this idea of: “Hey, the product owner told me to do this and I know it’s stupid and I know it’s a waste but they are paying the bills”. However there are a set of skills that product owners and business analysts have, it’s actually a domain as in of itself even independent of the domain within which your company happens to work, insurance, real estate…. As a developer how do I start to get good at product management?
Yes, good question. There might be a whole lot of other problems that you have to solve before you even want to, like if you hate your job and the stuff you do, it’s not going to work, don’t bother, trying to correct those problems. But let’s say you love your job and you are fired up about the work that you do and you have a product owner that you work with on the team, as it turns out I’m not actually calling for the assassination of those people, I mean they are really, really useful people. In an organization that is making that kind of changes that I’m asking for, that person is a coach. If I’m a developer and I get to partner with that product owner over there, please teach me how to do the stuff that you do, that is why that the people who are really good at that, I think in the world I’m wishing for, are incredibly valuable. Now it’s their job to help the rest of us who don’t happen to specialize in that work, to be good at it, and I think they are always going to be there coaching us. So I’m excited about those people about that profession and I would like to see them leading the charge here, saying: “I don’t want this all to go through me”, I want everybody to be good at this, I want to try to work myself out of a job, I want to cannibalize my own business, and I think we’ll see times and times again when a person tries to work themselves out of the job or a company tries to cannibalize its own business, Apple is famous for doing it and so forth. Usually you see nobody goes out of business that way, they usually increase in value rather than decrease.
Peter's full question: That is great, so let me change gears for a moment and ask about some of the technical elements of GitHub, because a lot of this is about collaboration and I know that just built in to GitHub whether you are part of the company where they are dog-fooding and using their own product or whether you are just using GitHub, it has got some really interesting tools for collaboration, could you talk a little bit about how you use things like pull requests to manage the collaboration around a new feature or a story?
We use them internally as one team of people who all trust each other, where there is as I like to say, trust is a symmetric, a developer trusts me, I trust a developer in an equal way. Pull request become a great code review and asynchronous communication mechanism, we're all over the place, different time zones, it’s impossible to determine what time zone I will be in in any given week. There are people with different schedules who are happy to work at night, I’m a diurnal human and it turns out there are some nocturnal ones, so we have this online mechanism for capturing discussion in a pretty rich way, it's not just text comments but it can be comments that are broken down per line of code, it can be images, paste in a screenshot or sketch of something or an animated gif if you want to make a humorous point, being that you have that sort of fun, the context of that discussion is important, so in that pull request is, all that discussion happens, you don’t know what a pull request is in the audience, in the context of sort of a package of changes going from here to there, like I’ve branched the source code and I’ve made some changes and we are talking about those changes getting merged in, and that discussion happens in there, so it’s a good loose way of having that discussion.
Peter's full question: Now it’s interesting because in most companies when people start with pull requests, it’s a way of implementing an informal code review. Let’s say we’ve got a trusted team, we use branch based pull requests so I would do a pull request and basically somebody else in the team would you just check this out make sure it’s a good idea and then let’s run the code, let’s merge it into master and make this part of the main line. But from what I understand, at GitHub you sometimes use pull requests even earlier in the process before maybe starting writing the code. How can I possibly do a pull request if I haven't written the code yet?
So there are two things that a pull request can mean. One of them is: “I made this for you, here is all my stuff, please merge it”, and in the open source sense where I have forked some repo that I trust but that doesn’t trust me, I make some changes, fix a bug, add a feature, I get that working in the fork and submit that in the pull request, here you go it’s all done. The other thing that a pull request can mean is let’s talk about this, so suppose I want to build a feature but I want to talk about the feature, I’ll branch, I write a Readme, an aspirational Readme describing what I think the feature ought to be, open a pull request, that means let’s talk about the Readme and we'll collaborate on that, discuss that and change that and once that is solid, I can begin to commit to that branch with code, we'll review the code, talk about the implementation, maybe iterate and review the definition of the feature, but the whole thing is a discussion about things we don’t know yet. And that's software usually you don’t know the thing that it’s going to be.
Peter: Tim great, thank you very much for taking the time to speak with us here on InfoQ, I’m Peter Bell, thank you!
Delighted to be with you, thank you!