Hey! My new website is Section 411. It's a lot like this site, except it's about 100% newer. Click here to check it out!

Developing asychronously

Why it works for Github, but maybe not for the rest of us

These days, it’s not hard to find a Silicon Valley startup that claims, not so modestly, that it’s changing the world. And while it’s true that some startups are doing just that, the not-well-kept secret is that most of them aren’t doing anything productive, much less profitable, but still somehow find ways to get funding. But one startup, Github, is unique: not only is it changing the world, but it’s changing the way startups change the world. Github’s about page claims it hosts over two million repositories, which include the likes of the Facebook SDKs, the popular JavaScript framework jQuery, and the open-source release of Doom 3. It was even the primary home to arguably the most important open-source project ever, the Linux kernel, when its usual home was compromised earlier this summer.

And while Github is making a huge difference in how people write, store and track their source code, it’s also starting to affect how people develop software. This is an important distinction, and failing to optimize the processes and philosophies that you and your team take while developing software can lead to productivity losses just as severe as bad developers or bad bugs.

Github’s most notable employee who has talked about their process is Zach Holman, who has written a few blog posts as well as given a talk on the subject. His overarching thesis is that optimizing your development process is much like optimizing a piece of software you write: minimize the your blocks by making them asynchronous. This means:

  • no meetings, which require developers to synchronously stop what they’re doing, walk to the conference room, and meet about stuff which may or may not involve them for an indefinite amount of time,
  • no deadlines, which sometimes require developers to synchronously stop what they’re doing to work on something more pressing,
  • no pings, which distract developers and pull them away from what they’re working on,
  • no hours, which require developers to start and stop synchronously, and sometimes starts or stops them at suboptimal times, and
  • no managers, who in the best case scenario, try to schedule developers so that they’re working as asynchronously as possible, but in the worst case, simply get in the way.

There’s not a whole lot of “radical” in these ideas, at least not as far as I, a developer, am concerned. I know I work best when I’m uninterrupted and on my own schedule, and am happiest when I feel autonomous, or that I’m not depending on anyone else or waiting on anyone else for me to do my job. But hand this list to most traditional businessmen (or software managers) and they’ll have a different impression.

Why it works for Github

  • Github works for themselves. As a developer, it’s pretty rare to work for a company that produces products for end-users, as opposed to a company that produces products for clients. Companies that produce products for clients not only have to do what the clients ask them to do (or risk not getting paid), but clients come from the enterprise, 20th-century world of business, which means spec sheets, pings, hours, meetings and deadlines. On the other hand, companies that produce products for end-users might solicit feedback, and they might even listen to that feedback, but in the end, they’re making product decisions based on their own interests.

    Github is in the unique position of not only producing products for end-users, but they’re producing products for developers. This distinction means the user base is very narrow, meaning that Github can stay focused on providing features for almost all their users at once, rather than features for business users here and home users over here. Additionally, not every feature has to have the smoothest edges right off the bat, so features can be released, tried, tested, and if they don’t work, can be put to bed. And since there’s no direct client relationships, there doesn’t have to be any deadlines except internal ones, and really, that’s just a choice.

  • Github is full of really smart people who are all driving towards a similar goal. By creating a product that’s popular and well-liked by developers, Github has their choice of talent to hire. Not only can they find really smart developers, but they can (and do) find developers who have resonant beliefs to the rest of the company. Hiring developers like this means everyone can settle into their role and figure out how they can contribute best on their own, without a manager getting involved. If Github interviews a potential hire who doesn’t want to work really hard, and is only in it for the money, they can pass on him, assured that there are more desirable developers eager to take his place. Not all companies have this flexibility, because not all companies are in the position of having a really cool job to offer.

    And to be clear, that similar goal isn’t “making money” or “building value for an exit”. Github was founded to solve a problem of sharing code between friends, and today, their goal is simply to make developers’ lives easier by removing as many headaches that used to come from version control, issue tracking, and code reviews, as possible. If some employees’ goals were to simply make as much money as possible, then they’d fight with the more idealist employees who are trying to make a better product over what features need prioritized, and when they need them done (for example: a better ad-serving platform instead of fixing bugs with the code review process).

What the rest of us can do

It’s true that we won’t be abolishing software managers any time soon, nor will most of us be able to eradicate deadlines. But that wasn’t Zach’s point in his talks; his point was that Github’s methods are just an aggressive way of tackling the headaches and blocks that developers face every day. Most of us can’t take the same amount of steps that Github has, but there are certainly lessons from Github’s approach that we can apply.

  • Software managers’ main goal should be to minimize developer interruptions to maximize their productivity. Joel Spolsky writes that developers should be solely focused on developing as much as possible, because the little interruptions add up and eventually lead to lost productivity, most of which can be avoided.

    Github sees software managers as getting in the way of the developers, but if you have to have them around (and you do, because most software teams require some management in order to get much done), then they should be trying to get themselves in the way of all the interruptions they can. This means intercepting pings which aren’t urgent but will knock the developer out of the zone anyway, making sure that each developer is working on something and isn’t waiting on anyone else, and in the best case, acting as sort of a surrogate developer that can interact with the rest of the company while the developers do their thing on their own time.

  • Software development processes should be as simple as possible. Many of the headaches that come with software development are a result of the meta tasks: source control, bug tracking, deploying code, etc. Github’s rule (anything in the master branch is deployable) is simple enough to remember but powerful enough to let developers work on stuff without a fear of breaking anything. Rule #2 in The Joel Test is that developers should be able to make a build in one step, reducing the complexity and chance for human error when deploying code. Github uses their own issue tracking every day, so if something with bug tracking isn’t simple enough, they know about it quickly, and if they need to deploy code, all they need to do is ask their friendly neighborhood Hubot.

    The fact is that software development is not only complex, but it’s done by humans. Errors and mistakes are going to happen. But they should be avoided where they can, and software development processes are often way more complex than they need to be.

  • Developers should be encouraged to work on their own stuff on the side. This has done wonders for Google, whose 20% time policy is now legendary for the products it’s incubated in its lifetime. Github’s policy is seemingly even more liberal, encouraging developers to work on whatever they want to work on just about whenever they want to work on it, even if it doesn’t turn into anything. This has led to a culture of automation, autonomy, and fun. Automation makes the software development cycle faster and more foolproof; autonomy and fun make developers happy and easier to retain. Keeping developers on a tight leash and not allowing them to experiment and innovate is a bad idea, and will only lead to turnover. The best solution is to encourage as much experimentation as you can afford.

While Github might still be a little ahead of the times with some of their ideas, the truth is that most of them are just common sense. And although their recipe to success might not work for your company, adopting some of their principles and ideas can only help.

Oh by the way, I have a Github! Check me out at github.com/jimmysawczuk or on Bitbucket, Github’s mercurial cousin (pun intended) at bitbucket.org/jimmysawczuk.

Originally posted on Cleveland, Curveballs and Common Sense on December 5, 2011 at 9:24 AM. Post text content © 2011 Jimmy Sawczuk. All rights reserved.