Skip to end of metadata
Go to start of metadata

When considering a library to use in completing a task, one should consider the quality of the product and the effect its inclusion will have on project development. The following quality guidelines are provided as a rule of thumb. 

  Author Testing / Investigate the public's view of the library / Support

When rating the quality of a libary one should consider tests the library went through.

  • Was the library tested using rigourous methods, such as benchmark tests? (McCullough 1998)
  • Are the memory and computational requirements that have been tested similar to the requirements you'll be imposing? 
  • Were there a team of dedicated testers for the library?       

Consider outside testing of the library.

  • Type the library's name into google, and do a brief search of the results for bugs reported by other users.
  • Look for resource/time problems users of the libary may have required. Some algorithms require too much memory/space for a simple workstation. 

Look for support/future updates. 

  • Is there a web page with an active forum,mailing list or resource devoted to helping users with the library?
  • Are library bugs being tracked and documented?
  • Is there active development for the future versions of the library?

  Practical considerations

When choosing a package for use one should consider several cost/benefit results of the package in terms of project completion:

  • Will too much training be required for the package?
  • Will other programmers on the team be able to use of the library? Will the other members require training?
  • Will the inclusion of the library cause significant problems in distribution of project deliveries? ( Software license, User Agreements -- all of which can take time/resources ).
  • None