Are bought in thirdparty libraries cost/time effective?

Question

I've recently been working on a C# GUI. We used a third party graphical controls library (that I won't name). Some people really like this library and get all excited with "hey look its got a control that looks flashy, let's use that on this screen". My experience was that we compromised the usability of our GUI by putting some flashy controls in it. And, I also found many of the controls limiting. They'd nearly do what I wanted, but not quite, so there would always be a compromise.

Some parts of the library just had unacceptably poor performance, and we had to write our own versions of these features. In other places where bugs were encountered, we had to wait long turn-around times to get fixes from the suppliers.

I've got a feeling that the expense of buying this library in wasn't worth it and that it didn't improve our development time or product quality.

Do you have any information, preferably quantifiable facts, on the successes/failings of buying in software libraries so that we can be more informed about deciding if we should buy in libraries for future projects?

Answer 1

Obviously the answer is subjective and depends.

If you're looking for "official" research, the Software Engineering Institute has focused a lot of studies and published a lot of reports on COTS based systems. They did a lot of cost effectiveness modeling, though not necessarily of GUIs.

http://www.sei.cmu.edu/cbs/

Answer 2

Like many things in life, the answer is "it depends." It depends on the library, the vendor, your relative corporate size (e.g., IBM putting pressure on Microsoft to fix an API vs IBM putting pressure on JoeSixPack's Software Emporium to fix an API), their desire to be responsive, etc.

My experience with third party libraries has been limited, but positive. As always, YMMV.

Answer 3

Think along the lines of long term maintenance of your software. Third party controls fester, get out of date, stop being supported, and clutter your build with extra code--code you didn't write, but now get to support. My view is this, if you want a button in your software GUI, use the Button that came with your framework. Need that button to be flashy? Do it yourself with 20 lines of code, no need to import another 20,000 lines of code that you know little about to get the same functionality. In my experience, 3rd party controls can help you get some functionality quickly, but you never stop paying for them.

If a control provides the exact functionality you need that would take months to implement, it might be worth it, but if it is just for "flash" then fight it.

Answer 4

Generally, you've got to reason the cost of the library not being exactly what you want versus the cost of doing everything the library would do yourself, including the maintenance of it. I've not come across many situations where the library cost more.

I've built my own web grid component because I didn't like any of the ones already out there at the time (late 2005). I now have mixed feelings about that decision. While it gave us excellent time-to-market for some advanced grid functionality, I spent a long time developing it (which could have been directed at product features), and I can't keep up feature-wise with other grid components out there.

Answer 5

I have learned this: the more you research before you purchase, the more likely you are to be satisfied with what you get. The decision of which 3rd party library to buy, or develop in-house is worth spending time on (the more impotent the library is to your product the more time you should dedicate to research). Try samples/demos and even contacting other organizations that have faced similar decisions. Anything to lower your risks.

Answer 6

If the feature is core to what you are trying make special about your product, you should not "outsource" it by using a 3rd party component. Joel has a good article: In Defense of Not-Invented-Here Syndrome

Answer 7

(I feel like the wizard of Oz). But, Dorothy (or Scott), you already have the facts.

These are perfect. Add details when you report internally. Name the project, name the control, provide the number of days it took.

Some parts of the library just had unacceptably poor performance, and we had to write our own versions of these features.

In other places where bugs were encountered, we had to wait long turn-around times to get fixes from the suppliers.

What more do you need? Just quantify what you already know. Since your facts are based on your experience, not mine, it should hold some weight. If I tell you my experience, the GUI Control Fan Club will say that my bad experience is because I'm dumber, fatter and less motivated to succeed.

However, please discard this.

They'd nearly do what I wanted, but not quite, so there would always be a compromise.

It's what we call NIH. Just because you didn't create it, you might feel like there's a "compromise". With respect to what? What the user needs? Doubt it. With respect to how you would have written the API's? Maybe, but who cares other than you? Indeed, in the long run, you may find that there was some wisdom to their "compromise".

Answer 8

Third-party libraries for GUI development are much cost and time effective; some of them provide familiar, consistent user experience and are used unanimously. Absolute majority of development teams use third-party GUI components such as Windows, GTK, and SWT.

To get the most of cost and time efficiency consider any non-mainstream components as stringently as you would your mainstream GUI development platform.

Given your chosen time-horizon (predicted lifetime of the code) maintainability and extendibility are usually need to be set as main criteria for the assessment of candidate components:

• Do you get the source code?
• Would it be easy to override parts of the component, its standard behaviours if that required?
• Is it future proof and portable, i.e. when next operating system or rendering engine comes along is it likely to be supported?
• Licensing conditions and fees.

You would be almost always better off when going for a collection of small components designed to work together rather than a large solid rock of a single component. So instead of a spreadsheet component it is better to have a flexibility of individual cells, some sort of grid to assemble the cells together, buttons, toolbars etc.

When making decision of using third-party GUI component versus writing your own many development teams underestimate skills and effort required to create a new component and make it behaviour consistent with user expectations. In my opinion, this is because of wide availability, cheapness and high quality of mainstream components. Many software professionals do not realise how much effort and consideration is required to create a GUI component.

Ask yourself if having a bespoke made GUI component strategically important for the success of the product? If not then it is definitely more cost and time effective to stick to the mainstream.