4 ms·

Yegge, as usual, is hyperbole and a half. Don't get me wrong, I like his writing. I liked it more when I was younger, but I still enjoy it. I have to say thoug

by marcusf 15y ago

Yegge, as usual, is hyperbole and a half. Don't get me wrong, I like his writing. I liked it more when I was younger, but I still enjoy it. I have to say though, after working the last 3.5 years in an organization that Yegge would categorize flatly in Bad Agile, first as a developer and now as a PM, that I disagree. Plainly, his hyperbole and name calling doesn't open up for a constructive debate but I'll give it a try. We do iterations, retrospectives and kaizen, automated testing (yes, part of XP), user stories and more. A few people practice TDD or pair programming. Importantly, all of this is voluntary - after five years of experimenting with process, tools, methodology we've found a set of things that work for us and help us deliver software with high quality and on time. It just happens that the tools we use fit in the Agile and XP umbrella. And if we look back five years to the pre-agile days and start looking at delivery times, quality (in terms of defect rates, patch releases, …) and customer satisfaction, they've trended continuously upwards and in a big way. I'm not sure what we're doing wrong and why, and I'd like to have that explained to me.

Jach 15y ago
I'll offer my 6am reasoning-by-analogy commentary in a slightly inflammatory style to keep the mood. Your third paragraph, if you change all the keywords, looks like something a converted Scientologist might say! All your friends tell you it's stupid and give you reasons why you should be unhappy ("Look at how much money you're giving them!") and so forth, but by golly, you look back at your life just a few years ago and things seem so much better now! You don't feel like you're doing anything wrong, and by objective accounts if you're genuinely happier you probably aren't doing anything wrong in the grand scheme of things. Why wouldn't you feel good supporting your Church with huge sums of your income anyway? In short, the brainwashing worked and you're under the influence of a beneficial placebo effect. Maybe the placebo effect is what explains the 10% "success stories" of not-screwed-up Agile Teams that Yegge hints at. Or not. I don't know. I do know that for me any productivity hacks are temporary at best and ineffectual by default, and I'm wary of ones that have been actively dangerous for a good number of people; when akrasia is solved in general humanity will rejoice...
- jmilloy 15y ago
  Unlike "genuine happiness", things like delivery times, defect rates, and numbers of patches seem concrete and easily measurable. (I left customer satisfaction out, but for all I know companies have objective ways to measure this as well.)
- marcusf 15y ago
  Ok but I believe the burden of proof is on you. I'll claim that adhering to some principles has given us quantifiably better results, and that the time scale is long enough that any Hawthrone Effect would've worn out by now. Also, "productivity hack" is not a label I'd use to describe e.g. automated testing. YMMV.
  - jerf 15y ago
    My personal theory on XP, and to a lesser extent Agile, is that about 90%, if not 120%, of the benefit is in the pervasive use of automated testing, and the rest is either marginal in comparison, or even harmful but propped up by the benefit you scored by using automated testing so it all looks net positive in the end. (Hence the 120%; the benefit of just using automated testing is indeed greater than the whole package.) I can't prove it. And I do like iterations in the sense of "produce a deliverable product every N weeks" for keeping you from wandering too far down the wrong path, though from what I've seen one of the most popular things to do with agile is just break your calender up by "iterations" then keep doing the same thing you did before. It's sort of hard to get a real sense of the utility of agile because hardly anybody really seems to really try it. (I do not necessarily think every aspect of it should be kept, but much of what it proposes is at least worth a real try. And "trying" shouldn't be a matter of smearing new words over the same procedures.)
  - pdubroy 15y ago
    Actually, the burden of proof should be on you. The null hypothesis is that adhering to agile principles has no positive affect on the outcome of software projects. In order to show that these principles have worth, you should disprove the null hypothesis.
nswanberg 15y ago
In the past six years or so since this was written, Greg Wilson has advocated gathering data on this and other programming related topics (watch http://vimeo.com/9270320 http://vimeo.com/9270320 if you have an hour, or get a flavor for the arguments here http://blog.stackoverflow.com/2011/06/se-podcast-09/ http://blog.stackoverflow.com/2011/06/se-podcast-09/), and has compiled a book of essays (with research) on the topic: http://www.amazon.com/Making-Software-Really-Believe-ebook/dp/B004D4YI6G http://www.amazon.com/Making-Software-Really-Believe-ebook/d... I haven't yet read the book, and so don't know it's conclusions, if any, on the various methodologies, but if you're curious about research in the area it would be a great start. The other thing worth pointing out is that, while the Google Yegge describes in the essay might be different in 2012 than it was in 2006, it's still a different level of organization than even the average software development company, let alone a non-software company that happens to employ internal or contract developers. And Steve is writing about developing within Google.
- marcusf 15y ago
  Thanks, but I've seen Gregs talk and the book has been on my short list for a while. I whole heartedly agree with trying to bring some science to the table. However, in lieu of any research on the subject and given the tools at our disposal right now, we can only look at the metrics we have and draw conclusions from them. Also, I disagree that Yegge discusses Google in particular. Sure, he blabbers on about how great Google is, but he dismisses agile methods outright. FWIW, the Googlers I know don't tell the same rosy picture about the place. What Google is seems to vary quite a bit with where you are and on what project.

by marcusf 15y ago

Jach 15y ago

I'll offer my 6am reasoning-by-analogy commentary in a slightly inflammatory style to keep the mood. Your third paragraph, if you change all the keywords, looks like something a converted Scientologist might say! All your friends tell you it's stupid and give you reasons why you should be unhappy ("Look at how much money you're giving them!") and so forth, but by golly, you look back at your life just a few years ago and things seem so much better now! You don't feel like you're doing anything wrong, and by objective accounts if you're genuinely happier you probably aren't doing anything wrong in the grand scheme of things. Why wouldn't you feel good supporting your Church with huge sums of your income anyway? In short, the brainwashing worked and you're under the influence of a beneficial placebo effect. Maybe the placebo effect is what explains the 10% "success stories" of not-screwed-up Agile Teams that Yegge hints at. Or not. I don't know. I do know that for me any productivity hacks are temporary at best and ineffectual by default, and I'm wary of ones that have been actively dangerous for a good number of people; when akrasia is solved in general humanity will rejoice...

jmilloy 15y ago
Unlike "genuine happiness", things like delivery times, defect rates, and numbers of patches seem concrete and easily measurable. (I left customer satisfaction out, but for all I know companies have objective ways to measure this as well.)
marcusf 15y ago
Ok but I believe the burden of proof is on you. I'll claim that adhering to some principles has given us quantifiably better results, and that the time scale is long enough that any Hawthrone Effect would've worn out by now. Also, "productivity hack" is not a label I'd use to describe e.g. automated testing. YMMV.
- jerf 15y ago
  My personal theory on XP, and to a lesser extent Agile, is that about 90%, if not 120%, of the benefit is in the pervasive use of automated testing, and the rest is either marginal in comparison, or even harmful but propped up by the benefit you scored by using automated testing so it all looks net positive in the end. (Hence the 120%; the benefit of just using automated testing is indeed greater than the whole package.) I can't prove it. And I do like iterations in the sense of "produce a deliverable product every N weeks" for keeping you from wandering too far down the wrong path, though from what I've seen one of the most popular things to do with agile is just break your calender up by "iterations" then keep doing the same thing you did before. It's sort of hard to get a real sense of the utility of agile because hardly anybody really seems to really try it. (I do not necessarily think every aspect of it should be kept, but much of what it proposes is at least worth a real try. And "trying" shouldn't be a matter of smearing new words over the same procedures.)
- pdubroy 15y ago
  Actually, the burden of proof should be on you. The null hypothesis is that adhering to agile principles has no positive affect on the outcome of software projects. In order to show that these principles have worth, you should disprove the null hypothesis.

nswanberg 15y ago

In the past six years or so since this was written, Greg Wilson has advocated gathering data on this and other programming related topics (watch http://vimeo.com/9270320 http://vimeo.com/9270320 if you have an hour, or get a flavor for the arguments here http://blog.stackoverflow.com/2011/06/se-podcast-09/ http://blog.stackoverflow.com/2011/06/se-podcast-09/), and has compiled a book of essays (with research) on the topic: http://www.amazon.com/Making-Software-Really-Believe-ebook/dp/B004D4YI6G http://www.amazon.com/Making-Software-Really-Believe-ebook/d... I haven't yet read the book, and so don't know it's conclusions, if any, on the various methodologies, but if you're curious about research in the area it would be a great start. The other thing worth pointing out is that, while the Google Yegge describes in the essay might be different in 2012 than it was in 2006, it's still a different level of organization than even the average software development company, let alone a non-software company that happens to employ internal or contract developers. And Steve is writing about developing within Google.

marcusf 15y ago
Thanks, but I've seen Gregs talk and the book has been on my short list for a while. I whole heartedly agree with trying to bring some science to the table. However, in lieu of any research on the subject and given the tools at our disposal right now, we can only look at the metrics we have and draw conclusions from them. Also, I disagree that Yegge discusses Google in particular. Sure, he blabbers on about how great Google is, but he dismisses agile methods outright. FWIW, the Googlers I know don't tell the same rosy picture about the place. What Google is seems to vary quite a bit with where you are and on what project.