Results from my recent evaluation of a custom MOSS field control

This is a short post to capture my thoughts while it’s all still fresh.

As technologists we offer our opinion and maybe some guidelines with regard to evaluating MOSS third-party components. We search for this information when clients ask about best practices, or perhaps have written a white paper on the subject. However, the rubber really hits the road when we have the source code as part of the evaluation. The question, “is this component worthy of a production deployment?”.

I was recently asked to evaluate a MOSS custom field control. This came at a good time because I just finished developing one myself and felt generally prepared. For MOSS, it’s easier to justify the purchase of components rather than to build. Justification for custom built software falls out of the clients requirements. That is, some things are specialized enough that only a custom solution is possible.  

Without looking at the code base I deployed an open source solution found online (by the client) into our evaluation server. We did some cursory use-case testing and it passed. At this point we felt it was a potential solution.

Ok, it was time to crack into the code and here is what I found

  1. Elevated privileges – this control could open a list from a farm installed on Mars! It defeated site authorization boundaries.
  2. Dependencies – the control required other types of controls added to the same list, otherwise it would fail horribly.
  3. Missing or minimal error trapping – explaining the lack of good error reporting in issue 2 above.
  4. Missing end tags – the control templates had some sloppy HTML (a red flag but correctable)
  5. Hand rolled solution structure – that is, not created with a tool. This is somewhat of a red flag for me but not a deal breaker. 
  6. The code base was old – maybe this explains issue 5 but raises concerns about what version of MOSS it was developed on.
  7. Packaged with another control – a poor practice IMHO, I’m not a big fan of tool suites installed out of the same package.
  8. Objects not properly disposed – Yes, SPSite and SPWeb issues as well (memory leaks).

Having looked at the code I was able to go back into our evaluation farm and cause it to fail without much effort. Now, open source makes this kind of evaluation possible but you can see nothing is really free.      

The high level recommendations are

  1. Purchase from a reputable third-party vendor if at all possible, you have immediate support.
  2. Don’t try and fix someone’s code unless it’s trivial – and you can certainly decide what trivial means.
  3. Field Controls specifically (but other components as well) should be considered as “atomic” units of functionality without unreasonable (or any) dependencies on other components, site configurations, or special security constructs.
  4. Only create from scratch if its undeniably the only way your clients requirements can be met.
  5. Unless you have a well heeled development team it’s better to purchase development expertise from a reputable (or otherwise proven) consultancy or established contractor.
  6. If possible, suggest a change in the requirements so the component is unnecessary. This can hurt initially but in the long run will save time and money.

Addendum: 7. If an open source solution is selected do not forget to download both the binaries and source to a repository. If a fix is required later having the original source code is critical.

This ends my – mostly – “note to self” segment

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s