Live data from Hacker News

The Programmer's Dilemma

raganwald.posterous.com

41–50 of 53 posts

Re: The Programmer's Dilemma

#41
"Theory P methodologies like XP and Scrum constantly recalibrate expectations, so if the result is dissapointing, you are left blaming the inelasticity of space-time. An alternate version of this story had the protagonists choosing a methodology for a risky project: Choosing Waterfall was defecting and choosing Agile was coöperating."

I'm sorry, but measured against the number of times I've heard the phrase "Doing Agile Wrong", this sound disingenuous.

Re: The Programmer's Dilemma

#42

Somewhat off topic, but I am reminded of a paper I had to critique a uni: "A Rational Design Process: How and Why to Fake It" [1] The paper reasons that following a strict process is unrealistic, but that it is still worth it to "fake" a process, by presenting your system to others as though you had followed it (for example through documentation and reports that mimic the waterfall process, presented to players such…

I worked on a project for a large corporation where the manager running the project did this. I thought he was insane until it became clear that the fake process created an umbrella for the devs to self-organize under. It wasn't a perfect project but it went better than it would have if the process had been real.

Re: The Programmer's Dilemma

#43

"Theory P methodologies like XP and Scrum constantly recalibrate expectations, so if the result is dissapointing, you are left blaming the inelasticity of space-time. An alternate version of this story had the protagonists choosing a methodology for a risky project: Choosing Waterfall was defecting and choosing Agile was coöperating." I'm sorry, but measured against the number of times I've heard the phrase "Doing Ag…

I've heard "Doing Agile Wrong" too, however I think what the post is talking about is when the participants accuse each other of doing it wrong, which is different than when an outsider says an entire project was done wrong.

So for example, if I say "We tried Scrum, and it didn't work," and some evangelist tries to defend the project and says "You did it wrong," that is not the same as when I say, "We tried Scrum, our Team was fine, but the Product Owner did it wrong and that's why we failed."

I can't speak to what you've heard, but I certainly have heard a lot of the former, to the point where I reply to all such discussions with a pointer to the No True Scotsman fallacy:

"Agile works."

"No it doesn't, we tried it and failed."

"You did it wrong."

Compare and contrast to:

"Scotsmen are cheap bastards, Ne'er would you catch one standing a round."

"Hamish just bought me a dram of Lagavulin."

"Hamish may have Scots parents, but he lives in Toronto. No True Scotsman would stand a round."

Re: The Programmer's Dilemma

#44
post #37
post #24

Earlier quoted context omitted.

No, you're still missing it. In Prisoner's Dilemma, if they both cooperate they still get a bad outcome. It is globally the least bad, but individually worse for each of them than defecting if the other cooperates. Look at the payoff matrix: [1] If mutual cooperation was the best outcome, there would be no dilemma . [1]: http://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_f...

In that matrix, total time served if they remain loyal is 2 months (one month for each of them). If one of them betrays the other, total time served is 1 year (for one of them while the other goes free). If they both betray, total time served is 6 months (3 for each of them). So it seems to me that if they both remain silent, that is the best aggregate outcome. However, it isn't always the case that someone will auto…

"Sometimes if they both remain loyal, they can't be charged with anything."

It's important to not bring too much real-world logic to the matter. What's being discussed is a certain payoff matrix; the "story" of the Prisoner's Dilemma is really just a way to try to wrap the non-math part of your brain around it, but the payoff matrix, exactly as written, is what is under discussion. The payoff matrix where there is a non-zero probability that they will both manage to skate is a different problem, one not necessarily less worthy of discussion, but one that is not the Prisoner's Dilemma any longer.

If you are interested in further discussion, you should google "Iterated Prisoner's Dilemma" for more fun, including stories about computer simulations of various strategies. Prisoner's Dilemma on its own isn't actually all that interesting, it's more useful as a framing device. Iterated Prisoner's Dilemma is actually interesting.

Re: The Programmer's Dilemma

#45
post #44
post #37

Earlier quoted context omitted.

In that matrix, total time served if they remain loyal is 2 months (one month for each of them). If one of them betrays the other, total time served is 1 year (for one of them while the other goes free). If they both betray, total time served is 6 months (3 for each of them). So it seems to me that if they both remain silent, that is the best aggregate outcome. However, it isn't always the case that someone will auto…

"Sometimes if they both remain loyal, they can't be charged with anything." It's important to not bring too much real-world logic to the matter. What's being discussed is a certain payoff matrix; the "story" of the Prisoner's Dilemma is really just a way to try to wrap the non-math part of your brain around it, but the payoff matrix, exactly as written, is what is under discussion. The payoff matrix where there is a…

Actually, I've had a college class on "Negotiation and Conflict Management" where stuff like Prisoner's Dilemma was covered fairly well. I cleaned up in the negotiation rounds at the end of class, so I suspect my understanding of the concepts we were taught is just fine. But you and I appear to be talking at cross purposes.

Peace.

Re: The Programmer's Dilemma

#46
post #32

A colleague of mine - his wife was a 3rd grade teacher. One day, he mentioned to her the process that we were doing. And she laughed. She showed him the daily progress report. "What I did today? What I want to do tomorrow?" That her 3rd graders had to fill out everyday. Are programmers adults that need to be self-managed + micro-managed like 3rd graders?

They asked me in school what I wanted be when I grew up, I wrote "happy", they told me I didn't understand the assignment, I told them they didn't understand life.

--John Lennon

Re: The Programmer's Dilemma

#47
post #46
post #32

Earlier quoted context omitted.

They asked me in school what I wanted be when I grew up, I wrote "happy", they told me I didn't understand the assignment, I told them they didn't understand life.

--John Lennon

nice. I thought it was John Lennon but I couldn't find a reliable attribution.

Re: The Programmer's Dilemma

#48

"Theory P methodologies like XP and Scrum constantly recalibrate expectations, so if the result is dissapointing, you are left blaming the inelasticity of space-time. An alternate version of this story had the protagonists choosing a methodology for a risky project: Choosing Waterfall was defecting and choosing Agile was coöperating." I'm sorry, but measured against the number of times I've heard the phrase "Doing Ag…

I've heard "Doing Agile Wrong" too, however I think what the post is talking about is when the participants accuse each other of doing it wrong, which is different than when an outsider says an entire project was done wrong. So for example, if I say "We tried Scrum, and it didn't work," and some evangelist tries to defend the project and says "You did it wrong," that is not the same as when I say, "We tried Scrum, ou…

So if I'm reading this right:

If a project that uses Agile fails, the participants have no incentive to blame each other.

If a project that uses Waterfall fails, the participants have an incentive to blame each other.

Because Waterfall in the failure case gives people an incentive to blame each other, it's a poorer methodology than Agile.

If I haven't confused your argument, then the weakness is that you have not shown that Agile is a methodology in which people have no incentive (or ability) to blame each other if the project fails.

Re: The Programmer's Dilemma

#49

Earlier quoted context omitted.

I've heard "Doing Agile Wrong" too, however I think what the post is talking about is when the participants accuse each other of doing it wrong, which is different than when an outsider says an entire project was done wrong. So for example, if I say "We tried Scrum, and it didn't work," and some evangelist tries to defend the project and says "You did it wrong," that is not the same as when I say, "We tried Scrum, ou…

So if I'm reading this right: If a project that uses Agile fails, the participants have no incentive to blame each other. If a project that uses Waterfall fails, the participants have an incentive to blame each other. Because Waterfall in the failure case gives people an incentive to blame each other, it's a poorer methodology than Agile. If I haven't confused your argument, then the weakness is that you have not sho…

My claim is that if a project that uses Agile fails, the participants still have an incentive in dysfunctional cultures to blame each other, it's just that the structure of Agile makes it harder to blame individuals. So I am not claiming that A is better than W or W is better than A at shipping software, I am claiming that W is better than A at blaming people for failures.

I might have confused the issue by trying to draw a distinction between blaming the process from the inside and from the outside. My claim is that it is much easier to blame a process if you aren't a participant in a failing process. For this reason, it is easier to evangelize a new process of any type as a consultant or as a new face than it is if you are an old hand who may be accused of having been a cause of previous failures.

I think this second point is true of any process.

Re: The Programmer's Dilemma

#50

Earlier quoted context omitted.

So if I'm reading this right: If a project that uses Agile fails, the participants have no incentive to blame each other. If a project that uses Waterfall fails, the participants have an incentive to blame each other. Because Waterfall in the failure case gives people an incentive to blame each other, it's a poorer methodology than Agile. If I haven't confused your argument, then the weakness is that you have not sho…

My claim is that if a project that uses Agile fails, the participants still have an incentive in dysfunctional cultures to blame each other, it's just that the structure of Agile makes it harder to blame individuals. So I am not claiming that A is better than W or W is better than A at shipping software, I am claiming that W is better than A at blaming people for failures. I might have confused the issue by trying to…

Can you explain how the structure of Agile makes it harder to blame individuals?
Post reply on HN