At this point, a comprehensive critique of Object Mentor would be more a case of writing a book than posting a few links. However, in the interests of not attacking them completely without justification:

- Object Mentor are big advocates of XP. The fundamental principle of XP is that a certain practice is good, then doing more of it must be better. There is no logic in that position at all, and it doesn't stand up to even cursory criticism. Moreover, if XP is as superior to other processes as the typical advocacy quotes and statistics imply, how come organisations using XP aren't consistently reporting dramatically better measurable results and how come so few software development groups have chosen to adopt it? Sooner or later, people notice that the emperor has no clothes. (I suspect this is why we now have Software Craftsmanship: it's a new positive-sounding but conveniently meaningless marketing term to pitch to clients.)

- Bob Martin has repeatedly stated that anyone who doesn't do TDD is unprofessional. Safety-critical software is typically not developed using TDD; in fact, formal methods, BUFD, and other very much not Agile processes are often used in such fields.

- Michael Feathers redefined the term "legacy code" in terms of unit tests. There are decades of research studying what actually causes a project to decay to the point that it is difficult to maintain and update. To my knowledge, a lack of unit tests has not yet been cited as a causal factor by any paper on the subject. (FWIW, I do think Feathers' book on the subject offered some interesting and worthwhile ideas, I just don't accept his premise that having unit tests is what defines whether code is legacy or not for practical maintenance/project management purposes. I think when you try to co-opt an ill-defined but commonly understood term and give it a formal definition that is very different to the mainstream concept, you lose some credibility.)

- Brett Schuchert, a man writing a book on C++, managed to make "Hello, world" take five source files and a makefile totalling nearly 100 lines, using TDD of course.

- Ron Jeffries. Sudoku. Probably enough said. TDD is not an alternative to understanding the problem and how you're going to solve it.

- From a post on the Object Mentor blog, Brett Schuchert apparently advocates pair programming based on a 1975 study of something involving two-person teams, a ten-year-old study of university students, and a couple of links to secondary sources. The original research for almost every one of the primary sources he appeals to either directly or indirectly is no longer available at the cited links less than 18 months later.

- Bob Martin thinks there are no more new kinds of programming language left to find. That's roughly on par with equating Haskell and Brainfuck because they're both Turing complete, and shows a complete lack of awareness of the state of the art.

- When it comes to the amount of up-front design and formal architecture that makes sense for a project, the amount of retconning in recent comments from the TDD guys is laughable. There was a particular interview featuring Bob Martin and Jim Coplien a couple of years back that was almost painful to watch.

I could go on, but if that lot doesn't paint a clear enough picture for anyone reading this, I don't have a powerful enough Kool-Aid antidote to help them.

I do agree with you about the insincerity. That's worse in theory, but unfortunately it's probably no less damaging in practice.

Edit: Here are few links to support some of the points above.

http://www.infoq.com/interviews/coplien-martin-tdd

http://skillsmatter.com/podcast/agile-testing/bobs-last-lang...

http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku...

http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp

http://blog.objectmentor.com/articles/2010/11/09/info-please...