0740-7459/12/$31.00 © 2012 IEEE NOVEMBER/DECEMBER 2012 | IEEE SOFTWARE 85 Editor: Diomidis Spinellis Athens University of Economics and Business, dds@aueb.gr APIs, Libraries, and Code Diomidis Spinellis TOOLS OF THE TRADE LET’S SAY YOU want to display a JPEG-compressed image, calculate Pearson’s correlation coef icient, parse an XML ile, or create a key-value store. You can often choose between using the functionality of the application’s plat- form (Java EE or .NET), calling one of several available external libraries, or writing the code on your own. It isn’t an easy choice because you have many factors to consider. Speciically, you must take into account the task’s com- plexity, as well as the licensing, quality, and support of competing options. You can narrow down your choice by elimi- nating alternatives at the earliest possi- ble decision point. Here’s how I recom- mend you go about it. Where to Start? There are clear advantages in writing your own code: you control its qual- ity, your code plays well with the rest of your system (and you can even reuse other parts of it), you don’t introduce new dependencies, and you don’t need to make special arrangements to sup- port the code. The main deciding fac- tor here is the task’s complexity. You’re getting paid to deliver end results, not to reinvent the wheel. Unless the task is trivial to implement, professional- ism dictates looking at existing solu- tions. Handcrafting code to ind the biggest number in a sequence is okay if a corresponding function isn’t directly available in your environment. On the other hand, unless you work for a game studio or Pixar, building a 3D rendering engine from scratch is dei- nitely a no-go area. If some alternatives come as exter- nal libraries, start by looking at the li- censing terms. Many offerings might be available as open source software. See if the distribution license is compat- ible with your business model. Tightly integrating GPL-licensed code with a product you’ll distribute without its source code will get you into trouble. Less worrisome scenarios include us- ing open source code that comes with a more permissive license, such as the BSD, MIT, and Apache ones, dynami- cally linking against an LGPL-licensed library, releasing your product’s source code with a compatible license, or of- fering services over the Web rather than as a product. When examining propri- etary packages, look at the one-off cost and per-user royalties. Only a library offering strategic functionality might justify the administrative burden and cost of paying royalties for each of your product’s end users. Next, judge the usability of the li- brary or the platform API. Is the inter- face straightforward or complex and full of hidden gotchas ready to bite you? Some libraries require you to ob- tain an object from a factory for even the simplest operation and then ini- tialize it with various obligatory pa- rameters (including other objects that you need to create) before performing multiple actions, each of which can fail in several obscure ways. I’ve even encountered cases where the library will mysteriously fail unless I guess and setup its correct coniguration. I recently saw a CSV library that would process a large ile incorrectly, unless a buffer size was increased. Such be- havior is pure evil. Libraries should be conigured with sensible defaults that allow them to work faultlessly under all conditions (convention over conig- uration). Additional settings could im- prove their performance or specialize their operation, but they should never be required. You’re getting paid to deliver end results, not to reinvent the wheel. See www.computer.org/software -multimedia for multimedia content related to this article.