6 ms·

Developer-driven development

97 points by mcantelon 16y ago

ulf 16y ago
"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.
semanticist 16y ago
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 16y ago
  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.
wccrawford 16y ago
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
- generalk 16y ago
  > I can't help but think this requires that only 'rock star' programmers be on the team. "Rock star" developer can mean a lot of things. What's required here (aside from everything listed in the prerequisite section of the slides) is that developers have a sense of ownership of the product. That's it. You can foster this by literally giving them percentage shares of ownership. Some developers naturally feel this way about everything they ship. Some developers will never feel this way unless they own a majority interest in the software.
  - deleted 16y ago
    [deleted]
- kneath 16y ago
  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.
  - Stormbringer 16y ago
    looks interesting, thanks for the tip
  - ericlavigne 16y ago
    > 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 http://www.ted.com/talks/dan_pink_on_motivation.html
- ianl 16y ago
  Using "rockstar" reminds me of awful job advertisements for awful companies.
- pskomoroch 16y ago
Ysx 16y ago
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.
- technoweenie 16y ago
  Showoff is designed to give presentations. Though it can output slides in a single page or as PDF for sharing with people.
- jchrisa 16y ago
  Couldn't get it to work on iOS.
  - technoweenie 16y ago
    Weird, I added swipe events to Showoff awhile ago. Maybe the running instance is just on an old version.
    - yesbabyyes 16y ago
      On my Android phone, swiping would advance lots of pages - first two, then ten, then forty.
      - j_baker 16y ago
        Same here on the iPad.
        technoweenie 16y ago
        https://github.com/technoweenie/jquery.doubletap https://github.com/technoweenie/jquery.doubletap if you'd like to file any patches, bug reports, etc.
- biot 16y ago
  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.
weixiyen 16y ago
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.
fleitz 16y ago
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.
twymer 16y ago
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".
- shade 16y ago
  Man, I was at CodeMash, but missed that keynote since I had to run an errand over lunch (kinda needed new hearing aid batteries). I'm kinda bummed that I missed it given the volume of discussion that it generated. Did you happen to hit Joe Nuxoll's user experience session on Friday? That was probably the high point of the conference for me -- tons of useful info.
  - twymer 16y ago
    Yeah, the room was packed when I got there.. sat in the front on the floor for it. Definitely the most useful of everything I saw there.
- tbrownaw 16y ago
  > 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. Does this actually apply to employer-sponsored OSS work?
deleted 16y ago
[deleted]
ghkyudfe 16y ago
====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== Gold autumn, personality Mes clothing + Shoes, Travel bag that grabs an eye coat + Chao packet Free transport ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )====
kikibobo69 16y ago
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 16y ago
  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 16y ago
    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.
wpeterson 16y ago
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 16y ago
Thinking about self-motivation goes back to the 1960s: https://secure.wikimedia.org/wikipedia/en/wiki/Theory_X_and_theory_Y https://secure.wikimedia.org/wikipedia/en/wiki/Theory_X_and_...
schacon 16y ago
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 16y ago
  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.
widgetycrank 16y ago
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.
mariani 16y ago
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 16y ago
  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.
aneth 16y ago
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.
- wpeterson 16y ago
  +1 on the thesis - developers expert in the product, using the product. To me this should be the real goal and take-away from this article, not the many nice things this enables, but how to get there for other companies/products. THAT would be revolutionary.
- lucisferre 16y ago
  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.

97 points by mcantelon 16y ago

ulf 16y ago

"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.

semanticist 16y ago

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 16y ago
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.

wccrawford 16y ago

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

generalk 16y ago
> I can't help but think this requires that only 'rock star' programmers be on the team. "Rock star" developer can mean a lot of things. What's required here (aside from everything listed in the prerequisite section of the slides) is that developers have a sense of ownership of the product. That's it. You can foster this by literally giving them percentage shares of ownership. Some developers naturally feel this way about everything they ship. Some developers will never feel this way unless they own a majority interest in the software.
- deleted 16y ago
  [deleted]
kneath 16y ago
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.
- Stormbringer 16y ago
  looks interesting, thanks for the tip
- ericlavigne 16y ago
  > 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 http://www.ted.com/talks/dan_pink_on_motivation.html
ianl 16y ago
Using "rockstar" reminds me of awful job advertisements for awful companies.
pskomoroch 16y ago

Ysx 16y ago

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.

technoweenie 16y ago
Showoff is designed to give presentations. Though it can output slides in a single page or as PDF for sharing with people.
jchrisa 16y ago
Couldn't get it to work on iOS.
- technoweenie 16y ago
  Weird, I added swipe events to Showoff awhile ago. Maybe the running instance is just on an old version.
  - yesbabyyes 16y ago
    On my Android phone, swiping would advance lots of pages - first two, then ten, then forty.
    - j_baker 16y ago
      Same here on the iPad.
      - technoweenie 16y ago
        https://github.com/technoweenie/jquery.doubletap https://github.com/technoweenie/jquery.doubletap if you'd like to file any patches, bug reports, etc.
biot 16y ago
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.

weixiyen 16y ago

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.

fleitz 16y ago

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.

twymer 16y ago

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".

shade 16y ago
Man, I was at CodeMash, but missed that keynote since I had to run an errand over lunch (kinda needed new hearing aid batteries). I'm kinda bummed that I missed it given the volume of discussion that it generated. Did you happen to hit Joe Nuxoll's user experience session on Friday? That was probably the high point of the conference for me -- tons of useful info.
- twymer 16y ago
  Yeah, the room was packed when I got there.. sat in the front on the floor for it. Definitely the most useful of everything I saw there.
tbrownaw 16y ago
> 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. Does this actually apply to employer-sponsored OSS work?

deleted 16y ago

[deleted]

ghkyudfe 16y ago

====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== Gold autumn, personality Mes clothing + Shoes, Travel bag that grabs an eye coat + Chao packet Free transport ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )==== ====== ( http://u.ly/73I http://u.ly/73I )====

kikibobo69 16y ago

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 16y ago
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 16y ago
  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.

wpeterson 16y ago

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 16y ago

Thinking about self-motivation goes back to the 1960s: https://secure.wikimedia.org/wikipedia/en/wiki/Theory_X_and_theory_Y https://secure.wikimedia.org/wikipedia/en/wiki/Theory_X_and_...

schacon 16y ago

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 16y ago
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.

widgetycrank 16y ago

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.

mariani 16y ago

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 16y ago
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.

aneth 16y ago

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.

wpeterson 16y ago
+1 on the thesis - developers expert in the product, using the product. To me this should be the real goal and take-away from this article, not the many nice things this enables, but how to get there for other companies/products. THAT would be revolutionary.
lucisferre 16y ago
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.