Thursday, November 06, 2008

Be wary of them the 3rd Party Components

I've been burned once and seen other projects burn because of wrong choice of 3rd party components.

My project - that was shot to hell - had to depend on a 3rd party component [Let's call it WiseImport ;)] from reading data from a competing product [MarketLeader]. We were doing an import wizard and Legal warned us not to use any of the SDKs exposed by the competitor [Legal moves in mysterious ways especially when the competitor offers the same kind of tool as an add-in]. But it was somehow okay to use the third party component.

The version 1.0 of the wizard used WiseImport successfully and in his infinite wisdom our Architect mandated us to go with the same product. Now, we required master-detail information from the MarketLeader. Alas, late in the game we found that the master & detail information are available separately but there was no way to link them to each other. The creator of WiseImport was a 2-person company that was successfully bullied into [I guess nothing motivates people like a threat of multi-million dollar law suit] looking at the problem at a war footing.

Well, let's just say he was near tears when he wrung his hands and said this was a bug in the MarketLeader product and he would only be able to provide a fix when the MarketLeader fixes its SDK. [And, of course, he was sorry as hell and was willing to refund the license fees ... I'm sure minuscule in comparison with "multi-million dollars"]

Oh, yes, the rest is history [along with the project that is].

In another instance, where I was called in as outside expert to look at the performance issues, I found, to my dismay the control used does not care about its ViewState size. I thought that these guys should be held criminally responsible for such a shoddy code. I'm no lawyer [probably explains why I don't make much money], so as a compromise, I had to hold the team responsible for their gross negligence. In the end, I thought I'll frame some guidelines - or at least warn people of the careless use of 3rd party components.

  1. Evaluate the component per your current and future needs
  2. Make sure it is functionally fit for your requirements
  3. Gather metrics - if you're using a ASP.Net Server Control use Fiddler2 / WDH that support #2
  4. Don't be influenced by what is being used currently
  5. Don't go by popularity of the component or just because you've used it in your previous project
  6. Make sure you can get support when required [not everyone have the threat of a multi-million dollar law suit in their arsenal]
  7. Can they roll a custom build to fix your issue?
  8. What is your backup plan if the component have to be replaced?
  9. Have you identified a suitable alternative?
  10. Does your design isolate the 3rd party component so you can plug & play?

I'm sure all the above may appear overkill. Let me assure you, they're not. You'll probably thank god [and your stars] for the sense you had to do the above. Or when the project fails [more aptly when the s**t hits the fan], you'll at least have covered your bases.

1 comment:

Anonymous said...
This comment has been removed by a blog administrator.