The VooDoo consulting style

I'm working often together with "experts" from different consulting companies. It seems like they follow a common strategy (I call it VooDoo) during the consulting activities:

Never say "I don't know". In case you have no idea about a certain technology, just use generic terms like "SOA", "Web 2.0" , "loose coupling" to explain how it works.
Regardless what standards your customer follows, just suggest the opposite for the realization e.g. in case RoR is the standard: suggest Java EE, in case Java EE is used than suggest Spring.
Concentrate on sofskills, never answer questions directly. Prefer meetings, telcos or videoconferences rather than answering question per email.
Always reinvent the wheel.
Do not follow common standards - try to build unmaintainable systems. It is more likely then, that you contract will be extended.
Try to influence other projects or better: try to take over the world.
Always use the CoS (Cover Your Ass) strategy, regardless how expensive this really is for you customer. Prefer "Green Bars" rather than satisified customers and running systems. Try to "hide" behind CMMI, RUP, or XP-manifesto - it is really convenient.

It is easy to identify a VooDoo consultant. Just ask the question: "Why your decided this way?". In case he answers: "Because it is cool" or "This is the way to do it", or "Everyone is using this framework" you are working with one of them :-).

Comments:

... like a deja-vu ;o)

Some more behaviour i've encountered:

- always push as many staff into the project as you can. The more the better.

- Keep the workload of your staff high - even if it's pure 'actionsism' - it look's professional

- Quality of code is equal to Quantity of code. The more the better (what's DRY ???)

:o)

Posted by Mario Gleichmann on September 14, 2006 at 06:58 PM CEST #

Hah, great writeup. I think I've worked with my fair share of consultants like this, and might even be guilty of this once or twice before I learned how little I knew ;)

Posted by Riyad Kalla on September 14, 2006 at 07:59 PM CEST #

Hi Mario,

DRY is "Don't repeat yourself". A soundful acronym for simple principle - try to avoid redundancy.
You forgot also the documentation. Even a guestbook needs about 500 pages design spec :-).

Posted by Adam Bien on September 16, 2006 at 01:29 PM CEST #

Riyad,

the problem in software engineering is: we know really very little comparing it to the challenges we have to face. This makes the life more interesting, but if we stop learning - we are retired :-)

Posted by Adam Bien on September 16, 2006 at 01:34 PM CEST #

Hi Adam,

what i wanted to state is, that our so called gurus apparently never have heard about DRY or TDA ...
(but nevertheless - thanks for your explanation again ;o))

... lol - you are rigth: documentation and focus on processes / plans (over response to changes) is another highlight - handsome presented in pretty powerpoint-presentations.

Posted by Mario Gleichmann on September 18, 2006 at 02:25 PM CEST #

Hi,
check this link http://www.voodoo-consulting.com/
and tell me if I'm a real voodoo consultant.
P.s.: When i choosed the name of my company i was thinking both about :
- voodoo child from Jimy Hendrix (I'm also a guitar player)
- kicking-out the "magie informatique" (as we say in France) from viruses-infected personal computer.
lol.

Posted by Nicolas Casadevall on September 30, 2009 at 06:06 PM CEST #