How to cope with developing against a poor 3rd party API/application?

Posted by wsanville on Stack Overflow See other posts from Stack Overflow or by wsanville
Published on 2010-06-02T23:20:40Z Indexed on 2010/06/02 23:24 UTC
Read the original article Hit count: 231

I'm a web developer, and my organization has recently started to use a proprietary ASP.NET CMS for our web sites. I was excited to get started using the CMS, thinking it would bring a lot of value to our end users and be fun to work with, since my skills are a good match for the types of projects we're using it for. That was about a year ago.

Since then, we've ran into all kinds of issues, from blatant bugs in the product, to nasty edge cases in the APIs, to extremely poor documentation for developers. On about a weekly basis, we are forced to pursue workarounds and rewrite some of the out of the box functionality, and even find some of the basic features unusable. In many cases, since this is a closed source application (and obfuscated of course), there's nothing we can do as developers to solve these issues.

So my question is, how does one attempt to develop a good application in such a scenario?

The application mostly works when using the the exact out of the box behavior, or using one of the company's starter sites. However, my attempts to use the underlying APIs to implement slightly different, yet reasonable behavior has proved to be extremely time consuming (not to mention just as buggy), given the lack of good information about the APIs.

I've given this a lot of thought, and my conflicting viewpoints are the following:

  1. Strongly advise against any customization to the CMS, as development time will rise exponentially, or even have an extremely high chance of failing.

    While this is accurate, I do not want to give the impression that I am not willing to code my own solutions to problems and take the initiative to implement something difficult or complex. I don't want to be perceived as someone who is not motivated, lazy, or not knowledgeable to do anything complex, because this is simply not the case. I love coding my own solutions, trying new/difficult things, I just dislike the vendor app we're using.

  2. Continue on the path I'm on now, which is hacking my way past all issues I encounter and try my best to deliver an application that meets the needs and specs exactly. My goals are to make it as seamless and easy to use as possible to the end user, even when integrating the CMS with our other applications internally.

    The problem I'm finding with this approach is it is very time consuming. I open support cases with the vendor on a regular basis to solve issues and to gain knowledge of their APIs, but this is extremely time consuming, and in some cases it leads to dead ends. I post on the vendors forums on a regular basis but have become frustrated as most of my posts get 0 replies.

So, what would you, a reasonable developer, do in this case? How can I make the best of the situation?

And just for fun, here are some of the code smells and anti-patterns I've dealt with using the product (aside from their own code blatantly failing):

  • Use of StringBuilder to concatenate a giant string that is hard coded and does not change. They use it to concatenate their Javascript and write it out into the body tags of their pages.

  • Methods that accept object or Microsoft.VisualBasic.Collection as the parameters. In the case of the VB Collection, the data is not a list of any kind, it's used instead of making a class.

  • Methods that return a Hashtable of VB Collections

  • Method names of the form MethodName_v45, MethodName_v20, etc...

  • Multiple classes with the same name in different namespaces with different functionality/behavior.

  • Intellisense that reads "Note: this parameter is non functional"

  • Complete lack of coding standards, API is filled with magic numbers and magic strings. Properties with a getter of type object that accepts totally different things, like enum or strings, and throw exceptions at runtime when you pass in something not supported.

  • And much, much, more...

© Stack Overflow or respective owner

Related posts about best-practices

Related posts about subjective