I can appreciate the label pseudoscience for a field where things advocated by practitioners are independent of empirical evidence for them. Some may accidentally have empirical evidence but that’s not a criteria for inclusion.

However, can we please not associate it with Pragmatism (Pierce, Dewey, James etc.) which definitely is about empiricism and avoiding the supernatural or transempirical?

Berlin - quick 5-10 minute meetings can be a good technique to introduce into a team who clearly don’t talk to each other, or rapidly diverge off-track without guidance, or don’t communicate slippage until a weekly meeting - but that works just as well in a Waterfall project, or for a chef in a kitchen.

Point being it’s a specific managerial technique for dealing with a particular situation - and a lot of what I see in Scrum, etc, books seems to be of that nature. The problem is, of course, that it’s bundled into a single package - and people seem to focus on the rituals (peer programming) rather than the why.

Or indeed start trying to sell it where it’s not appropriate - I presume at least one of the causes of the Agile movement was the push of Big Project Methodologies into smaller inappropriate projects.

>Then there is no way to prove that Agile is going to benefit your organization. Note, YOUR organization. >Then why should we care?

But that takes me back to my question to Tony. If we accept that the management of most software projects in inadequate, from both the point of view of customers and developers, we clearly need better managers - which means either experienced ones or better managerial training.

Ideally we want to make sure that training does offer some provable benefit.

If you were to explain to me how you develop software and I ask you to explain to me why you do it that way, then none of your explanations will be of a scientific nature. Should I therefore be able to dismiss your methodology on the basis that it is ‘pseudo-scientific’? Of course not; your practices probably make perfect sense to me.

“I’m unclear as to which aspects of the agile/… methodologies you consider as ‘pseudoscience’. ”

I would say the part with Pig and Chicken Roles. 5-15 minute meetings everday.

“It’s not a religion, it’s not something to be strictly adhered to and it’s certainly not scientific.”

Isn’t that the definition of pseudo-science.

And this is the sticking point with me. If you can’t strictly adhere to it. And it is not scientific. Then there is no way to prove that Agile is going to benefit your organization. Note, YOUR organization. Then why should we care? Does it work for the highly paid consultants at Thoughtworks. They would like to believe so.

Here are the main offenders.

I am replying to the main point and not the comments. Think about Agile and other BS this way. When you first learned programming. There were a couple of things required to make anything happen. You needed a computer, probably a programming language. Maybe a text editor of some type. When I programmed when I was young, since then programming hasn’t changed to much. Now, consider Agile and other methodologies. Can software be written without Agile? and other nonsense. Of course it can. Not even to mention that Agile for company A could be completely different from company B. What about the watefall model? It seems like Waterfall describes a sequence of events as part of the software design and deployment process. And as far as I can tell, there aren’t religious fanatics for Waterfall. “Requirements, Design, Implementation, Verification, Maintenance”, describes a simple set of sequences in the software development process. It is clear if you missed the ‘testing’ aspect of the Waterfall model. On Agile, are you not doing Agile right if you don’t meet for 15 minutes everyday? Or gasp!?! you spend a lot of time during the Design phase.

Agile and other variants is non-sense, always has and always will be. Too bad companies like Thoughtworks continue to peddle the non-sense.

As far as the thought experiment with the “running around a clothes line 5 times each morning yields good software”, I think I can safely say that this process would fail, that the process would gain no traction, and zealotry wouldn’t really be a problem. (Actually, given how little exercise many programmers get, it probably would help your software a little bit, but that’s beside the point).

I’m surprised by your claim that reason dictates that hypotheses must be inductively determined. That’s a pretty unrealistic vision of how reason (or scientific thinking) works, since seeing a pattern in data requires an idea of what kind of patterns to look for. That is, hypotheses have to precede the gathering of inductive evidence, even for hypothesis formation. Otherwise, I have to pay attention to all factors in the universe.

For example, I could claim “functional languages produce better software”. I could justify this claim by looking at similar cases where functional and non-functional languages were used, quantify their outcomes, and compare. But how can I inductively form the hypothesis itself? I have to suppose that “functional languages” and “better software” may have a relationship, and then start looking at cases. Where does that initial supposition come from? It could be from anywhere: a hunch, a sense of aesthetics, personal experience, a blinding vision, similarity to other problems, because your boss told you, etc.

What I get from your examples is more that you have some beliefs about what kinds of things do and do not affect certain outcomes. Crystals and health are unrelated; methodology and project success are unrelated; clotheslines and software quality are unrelated. You describe these as (or imply they are) obvious rules, rather than the beliefs they are. These kind of foundational beliefs about what is and isn’t important are pretty tenacious things, and this causes a lot of friction.

All that being said, I agree with you that it is frustrating when people believe things that you don’t. It is even more frustrating when they try to impose those beliefs on you, when your own contrary beliefs have been forged in the crucible of your own experience and tempered with reason.

I’d still be interested to read at least one example of how Agile/Lean/Scrum/XP people are trying to impose their beliefs on you, how you reacted, and how they reacted back. Not in any kind of empirical-study way, but just to get a better sense of the sources of your frustration.

Now concerning my earlier point: if you wanted to explain to someone the methods that you use to ensure you produce readable, mainainable, high-quality code, wouldn’t your arguments be susceptible to the exact criticism you give in this blogposting?

The DRY principle says enough in its expansion, Don’t Repeat Yourself.

It has a lot to do with Java, when someone professes this principle, then in the very next take, uses Java or any other grossly inept language in an attempt to achieve a practical objective. This is because this language is at its very essence, all about repetition — I cannot think of anything more diverted. I’m only using my own anecdotes — I see this doublethink quite often. Such is the nature of the practitioners in this industry.

Yes, I agree it is a sound principle, but I think John Hughes probably captures it best in Why Functional Programming Matters. Not Kent Beck or McConnell in Code Complete — in fact, as a university teacher, I’d recommend against both of these resources for learning about this principle since they both provide — at best — a very subverted understanding.

I also do not understand your remark about the DRY principle. It has nothing to do with Java and when you ask someone like Kent Beck about the DRY principle, he will not mention Java. He will say the same as McConnell says in ‘Code Complete’ and many others of different plumage have said on many occasions. Is het the kind of person you intend to address in this blogposting?

BTW, you do agree the DRY principle is a sound principle to keep in mind while writing software?

Who ever said I am using a “development methodology”?