Martin Fowler is an enterprise buzzword methodologist. He was into UML, refactoring and patterns and Java back in the days. Nowadays he is into agile, TDD and ruby.
He has a big respect in certain circles, and even I have the Refactoring book, which was a disappointment for me, because it was about practices that was trivial for me after two years of proferssional work, while going into the details too much.
The plural of anecdote is not data, but when I worked at ThoughtWorks, Martin sent me some code to look at. It was very clean OO code (very smalltalk-ey in design and form, thought it was written in Ruby). The man can code well (not to the level of say Peter Norvig, but then not many of us can) and competently and is very sharp and when he gets hands on, solves problems fast.It is true that he doesn't have any code online where we can look at it.
Another admirable trait I've witnessed is his willingness to say "I don't know" when asked questions outside his circle of competence. He often says it very bluntly (which has caused some heartburn to some ThoughtWorkers once in a while, but that is another story).
His "Enterprise Patterns" book is very useful for anyone working on enterprise software. I believe DHH was influenced by the book when he was hacking Rails.
His upcoming book on rich gui apps seems promising too. Also he doesn't make outragoeus claims or adopt a condescending atitude to programmers who don't work the way he does/advocates (unlike say Robert Martin). I wouldn't dismiss him as a "know nothing" talker/blowhard.
As I said, just anecdotes. Make of them what you will.
His enterprise applications patterns book is superb. An excellent reference to have to hand when you're planning a system. And because it's all written down, you can point to it for substance underneath your decisions when you get skepticism from straight line programmers who just want to start coding without getting excited abuout structure.
Oops, my mistake. But the above still holds for Martin Fowler btw. And all those enterprise methodologists look the same to me: they advocate something, but you never see the code they produce, as it is some proprietary crud system at the end of the day :)
He has a big respect in certain circles, and even I have the Refactoring book, which was a disappointment for me, because it was about practices that was trivial for me after two years of proferssional work, while going into the details too much.