There’s Madness in your Method

I wrote this last year, prompted by Penny asking me write something for the website that might get people talking. After I wrote it, I thought it was more likely to annoy than stir up debate. However, @martinfowler just wrote this, which I liked, probably because he’s better at presenting a coherent case than I am. Here’s my attempt…

As a consultant, I tend to have adapt to the customers’ ways of working.   Sometimes that even means I have learn something new. I had been considering going on a TOGAF course for a number of years now. Fear of getting into a public argument with the trainer over something pedantic like a meta-model issue or the exact meaning of “Service” has always prevented me though. Over the last few years, I have found myself working amongst TOGAF qualified architects, and it is this what is worrying me.

I’ve always had a bit of a problem with methods. Maybe it’s an aversion to being told what to do, or just a misplaced, egotistical belief that I probably know better. Either way, methodologies suck. Big time. They all look logical enough, and they’re hard to pick fault with because they’re based on best practice and the collected wisdom of experts in their field. Collected wisdom, renowned experts and logic have never stopped me having a pop at something I don’t like though, even if I can’t rationally explain why I don’t like it.

Firstly, completing a course and ticking the right multiple choice options doesn’t mean you know what you’re doing. Government and industry are littered with MSP and PRINCE2 qualified contractors. Many of them are clearly in the wrong job and some are utterly incompetent – evidenced by the eye-popping number of failed programmes and cost overruns. We’ve all met them, and we’ve all wondered how they manage to even dress themselves in the morning, never mind find their way to work. I wonder if Google pay their PMs four times what they pay their best coders ? Actually, I wonder if Google have ten times as many managers as they do coders on their software projects ?

Secondly, I’d rather have one person who can think for themselves than five people who are following a methodology. Zombies at typewriters aren’t going to produce the complete works of Shakespeare. They might well come up with a new methodology though, and the accompanying manual (with sample exam questions) will probably sell more copies than King Lear.

Thirdly, it lets HR off the hook, and if there’s a bunch of people in the organisation who you should never, ever let off the hook, it’s HR. They will always take the path of least resistance in finding candidates, and their natural tendency to cover their own arses means they’ll always choose candidates with a certificate of some sort no matter how experienced they aren’t.

Fourthly, these methodologies always seem to duck the difficult bits. They’re much more likely to tell you how to run an architecture / development / engineering team than tell you how to build something useful.

Finally, I think methodologies hurt the trades they are supposed to serve. The certification schemes are highly profitable, and it is not unusual for hundreds of candidates to go through them every year. This floods the employment market with a wide spectrum of abilities all concealed under a common qualification. Couple that with HR’s love of certificates and you get huge numbers of people working in roles they are unable perform. That hurts everyone. It tars the able practitioners with the same brush. It blots the career of people who have tried to take on too much without enough experience. And, it diminishes the reputation of the trade as a whole.

@MonkeyChap