Live data from Hacker News

Agile is a Sham

williamedwardscoder.tumblr.com

181–189 of 189 posts

Re: Agile is a Sham

#181

Earlier quoted context omitted.

That's not obviously true to me. Any professional has some process, explicit or implicit: it's the observable regularities in the way they work. Any team is going to have some explicit process, because there's no way people will converge on the maximally effective way of working together without some discussion. So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an exte…

So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient. Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else i…

I agree that nobody should focus solely on getting better at, say, Agile. I also agree we should work hard at getting better at programming.

However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you're screwed. Ditto if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.

I also think you're creating a bit of a false dichotomy. When I first tried XP, it wasn't for the sake of doing XP. It was because I wanted to improve how we made things for our users. So exploring XP wasn't tangential to better programming; for me it was closely related, in that programming was a big part of making.

Re: Agile is a Sham

#182

Earlier quoted context omitted.

You start out with a giant misunderstanding, which makes it hard for me to take the rest of your complaints seriously. Extreme Programming is not an arbitrary desire to turn all the knobs you can find to 11. It started as a question: what happens if we take certain practices that are good and do them more intensely? E.g. if some testing is good, what if we test pretty much everything? That team found that they really…

Extreme Programming is not an arbitrary desire to turn all the knobs you can find to 11. It started as a question: what happens if we take certain practices that are good and do them more intensely? E.g. if some testing is good, what if we test pretty much everything? That team found that they really liked turning particular practices way up. Well, of course they're entitled to their opinion, but that's all it is: an…

An argument that if some testing is good then test-driving everything must be better, or that if code review is good then full-time review via pair programming must be better, has no basis in logic.

That's not the argument at all. That is, as I just said, the reason they decided to try that. Their reasons for continuing to do it and further to recommend it are entirely different.

[...] better have rock solid empirical data [...]

You do realize that almost everything that goes on in the industry is not based on rock-solid empirical evidence, right? And also, that you're privileging an arbitrary historical accident by saying that new thing X has to have evidence when the common practice doesn't?

If you came into an environment like that, and only "professional" thing to do was to [...] make up a few test cases as you went along and trust that your code was OK [...]

That is not something I have ever heard any Object Mentor person say, and it's not something I said. It's so far from what I've ever heard somebody like Bob Martin or Kent Beck say that your misunderstanding is so dramatic that I have a hard time believing it's not willful.

I prefer to keep debates that start on a public forum out in the open.

Well, I'm not trying to have a debate. If you'd like to have one, you'll have to do it without me.

Re: Agile is a Sham

#183

Earlier quoted context omitted.

So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient. Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else i…

I agree that nobody should focus solely on getting better at, say, Agile. I also agree we should work hard at getting better at programming. However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you'r…

... if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.

That's impossible.

Re: Agile is a Sham

#184

Earlier quoted context omitted.

I agree that nobody should focus solely on getting better at, say, Agile. I also agree we should work hard at getting better at programming. However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you'r…

... if you have a bunch of individuals doing great programming that doesn't add up to a functioning project. That's impossible.

A) It's kind of irritating for you to ignore everything except the one thing you'd like to argue with.

B) Unless you have some mathematical proof of what I'm unaware, I believe you mean, "I don't understand how that could be the case."

Re: Agile is a Sham

#185

Earlier quoted context omitted.

Extreme Programming is not an arbitrary desire to turn all the knobs you can find to 11. It started as a question: what happens if we take certain practices that are good and do them more intensely? E.g. if some testing is good, what if we test pretty much everything? That team found that they really liked turning particular practices way up. Well, of course they're entitled to their opinion, but that's all it is: an…

An argument that if some testing is good then test-driving everything must be better, or that if code review is good then full-time review via pair programming must be better, has no basis in logic. That's not the argument at all. That is, as I just said, the reason they decided to try that. Their reasons for continuing to do it and further to recommend it are entirely different. [...] better have rock solid empirica…

Their reasons for continuing to do it and further to recommend it are entirely different.

So you keep saying. The problem is, almost everything Object Mentor advocate does seem to be based on some combination of their personal experience and pure faith. I object to someone telling me that my colleagues and I are "unprofessional" because we happen to believe differently, particularly when we do have measurable data that shows our performance is significantly better than the industry average.

You do realize that almost everything that goes on in the industry is not based on rock-solid empirical evidence, right?

That may be so, but most people in the industry aren't telling me how to do my job, and insulting me for not believing the same things they do.

That is not something I have ever heard any Object Mentor person say, and it's not something I said.

Good for you. XP consultants have been making essentially that argument, in public, for many years. TDD without any planning ahead is inherently a trial-and-error approach, which fails spectacularly in the absence of understanding as Jeffries so wonderfully demonstrated. Plenty of consultants -- including some of those from Object Mentor -- have given various arbitrary amounts of time they think you should spend on forward planning before you dive into TDD and writing real code, and often those periods have been as short as half an hour. You may choose not to believe that if you wish. I'm not sure even they really believe it any more, as they've backpeddled and weasel-worded and retconned that whole issue repeatedly in their recent work. But I've read the articles and watched the videos and sat in the conference presentations and heard them make an argument with literally no more substance than what I wrote there.

You keep saying that I'm misunderstanding or cherry-picking evidence. Perhaps that is so and I really am missing something important in this whole discussion. However, as far as I can see, throughout this entire thread you haven't actually provided a single counterexample or alternative interpretation of the advice that consultants like those at Object Mentor routinely and publicly give. You're just saying I'm wrong, because, and there's not really anything I can say to answer that.

Re: Agile is a Sham

#186

Earlier quoted context omitted.

... if you have a bunch of individuals doing great programming that doesn't add up to a functioning project. That's impossible.

A) It's kind of irritating for you to ignore everything except the one thing you'd like to argue with. B) Unless you have some mathematical proof of what I'm unaware, I believe you mean, "I don't understand how that could be the case."

except the one thing you'd like to argue with.

It's the part of your comment I think is crazy. Of course I'm going to comment on that in particular.

I believe you mean, "I don't understand how that could be the case."

No, I don't. Professional programmers get paid to release working software to their users. If they haven't done that, they haven't done any "great programming". They probably did some clever coding while they failed, but it wasn't great programming.

Re: Agile is a Sham

#187

Earlier quoted context omitted.

An argument that if some testing is good then test-driving everything must be better, or that if code review is good then full-time review via pair programming must be better, has no basis in logic. That's not the argument at all. That is, as I just said, the reason they decided to try that. Their reasons for continuing to do it and further to recommend it are entirely different. [...] better have rock solid empirica…

Their reasons for continuing to do it and further to recommend it are entirely different. So you keep saying. The problem is, almost everything Object Mentor advocate does seem to be based on some combination of their personal experience and pure faith. I object to someone telling me that my colleagues and I are "unprofessional" because we happen to believe differently, particularly when we do have measurable data th…

That's because you're trying to have a debate with the Object Mentor guys rather than a discussion with me. Your problem with them isn't my problem, and neither are your misunderstandings. It is not my job to argue you into a better understanding of something you clearly can't stand.

Re: Agile is a Sham

#188
post #155

Earlier quoted context omitted.

> A 15-minute standup isn't going to hurt a good team's productivity It can send a powerful message that the team is not responsible for producing the software.

It can send a powerful message that the team is not responsible for producing the software. Could you elaborate? I have a hard time imagining how spending a few minutes describing your progress and your immediate plans could possibly give you the feeling that you're no longer responsible for what you're working on. It seems to me that not ever being asked about what you're doing would powerfully convey that message.

Daily stand ups would be stupid in my current project.

Professionals should have a broad responsibility for the end result and appropriate freedom over the approach taken.

Externally imposed process creates a situation where professions are responsible for executing that process.

People ask dumb questions like "Is this Agile?". Who cares? The correct question is "Is this what makes sense to get the right outcome?"

My personal experience is daily stand ups are used as a tool to mandate a start time. This time was been inconvenient for staff with young children to drop at school. I remember hearing the sigh or relief from a person when they were dropped.

Re: Agile is a Sham

#189

Earlier quoted context omitted.

Glad to see disdain for "agile" is finally becoming mainstream. Now, it may be that someone writing rote software should follow a process, but for anyone doing anything actually innovative, you can't get into their head and tell them what process they must follow, whether waterfall or agile. It's like telling Michelangelo the process for sculpting. Rather than teaching people processes, they should help foster better…

I think you can't effectively impose process, but I do think that good teams can happily decide what process they're going to follow. Which is how we got Extreme Programming in the first place.

Why stop at teams? How about "good departments happily deciding"? Or "good companies happily deciding"? Or "good nations happily deciding"?
Post reply on HN