acm - an acm publication

Articles

'Build or Buy' Your Next Porsche?
Thinking Clearly About the Component Approach to Development

Ubiquity, Volume 2005 Issue November | BY Rob Meyer 

|

Full citation in the ACM Digital Library

Rob Meyer, CEO of the Numerical Algorithms Group, wants you to be thinking clearly when you consider the component approach to development.


Imagine going to your Porsche dealer and asking him to sell you a new Carrera GT (mid-engine V-10, 605 HP, 0-100 kph in 3.9 seconds) but then informing them that you'd like to have them replace the engine with one you'd built in your home garage. Farfetched? The tools and the parts, if not the know-how, are a few clicks away on the web though few of us would seriously contemplate building a car this way.

From the point of view of specialists in mathematical, statistical, and data mining components, this is an apt analogy for many 'build or buy' decisions surrounding analytical application projects. For many complex applications such as these, the arguments for 'in-house' building are as difficult to justify as their equivalents for building the engine for your Porsche at home. Even if the talent to do so is available internally, that talent might better be applied to identifying the best available components to incorporate into the application. This could ultimately create more value and competitive advantage for the business.

The build-it-yourself argument usually asserts that the biggest drawback to using commercially available components is the lack of source code and the resulting inability to tailor the code for very specific needs or performance requirements. Indeed, in some combinations of algorithm, customer expertise, and functional requirements, this could be the case. For relatively straightforward functionality there is good open source code that can be used as a starting point. This approach can and does make sense for some code and some projects.

However, things can go wrong and there are a number of factors to consider in making the decision. A well-known American football coach was once asked why his team ran few pass plays. His answer sums up this decision: "On a pass play there are three things that can happen; two of them are bad." In the case of complex numerical code, he was an optimist.

The most obvious problems involve the accuracy and stability of the modified code. Ask yourself these questions:

  • What do you know about the accuracy of the code you are starting with? With your compiler? On your hardware/operating system platform? Do you have an independent way of validating the answers from the code?
  • What do you know about the robustness of the code? Any code will break under right combination of data. Where will yours become unstable? Will it warn you, produce diagnostics, or will it simply give meaningless answers without warning?

Beyond the executable code there are a few other things to think about:
  • How good is the documentation? If your application has a life that exceeds a few months, the chances are good that the original developer won't be available to diagnose problems, port it to the next hardware/operating system platform.
  • What's the lifespan of the application? A few months? Or a few years? An irony that developers can appreciate is that their investment with the big price tag and long life these days is the software, not the hardware.
  • How critical is the application? Is a billion dollar portfolio, lives, or something much less significant riding on the accuracy and robustness of the application?

Application development in real life is rarely simple or easy. The one month project to modify some publicly available code using internal staff has the risk of ballooning into a six month exercise effectively costing $50,000 when the full cost of an experienced developer is considered. Remember too, to look at the license for the open source code you are considering as a base. It may not permit free commercial use or may include other requirements that are unwieldy. Finally, keep in mind that you may also have to indemnify commercial users of the application for flaws or intellectual property claims.

You may conclude that commercial components are the right path but what if the functionality you need simply isn't available? The choice often comes then to building your own or finding someone to do it for you. If you conclude that building it yourself isn't the best decision, what should you look for in a supplier? Consider the following as a guide:

  • A supplier with quality components similar to your requirements
  • Someone who has both numerical code experience and software engineering expertise.
  • A partner with the proven depth of expertise in complex projects and the longevity to be there for support and changes in the future.

Build-versus-buy decisions are rarely as easy as the one about the engine for your Carrera GT. The technical, legal and business issues can be complex but a common sense look at the functionality needed, the application itself and the alternative use of internal resources can make your next application development project a pleasant dream rather than a recurring nightmare.

About the Author

Rob Meyer is CEO of the Numerical Algorithms Group (www.nag.com), an organization dedicated to making cross-platform mathematical, statistical and data mining components and tools for developers as well as 3D visualization application development environments. NAG operates worldwide with offices in Chicago (USA), Oxford (UK), and Tokyo (Japan). Today it serves over 10,000 sites and has created a worldwide collaborative network of the world's best mathematical experts. Questions can be forwarded to Rmeyer@nag.com

COMMENTS

POST A COMMENT
Leave this field empty