

Developer-driven development - mcantelon
http://schacon.github.com/ddd

======
schacon
I'll probably write a blog post laying this out a bit more clearly, but
responding to a few of the comments here:

* I don't think 'rock star' programmers is important. I think that most programmers got into the game because they love programming, not because it's what they _have_ to do. There are exceptions, but I believe that more programmers love doing it then have to do it. The point is to setup an environment where you as an employer can get the most out of people of a range of talent simply by setting up an environment that motivates in the best way possible - through autonomy, mastery and purpose. I think people that don't seem passionate will become more passionate if given the freedom.

* to be clear, i said every 'developer' makes the same. or, better said, every role makes the same - there are roles that make different amounts, but it's still pretty flat and people are not individually offered different salaries by some subjective determination of their merit, but rather equally by the general role they are hired to do. it so happens that most of our employees are either developers or designers and they're all paid the same out of simplicity. the main point is that salary is less important than environment.

* finally, i'm not saying that the way that github does it is the way that you should do it - we have the difference of the C-suite being open source developers, so it's easier for us. the point is that even this somewhat radical example works surprisingly well, and that if you try to optimize for autonomy and purpose in the lives and working environment of your developers that it will most likely result in a much more productive output.

again, i'll try to do a more comprehensive post on what i specifically was
talking about, rather then just the slides out of context, but i wanted to
quickly address some of the comments. thanks! also, it was a blast doing the
keynote, so thanks to everyone that attended and argued about it after.

~~~
enry_straker
I suspect that you talk from experience when you make the claim that 'Most
programmers got into the game because they love programming.' I currently work
in india, and my experience here is that most folks who enter programming do
so because of better pay, more glamour, and more international travel. I don't
have any studies to back up my observation, just my personal experiences in
the last few years.

I also believe that their training/exposure to CS in college is not uniformly
good, and that they are put into an environment where they are already
expected to know stuff which they have not been exposed to. Good organizations
spend quite some time on training, but many do not.

I personally believe that before a programmer is given autonomy, it is vitally
important to have people with good, attitudes who are willing to admit to
mistakes and learn constantly, who have some measure of comfort with the
fundamentals of programming ( which works across languages ), and who are
mentored properly ( by which they have people to turn to whenever they get
struck and need to figure out how to proceed further ). Most middle managers
have no clue as to what programming is and hide behind a layer of techno-talk
and they really are often unable to provide a sense of direction or purpose to
the programmer.

While i agree with your role for management in creating a good environment for
your emplyees, giving them a lot of autonomy, allowing them to master their
tools, and having a sense of shared purpose, i believe that these require a
few fundamentals to be met before the above environment is productive.

I admit that these observations are biased and not based on any scientific
studies, so take them with a pinch of salt.

------
twymer
I was at this talk (given at CodeMash a few days ago). It spurred a lot of
discussion/opposition over the fact that it revolves so heavily around only
hiring passionate, rock star quality developers that care about the product
you're developing.

Small companies and startups often have a product that you can recruit people
who are passionate enough about the idea that stuff like this can work out.
The problem for discussion is more based on which (if any) of these ideas can
be applied to a large corporation where the developers are working on
insurance or financial software etc.

Some things that are lost for those only reading slides:

\- His main reasons behind this "DDD" policy is that it's the open source
model. Developers work on things they care about, when they feel like working
and then every hour they spend "working" is a valuable hour of work. Any
policy that forces or even simply guilts people into a set schedule or number
of hours causes unproductive time and a loss of developer happiness/autonomy.

\- He strongly advocates removing money as a motivator. At github apparently
every employee makes the same salary.

\- The "no vacations" comment comes from him not believing you should track
vacations. Employees should but trusted and able to take the time off they
deem appropriate.

\- At github, the Google "20% policy" is taken to an extreme. People can work
on whatever they want on "company time".

~~~
whatusername
I'd be curipous to see how the "No vacations" rule plays out..

In Australia most employees would deem 4 weeks vacation as appropriate. In
France it's probably higher. In the US -- maybe it's 2 or 3 weeks.

~~~
kneath
Stop tracking what days people are working & what days they aren't and you'll
realize you've missed the whole point of "no vacations"

We don't have vacations because we judge people by what they _do_ — not how
often they're working.

------
wccrawford
I can't help but think this requires that only 'rock star' programmers be on
the team. 1 bad apple would start to throw everything off, and a few could
derail it.

It also requires that everyone have the same vision, or you end up with a very
fragmented product, see as how you allow each developer to decide what to work
on.

Don't get me wrong, I would love to work at a company that is succeeding at
this... I just can't imagine how to keep it succeeding.

Seeing as how it requires the developers to act like they have a stake in the
company, perhaps a better title would have been: Driven Developer-Driven
Development

~~~
kneath
I dunno about 'rock star' (although I'm a pretty amazing drummmer…) but yes,
the talk centers around hiring the most driven people possible. I don't think
any of us act like we have a stake in the company — we do.

I'd highly suggest reading Drive by Daniel Pink. The entire book is about how
people are motivated. It would definitely answer almost all the points listed.

~~~
ericlavigne
> I'd highly suggest reading Drive by Daniel Pink.

This video shows Daniel Pink delivering an 18-minute presentation at TED on
the same topic: <http://www.ted.com/talks/dan_pink_on_motivation.html>

------
Ysx
Ah, it's a slideshow without mouse controls. Felt stupid for a good five
minutes while testing in various browsers, just trying to get /something/ to
work. Not a great experience.

~~~
biot
Not to mention that using the left and right arrow keys pushes the current
page onto your browser history which is unnecessary. It's far easier to go
back/forward with the arrow keys you're already using, plus it'd be nice to be
able to click the browser's back button to return to the site that linked to
the presentation.

~~~
bluesnowmonkey
The hash tags let you link to specific slides.

------
ulf
"keep your devs [...] always working on something they want"

this seems to be the uber-rule for everyone who employs a developer. If you
can guarantee that one (granted, it's huge) requirement, you should not get
into trouble with your engineering workforce. All other things might not
automatically fall into place, but once you got your people motivated through
their work, a big part is in good care.

------
weixiyen
The reason why there are so many startups is because most people want to work
on ideas that they conceive. People love to create something of their own.

If a company allows their workers to choose the features they work on,
programmers will automatically take ownership and immerse themselves in the
product. Most developers I know are bored out of their mind when working on
someone else's idea, although there are a few exceptions.

There's really not much more to be said on this topic imo.

------
semanticist
Slides are nice, but a video or a transcript of the talk would be a lot more
useful. Does anyone know where this talk was given? The title is too generic
for my Google skills.

~~~
steiza
This was a lunch keynote at codemash.org on January 14th, 2011, although it
may not have been the first time it was given.

For any HN'ers in the midwest, CodeMash is an awesome polygot conference that
takes place January every year in Sandusky, Ohio. I've never been at any other
conference where you meet experts in Python, Ruby, Haskel, and other languages
in the same session.

------
wpeterson
This is a cool model, but I worry it only works because software engineers are
both the producers and the consumers of the github product.

The real take-away for me was less their means than how much freedom/less
process you can get when the engineers completely understand the goals of your
users.

Getting to that point feels like the hard part. Github is lucky to produce a
tool central to their developers existing lives.

------
raganwald
Thinking about self-motivation goes back to the 1960s:

[https://secure.wikimedia.org/wikipedia/en/wiki/Theory_X_and_...](https://secure.wikimedia.org/wikipedia/en/wiki/Theory_X_and_theory_Y)

------
kikibobo69
Developing products for the mass market requires a lot of grunt work, and even
with a totally dedicated technical team, still needs somebody or -bodies to
compel them to do some of the boring things, fix the unfixable bugs that
actually affect non-technical users, etc.

So, while I guess I can imagine this working (and me loving) for products
geared toward a highly technical, somewhat forgiving customer base, I don't
see this as a workable for anything truly consumer-focused.

~~~
j_baker
I think you're missing the point. He's not saying that developers want to be
thrilled to death every minute of their careers. He's saying that developers
want autonomy and the ability to make something cool. The problem is that all
but the very best managers seem to assume that management letting up on the
reins means people going crazy and wreaking havoc.

The best managers understand that management is mostly a two-step process:

1\. Give someone a task. 2\. Let them accomplish that task.

Granted, you can't always work that way. But you might be surprised at what
proper motivation can do. People will do boring work if it means accomplishing
something great.

~~~
kikibobo69
Which slide was THAT on?

I'm reacting to slides like: "individuals choose what they want to work on"
which is all fine & well, except that sometimes, if we want to ship in time
for Christmas, people might have to work on what they wouldn't naturally
choose.

------
mariani
All very nice but based on my 5 year of project management, I'm fairly
confident to say that organizing work like this will only be successful with a
lot of luck. Every project or every product that gets developed has a moment
where "things go wrong"(tm) and having external constraints (like deadlines,
backlogs, ...) reduces the risk of failure ... a lot. I'd only try the
approach from the presentation if your team is made up out of very
disciplined, skilled people with the full benefits and responsibilities of the
outcome.

~~~
lucisferre
I'm fairly certain their team (or any team like this) has little or no need
for a project manager so I doubt they would need to worry about whether or not
you would try it.

I realize this comes across a bit snarky but I honestly couldn't think of a
better way to say this. I often find people in project management who have
little or no trust in the people who actually do the work and that seems to
guide their decisions about how the team should be 'managed' or how the work
should be planned.

I also find that while deadlines and backlogs seem like something intuitive,
in the end the belief that they really have a tangible effect on outcomes
seems to be largely anecdotal. Sure it's often a necessary requirement to work
with many organizations, but I rarely see any of those organizations actually
backing up their process with measurable results.

------
widgetycrank
I wonder how designers fit into this development process. Most open source
projects lack UI polish, yet GitHub looks like it's crafted by a professional.

------
fleitz
I think that all the arguments against it assume that management automatically
has a better vision for the product than dev. I think dev also recognizes
their falliability in choosing which features to develop so hopefully they'd
do it according to A/B testing or other more scientifically sound methods for
feature selection.

------
aneth
It's no surprise that developers can self-manage the development of a source
code tool. However this model is unlikely to work in any other space since the
product requirements will not be in the domain expertise of the engineers.
Github employees use the product all day in the process of developing it -
this is true for hardly any products. Imagine engineers trying to self-manage
the development of an ERP system - the resulting product would be unlikely to
solve real customer problems.

Other than that, it sounds like fun.

~~~
lucisferre
Lots of great products are made by teams of only developers and designers all
the time.

I think the real question is why do such low quality products get produced by
business when building LOB apps to solve "real" customer problems. In my
opinion it is too much interference in the communication chain between the
customer and the devs designers and that is usually a management problem.

