December 12, 2006
Selecting Third-Party ComponentsDocumentation
Any use of third-party components involves an investment on your part, not only in purchasing the component, but also (and more importantly) in the effort required to integrate it into your application. This is an area where documentation can be critical. Look for vendors that supply lots of sample code to illustrate usage. These can range from just code fragments to complete project sets ready to run in your development environment. Look for migration guides to assist you in migrating to new releases.
Vendors that have some longevity and a larger user group can also have considerable presence on the Web, with code and issues that can be searched by Google. Don't forget to also search Google Groups when looking for code samples and other developers with similar problems.
Autodesk's DWF Toolkit is a great example of a third-party component with a large Internet presence. Much of its documentation is available on the Web and there are active programmer groups that can be searched.
Updates
The third consideration is how the supplier handles changes in the component, especially with respect to API interfaces. All vendors need to make modifications to their code, whether to add new features or change architecture to support greater functionality. Generally, we make it a goal to keep up-to-date with a vendor's releases. Getting behind can mean real problems in getting help for defects, especially if they have already been fixed in more recent releases. However, keeping up with releases to adapt to modifications or even to complete rewrites of the API can also lead to substantial work, and that work sometimes does not result in readily visible benefits.
As an example, AccuSoft's ImageGear is a third-party component that we use heavily, and due to the volatility of raster formats, is one that we need to keep updated. AccuSoft recently reengineered its ImageGear API to improve memory management, add support for additional color depths, and add support for 64-bit processing. While AccuSoft maintained compatibility with most of its prior API, some of the calls that we used heavily were no longer supported. Consequently, we had to invest considerable resources adapting code that was working quite well to use the new methods. This resulted in no visible additional features for our products, but should help overall system performance. For this release, AccuSoft produced a helpful document to describe the migration from old API to new API.
As another example, we did not keep up with recent releases of Autodesk's DWF Toolkit. We use this product for parsing and managing 2D DWF files, and had been happy with its 6.0 release for several years. We had reported no defects and fell several releases behind. When support became available for 3D DWF files, we decided to upgrade to the 7.1 release, and were surprised to find that the higher level aspects of the API had been completely reworked! Most of the API architecture was similar, but the details had changed—from renamed calls to argument counts. Migrating to this release required a complete relearning of the API, which was almost as much work as our initial implementation. However, in this case, the new release resulted in new features available in our product.
Conclusion
We've found great success in adding code libraries from other vendors, even to replace functionality that we had developed ourselves when our perceived cost of maintenance became too high. Using third-party components can be a great way for a development organization to save time and also provide application features that would be difficult or too expensive to develop in-house.
Previous Page |
1 Selecting Third-Party Components
|
2 Third-party Component Issues
|
3 Documentation & Updates
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
