MS Consulting and The Client's Best Interest

time to read 6 min | 1137 words

Karl Seguin has posted MS Consulting : One Consulting Company To Rule Them All, which I read with a sense of sinking horror.

The problem with software consulting firms is that their incentives likely don't line up with their client's...

[some paragraphs talking about how a consulting company can screw their clients...]

Enter Microsoft.

Assuming we are strictly talking about Microsoft technologies, Microsoft is best positioned to solve the problem.

I work in a consulting company (which is also a Microsoft Gold Partner) so I am probably biased.

Karl then goes on to the really big issue with this suggestion:

Of course, there are flaws with my approach. First, it assumes that Microsoft Consulting is able to deliver quality products, hire quality developers and properly manage them. ... Consultants would likely be pressured to push Microsoft technologies that really aren't necessary (i.e, build something for InfoPath and require the company to buy 3000 copies of the program).

I can speak from second-hand experiance with having to deal with MS consultant "advice". It consist of "use [only] Microsoft products". I recently had to battle against using SharePoint and BizTalk in a project where they are completely the wrong tools for the job. And I had to explain to management (about 9 months ago) that no, using DLinq is not going to be a viable solution for a long time yet, because a MS Consultant told them that this is the One Microsoft Way to do data access from now on.

I have a big problem with the tendecy to go with all Microsoft (and only Microsoft) solution when there are often better alternatives around. I have yet to find the Microsoft consultant that will prefer using NUnit to MS Test, depsite some serious flaws in MS Test, for instance. Or suggest using log4net instead of bringing the who EntLib to a project (thereby increasing the complexity of configuration alone by an order of magnitude).

There are some crappy consulting firms out there, one of the thing that We! does is to provide code review services for companies that wants an independent review of the product that they are getting. Some of the code that I have had to go through is so nasty it is in the monthly WTF zone. Here is an actual quote from one of the mails I had after I did a performance review on a system:

The author of this piece of code has managed to achieve the unique state of being able to go very deep into the framework, while combining absulote cluelessness of the reasons why [a problem] occured. I have to say that I am impressed with the ability to dig so deeply to find the core issue, and amazed that at the same time, he managed to so completely missed the target. This code manages to be both ugly to use and the most inefficent way to do [a particular thing] that I have yet to see. All points for inventiveness, zero points for thinking.

I recognize that getting really bad products from consulting company is something that is not that rare. There are better ways to handle this than to trust that Microsoft would do a better job. The more likely scenario is that you would start spending a lot more money of licenses (and training/consulting about how to configure/administer/manage your new software) than before.

I currently have a system in production that is using SQL Express, preciesly because the data the application is managing is small, and can be purged on a regular basis. This meant a drop of $6,000(!) in the project price. What do you think a MS Consultant would have choosen? Would it have served the client's interest better?

Karl suggests that it is easier for the customer to detect a sell pitch in the style of "you should use BizTalk" than to spot getting a really crappy product. I would say that the reverse is true. If a manager is unable to have independant code reviews, or unwilling to head their advice, there is no gurantee that they will be able to understand whatever BizTalk (or SharePoint, or MS CMS, or the like) is a good solution for the problem at hand.

I personally know of at least one BizTalk installation that I could replace with about three days of work, and get more maintainable code, better scalability, far better robustness, etc. In that case, the client certainly hasn't benefit from what BizTalk has to offer.

I can tell you that I (and We!) take a great deal of pride in what I create. I tend to not ship crappy code on a aesthetic basis. I had to go back to old projects, for code harvesting, additional development, bug fixes, etc. Producing crappy code means that I go home depressed, and I intend to do "this computers stuff" for a long time.

The core problem still exists, of course. One of the solutions is to have someone from the client side (either in-house or a third party) review the code and make sure that it matches the required standards. In most of my there is such a person, and it is my responabilities to walk them through the code and explain stuff (and have heated arguments ;-) ). The other is to have some sort of a support contract, which may include some clauses about fixing bugs in the application, acceptance tests, etc.

To sum it up, I think that it is a naive approach at best.