Let me first say I'm a big fan of your work and thank you for sharing it with us - I regularly think about the concepts in Grokking Simplicity.
I'll also add to the merits of "Ensemble programming". The company that I have been working for the past 3 years uses this for the release of new features and it works quite well. People frequently feel engaged in what they're doing, that they learn more and are overall more satisfied in their work.
For its negative sides, I'll reinforce the point that was made before that having a solid process is absolutely essential. Just gathering a bunch of people together and say "Deliver me this" won't work.
Besides the danger of personal conflicts and social fatigue I'll add that the opposite is also true. People can become too friendly with each other making it easier to forget disciple and work ethic.
Having said that, I want to question a couple of points.
1. Throughput
I agree with you that using throughput as a metric is a much better indicator of a productive team. But, it must be stressed that it means quality throughput. Not just churning out features for the sake of it.
I think you hinted at this for your next article but I believe quality is the metric that trumps every other.
Specially since in the Software industry, usually the problem isn't delivery time - teams output software like crazy when compared to other fields. I think the biggest problem affecting our industry is that most software is ridden with defects.
So yes, throughput is important but only if quality does not drop.
2. Documentation
I feel like you didn't give enough credit to the effect documentation can have in the productivity of a team. I worry that by saying "More and better documentation helps. But how are those efforts going for you?" will serve as a cop out for people to drop documentation altogether.
When done right, documentation is effectively "Ensemble programming" on steroids. The ensemble being the documents you've produced.
Now, I agree that as an industry, we don't know yet how to write precise and complete documentation that can be leveraged for huge productivity gains. But I believe it can be done.
We can look to Dave Parnas and its work in the Software Reduction Cost project for the US navy. 3 years later and the documents they produced were still being actively maintained, read and most important understood. This was in the 1970's. We could do much better now.
It is my hope that the industry starts to move towards a true engineering and good documentation is always and everywhere the hallmark of good engineering.
Once again, thank you for the articles and I'm looking forward for the new book.
Are there case studies where ensemble programming has been studied and evaluated ? I didn’t find any with a web search, though there are books and articles on the topic.
Hi Eric & all,
Let me first say I'm a big fan of your work and thank you for sharing it with us - I regularly think about the concepts in Grokking Simplicity.
I'll also add to the merits of "Ensemble programming". The company that I have been working for the past 3 years uses this for the release of new features and it works quite well. People frequently feel engaged in what they're doing, that they learn more and are overall more satisfied in their work.
For its negative sides, I'll reinforce the point that was made before that having a solid process is absolutely essential. Just gathering a bunch of people together and say "Deliver me this" won't work.
Besides the danger of personal conflicts and social fatigue I'll add that the opposite is also true. People can become too friendly with each other making it easier to forget disciple and work ethic.
Having said that, I want to question a couple of points.
1. Throughput
I agree with you that using throughput as a metric is a much better indicator of a productive team. But, it must be stressed that it means quality throughput. Not just churning out features for the sake of it.
I think you hinted at this for your next article but I believe quality is the metric that trumps every other.
Specially since in the Software industry, usually the problem isn't delivery time - teams output software like crazy when compared to other fields. I think the biggest problem affecting our industry is that most software is ridden with defects.
So yes, throughput is important but only if quality does not drop.
2. Documentation
I feel like you didn't give enough credit to the effect documentation can have in the productivity of a team. I worry that by saying "More and better documentation helps. But how are those efforts going for you?" will serve as a cop out for people to drop documentation altogether.
When done right, documentation is effectively "Ensemble programming" on steroids. The ensemble being the documents you've produced.
Now, I agree that as an industry, we don't know yet how to write precise and complete documentation that can be leveraged for huge productivity gains. But I believe it can be done.
We can look to Dave Parnas and its work in the Software Reduction Cost project for the US navy. 3 years later and the documents they produced were still being actively maintained, read and most important understood. This was in the 1970's. We could do much better now.
It is my hope that the industry starts to move towards a true engineering and good documentation is always and everywhere the hallmark of good engineering.
Once again, thank you for the articles and I'm looking forward for the new book.
Cheers
Are there case studies where ensemble programming has been studied and evaluated ? I didn’t find any with a web search, though there are books and articles on the topic.