Wednesday, June 4, 2008

The 3rd Party Bait and Switch Game

Macadamian is a service company. We bid on projects with one of several models. The two most common ones are "Time and Material" and "Fixed Bid". Fixed Bid projects often are high risk, the customer knows this, which is why they want a fixed bid. It allows them to fix their costs and content, if not necessarily their quality.

While we sometimes estimate the work in a Time and Materials engagement, it is obviously mandatory when we do a Fixed Bid. When I do estimation, I don't have 80 hours to do it in; I often have less then 8 hours spread over a week or even longer. Couple that with the fact that estimation feels more likes an art then a science and you can see how we get into trouble.

A good practice when doing estimation is to look for 3rd party tools you can buy or license that will save time and effort (and hence money) during the project.

In one particular web application we researched what was supposed to be a top of the line product for charting and other UI widgets. The "marketing brochure" looked really good, it had all the features we were looking for, and the customer has used the desktop version of the controls for years to great effect. And we bought the support agreement! What could go wrong? Ha, famous last words.

It turned out that the 3rd party control did in fact do everything almost it advertised, just not at the same time. The 3rd party code was a complete and utter mess, and parameters, methods, and attributes for the widgets changed between the different versions, or were not supported in our version.

We ended up "creatively" working around a lot of the issues, but it added a lot of time and complexity to the project, and ended up making the code more fragile then it had to be.

The moral of this story is before you choose any 3rd party tool to solve that problem, spend some time and use it. And I mean, really use it. Don't just run some of their canned sample code; spend at least a full day making a proof of concept on one of your most complex pages (or uses cases) to see if it will work as advertised. If it's a web tool kit, look at its source. Is the source clean, well commented, and designed? Review the developer documentation in some detail, and "Google" the developer groups to see what people are saying about it.

It's the least you can do when your entire development plan hinges on it.

No comments: