October 1, 2010

...Learn TDD with Codemanship

We Emulate Management Consultants At Our Peril

One of the biggest complaints business leaders have about management consultants is that they usually know nothing about your business.

There's a well-known tale about Lord Sugar, the man behind Amstrad and The Apprentice here in the UK. Apparantly his company had hired a big consulting firm to help them streamline their business, with the usual eye-watering fees these companies charge.

One day, it's said, Lord Sugar happened upon a very youthful gentleman (basically, fresh out of college) in an expensive suit poking and prodding at the insides of a fax machine they manufactured. He asked the consultant what he was doing, and the consultant replied that he was looking to see how Amstrad could reduce the bill of materials for the fax machine.

Lord Sugar asked him what training or experience he had in electronics or manufacturing, and the kid replied that he had none. He was a business school graduate. He knew as much about the design and manufacture of fax machines as my Mum knows about functional programming.

As the story goes, after this unfortunate encounter, Lord Sugar showed this management consultancy the door and has had a dim view of them ever since.

Management consulting has been much maligned of late. There's good evidence to suggest that the "science" of management is nothing of the sort, being closer to astrology than anything genuinely evidence-based or grounded in sound logic. And whistleblowing insiders have revealed working practices that suggest some of the bigger firms may be applying simplistic one-size-fits-all formulas ("lay off a bunch of people", basically) that have almost no hope of resolving the complex, multi-dimensional problems most businesses face.

Like Lord Sugar, I tend to look sideways at any "expert" advising software development teams and software-dependent businesses who knows as much about developing software as the kid knew about making fax machines.

There's no doubt in my mind that a test-driven approach could be taken to designing kitchens, but as an "expert" in TDD, you won't see me advising MFI or Moben any time soon, and definitely not for money. Because I know sod-all about kitchen design.

I could explain the basic principles to a kitchen designer. But I couldn't illustrate how it applies to his work, and certainly couldn't easily tell if his kitchen designs were better as a result of applying it. As a "Test-driven Kitchen Design" coach, my usefulness would very quickly diminish. I might get an hour's work out of it, if we take it slow.

So why would anyone who can't write software themselves think for one second that they should be advising highly-skilled, knowledgeable software professionals about how to run their projects?

And why this indecent haste on the part of some Agile consultants to emulate a discredited and maligned profession, namely management consulting?

Well, I can think of one reason...

Anyway, the point I'm making is that we need to be very careful. Just as they're doing with management consultants, sooner or later our customers will figure out that the management practices of Agile don't deliver working software any more than they can grill cheese or power an electric bicycle.

The business of software is software. We don't make bean bags and we don't sell ice cream, even if that's what will solve the customer's problems. We make working software. And the Manifesto for Agile Software Development is a manifesto for doing it better.

If you don't know how to make software, then I'm afraid you've boarded the wrong train, my friend. This train is going to Better Software. The train for Management Snake Oil leaves from a different platform. You can't miss it. It's made of invisible gold and it runs on magic beans.

Posted 10 years, 10 months ago on October 1, 2010