rc3.org Strong opinions weakly held

Having worked in this environment for a little while, I’m not sure I agree that these are really prerequisites, but I’ll try to comment on each:

Your developers must be users of the product.

This is probably the key to everything. Seriously. Take everything below with a grain of salt.

Your developers must be able to iterate without relying too much on other members of the team.

We rely on each other quite a lot, actually. When somebody starts pasting screen caps of some concept into the campfire and they’re really good, people want to jump in and be a part of it. Sometimes you’re working on something and are totally content and loving it but you see that somebody else is really close and they could use a hand and so you make a decision to drop what you’re doing and switch over to that because, hey, let’s just ship that real quick because it’s close and it’s amazing and it’s not like the thing you’re working on has a deadline.

There’s a tremendous amount of freedom and flexibility. More times than not, that results in people using that flexibility to work together in ways that may not have been foreseen or planned.

There’s also times when people don’t jump in on a new concept. Those things may move more slowly. Maybe they should move more slowly. There’s times when something is worked on for a couple of days and then people lose interest for whatever reason. Maybe it’s not interesting.

I think this is part of what Scott was referring to when he said, “open source software style of business”. In an open source project, it’s hard for bad ideas to gain a lot of support. The maintainer doesn’t really get to tell other contributors what to work on. They can set a vision and tone, but an idea sinks or swims largely on its own merits and whether the people contributing feel it’s worthwhile as a collective.

I guess conventional wisdom is that team planning meetings (in whatever methodology you subscribe to) can be used to get the same results in a more orderly fashion. You get everyone in a room and you ask them, “do you think this is interesting? Should we prioritize X over Y?” And everyone says, “Hmmmm. Yes, let’s do Y first and then X but definitely not B,” and there’s debate and eventually everyone comes to an agreement and starts working on whatever was decided. There’s a lot of thinking and talking and committing involved.

The problem with the planning approach in my experience is this: what people think/say they want to do and what they really want to do (or what they’re capable of doing) are often wildly different things. It’s kind of like: “put your money where your mouth is.” Say you show me some thing and ask me whether I think it’s cool or valuable and I say, “yeah, it’s great and I’d totally buy it, yeah.” And then you say, “give me $100 and you can have this thing,” and now I’m not so sure. The act of actually having to take money out of my pocket and trade it for this thing is a powerful device. All the bullshit is distilled down to a very simple binary event: I pay or I go do something else. There’s no hypotheticals at that point.

I think time is kind of like that. It’s hard to tell how it’s best spent until a real person is faced with a decision to actually spend it or not spend it. At GitHub, we have a very simple voting/prioritization system: whatever people decide to work on is a priority, by definition. If something is interesting, more people end up working on it. This doesn’t mean there’s no priorities. It just means we find out about them instead of deciding on them.

And I want to stress that there’s more than just this selfish I’m-intellectually-curious-about-X-and-so-X-is-all-I’m-going-to-work-on thing going on here. You want to ship. You want to make money. You want people to love the shit you put out. You want to kick ass. You want your coworkers to kick ass. You want the site to be stable and fast and reliable. All of those things are at work all the time and they play into what you decide to work on at every moment.

The business must not have customers who are promised certain features by a certain date. Customers of every software company I’ve ever worked for have requested features that no developer wants to work on, but they pay the bills, so we worked on them anyway.

I’ll agree that dates are hard with this kind of setup, but dates are always hard. We’re just honest about it. I’d say the only difference between GitHub and most other places I’ve worked at in practice is that I apologize for being late a lot less. The same work gets done in the same amount of time, there’s just fewer estimation errors because there’s less estimating. Actually, I feel like I get more done “on time” because I have more freedom to take things that really aren’t time critical and shift them around because I wasn’t forced to put an artificial deadline on them in the first place.

As for working on stuff that’s tedious or maybe not immediately gratifying, that happens all the time. Again, the goal isn’t always to just work on what’s intellectually interesting. Things can be interesting for all kinds of reasons. Money is certainly interesting. Helping somebody out in a jam on a support request is interesting, even though the work might not be all that fun. Plugging a security vulnerability 20 minutes after it was reported is interesting. Fixing a bug that’s flooding your exception notification system is interesting.

I want GitHub’s availability and reliability to be unmatched. The steps required to get there aren’t all intellectually stimulating. Some of the stuff is a real chore. But I want to get there dammit. Getting there is interesting.

Also, most things are interesting to someone. There’s a few areas right now that no one has a particularly strong interest in. When things become neglected, they’re very quickly obvious. They don’t have a chance to fester. They just pop and are ugly and everybody has to look at it all the time and it’s annoying. At GitHub, those things are taken as a sign that we should consider hiring somebody who is interested in that thing. The more everyone is forced to take time away from what they would rather be doing to deal with the thing, the more pressure is created to find the person that’s going to love that thing and fix it for good.

I didn’t realize I had so much to say about this. I guess I feel like I’ve already learned a ton from these guys and am anxious to share. I’m still trying to figure out how it works so damn well myself. I doubt anyone really understands the thing. We’re all pretty good at rolling with it.

Posted by Ryan Tomayko on 20 February 2010 @ 3am

Thanks for the comment! All things considered it sounds like a great place to work, and certainly the product is incredibly good. What I’m trying to figure out is how I can make these good ideas work for me …

Posted by Rafe on 20 February 2010 @ 11am

Very interesting! I dig it because it challenges the planners and estimators. I’m thinking it would be challenging to implement the approach on a consulting gig. On your own business, though, it seems like the approach has a ton of advantages.

Posted by Duff OMelia on 20 February 2010 @ 7pm

Why can’t I read anything about Github without thinking about XKCD 624 (http://www.xkcd.com/624/) and Github for Lesbians. Curse you Randall Munroe.

Posted by Kaleberg on 20 February 2010 @ 10pm

obviously it would be great to work in an environment where you’re always doing exactly what you want to do… but if there is no planning, sprints/iterations, then how do they do release management? do they just do continuous deployment?

Posted by moonmaster9000 on 21 February 2010 @ 10am

Seems to me that this could work, and work well in some projects. However, I think many projects needs a bit more planning and followup to keep on track and deliver that is most needed. Besides planning, some metrics and time to reflect is good so that you don’t repeat misstakes and see what really works for your team.

Posted by Joakim Kolsjö on 21 February 2010 @ 2pm

Damn Ryan… you wrote more than the original post. You must like it here.

Release management? We don’t have “releases” in the traditional sense. When something is ready, it gets deployed. We might try to deploy a few things at once, but we don’t have some number with a deadline that says “on this date we’re releasing this version with features X, Y and Z.” I guess that’s “continuous deployment,” if you want to label it.

The funny thing is, as support, I’m on the opposite side of things here. I’ve come to accept that my primary job is two-fold. First, of course, I have to keep the customers happy. The things I can’t fix quickly, I have to track someone down to fix. That makes my secondary job harassing everyone to fix things they don’t want to deal with. When all else fails, I dive into the code and fix it myself. Having the freedom to take an afternoon to program is wonderful, and it really helps me not get burned out on the customer relations side of things.

The business must not have customers who are promised certain features by a certain date. Customers of every software company I’ve ever worked for have requested features that no developer wants to work on, but they pay the bills, so we worked on them anyway.

Honestly, I question the need need for such promises. We never ever give dates or timelines beyond “soon” to customers. There are things we honestly want to implement, or bugs that we are still tracking down, but we don’t know when those will be done. I believe that giving the customer a date is harmful in two ways here. First off, we don’t know if the date is even realistic, so there’s a good chance we’re lying to the customer. Telling them “yea I pulled that date out of my ass” only makes it worse. Second, imposing a deadline just adds stress to the developer for no good reason. The developer rushes to meet the deadline, bad code is made, things don’t go according to plan, deadlines are often missed. You’re only setting yourself and the user up for disappointment. We have never had a user upset because we wouldn’t give a timeframe yet, and I hope we never do.

Sure, some deadlines are unavoidable, but I think that keeping the deadlines restricted to bare necessity is a great thing. When you’re not spending times planning where things will go, you spend more time going there. In the end you’re going to reach the same place, but the trip is going to be much more enjoyable.

Posted by Tekkub on 22 February 2010 @ 3am

@moonmaster9000 we deploy whenever we want.

Posted by PJ Hyett on 22 February 2010 @ 4am

I wrote a little reaction to this on my blog trying to wrap it in some general principles of effective collaboration.

http://cdent.tumblr.com/post/404793442/choosing-to-know-implicit-goals

Posted by Chris Dent on 22 February 2010 @ 8am

I’m not sure it’s a useful exercise to try to quantify what makes this type of workflow possible. The obvious truth is that Github has almost unlimited sex appeal and dogfooding potential. It’s the perfect storm of talent and market opportunity. Not every programmer is interested in version control for this to be their dream job, but certainly enough do that Github will never have any trouble hiring the exact type of person they need at any given time. Also, since the target market is programmers, there’s diminished no need for separate domain experts, analysts, or marketers.

In short, when you add it all up, Github has an amazing developer-centric profile that is literally one in a million as far as real-world profitable businesses are concerned. It might make us feel good to enumerate the things that are holding our companies back from this kind of process, but I think it’s more productive to ask what we can learn from that process, and how can we utilize our individual company cultures to implement processes that are more agile than the “Agile” processes which have been developed, refined and packaged by consultants whose proven skillset by definition has been marketing their ideas rather than any provable development talent.

Posted by Gabe da Silveira on 22 February 2010 @ 7pm

It implies that nobody talks to nobody in this approach, but the chances are that people are working on:

• One fairly well focused project only
• Are working on pairs or communicating regularly
• Are producing something that is very techy oriented (I still haven’t been able to ‘deploy’ GitHub into my environment (even though I want to badly do it) so they are failing somewhere
• Their productivity (overall) might be pretty poor – while they might feel like they are doing loads, but in fact GitHub is not known for churning out significant innovations non-stop
• Their team is likely to be (very) small, so ah-hoc communication will do just fine

Posted by Jason Grant on 23 February 2010 @ 7am

Being that half of the interview was answered in “sarcastic mode”, I wonder if the quote regarding their development process isn’t also some kind of joke… Probably not, as commentators above this comment commented that’s the way things work on GitHub.

Posted by Julián Landerreche on 23 February 2010 @ 9am

We tend to work in the same way with the AVOIR project (http://avoir.uwc.ac.za) although not officially.

I think the hardest question here is managing delivery dates, and the simple answer to that is to have enough passionate people within your dev community that whatever comes up someone will be interested enough to deliver it ASAP.

We have rarely encountered a problematic situation like this in the past few years of the project, but before we had that critical mass, it was very very difficult.

Posted by Paul Scott on 23 February 2010 @ 10am

This works at my company, but then again, my company is a one-man operation, I make games, and I play all the games I work on.

Posted by Montoya on 23 February 2010 @ 1pm

@Ryan, how do you prevent developers from half finished projects or spinning off chasing shiny objects?

At some point you have to deliver that last 20%

Posted by @TheSandyWalsh on 24 February 2010 @ 10am

I am not sure that there are many types of projects other than this where you can get away with the ‘I do it cause I want to and the client is basically another copy of me so they will like the result too’ type of structure. You have a unique environment in which to develop, inspire and in turn be inspired. A shame cause much of the real world has the overlord paying the bills and providing promises to their counterparts, in turn forcing deadlines on the development and expecting to be able to rationalize each part of the process and watch it, because that is there responsibility and expectation. I think the Agile process needs to take in the business owners more than what it now accomplishes with the development team, it’s a great system if you have some good people developing in an area of their interest and the top-end doesn’t play with it or pull the strings too much.

Posted by Warren on 25 February 2010 @ 5pm