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

Question

Update: Based on the feedback, some good strategies are:

1. Avoid geeky arguments, instead focus on problems that effect the application on the whole, not just problems for developers.
2. Keep a bug list of problems with the product, explain how they effect the end users.
3. Write a wrapper over the APIs, make your code modular so a different system could be swapped in easily.

I'd love to head some more strategies ;)

Original post:

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 vendor'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 out of the box functionality, as development time will rise exponentially, or even have an extremely high chance of failing. Basically, become a "No" developer.

   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. I can imaging the conversation of the developers... "Hey guys, we don't have to make classes anymore, we can just use key value pairs!! This will save to much time!!"

• Methods that return a Hashtable of VB Collections (again, the items are NOT collections/lists, they should be classes)

• 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.

• Reading files that get pre-compiled (like resource files) directly off the filesystem, so their product will only work when the site is dynamically compiled. Apparently they have never even tried pre-compiling their product.

• And much, much, more...

Answer 1

1. Set up a bug database and report every stupidity and error you find.
2. Talk to other developers, you can only win this game if you speak for the whole team.
3. Talk to all levels of management that you would not recommend using the CMS, even when the vendor would pay you using it. Avoid geeky arguments at all costs. Management knows that people always hate change, always hate to learn, to use something new. And people love to argue against new stuff just for the fun. Point out real problems, real hindrances only. Management does not and will not know wtf a Hashtable of VB Collections means. Do not explain the problems to them, but the implications of the problems that will hit their asses. (Incalculable delivery times, mystic bugs, exponential complexity, undeliverable, unusable features that only exist on paper, random project failures, quitting developers etc.)

At this point, if nobody listens to you, I would consider to quit. Or:

1. Start using the CMS nevertheless.
2. Watch the project fail.
3. ???
4. Gain profit - or even a promotion - by blaming the management not listening to you.

Answer 2

I would hope for the best and prepare for the worst. Start off by designing a clean interface to the CMS that you would like to use. Design it in a way that you can swap out the implementation to a different system if need be.

Present a case to the management that you are "managing complexity" of working with a an imperfect system and that you are developing an abstraction layer over it. Also mention that the development of an abstraction layer is not much extra work, so it's totally worth doing whilst fixing their bugs.

Keep reiterating that the underlying system can be replaced at any time without much work. Maybe even do mockups for a competing CMS running with your codebase. Slowly build up a perception that the system is shit but it doesn't matter. Eventually you come up against a monster feature that requires a lot re-work - a perfect moment for selling changing over the CMS.

Answer 3

Definitely use another CMS!

Sure there's a learning curve, loss of old templates, 2 frameworks to maintain, etc.. but if you put the time you currently waste on dead-ends into growing the new toolkit you'll be 100 times better off a year from now than your will when your current vendor goes bust from selling poor software. You did say "my organization has recently started to use" so presumably it isn't too late to realise you fucked up and go with a better solution. The longer you put off changing the harder it will be. This time go open-source so you aren't at the mercy of third-party support.