Buy or Build?
By Elden Nelson
In the March 27, 2003 issue of asp.netNOW (the free e-companion to this magazine; subscribe at http://www.aspnetNOW.com), I asked developers, "What's your threshold for buying components or other technology, as opposed to coding it yourself?" I was impressed with the thought - and variety of criteria - that went into your responses. Let's take a look at some of your common criteria for buying or building.
Complexity: One obvious factor of whether you buy or build has to do with how easy it would be to do yourself. Brian Quinn says, "Normally I'll buy a product if it provides a complex function that I couldn't code."
Budget: IT budgets are stretched paper-thin right now, pushing developers to build, even when they'd be more efficient buying. Roy Barbour says, "Typically, in the current economic climate, the 'powers' will choose to build because my salary is a 'fixed cost,' as opposed to a 'discretionary expense.' So, even if the component provides more capabilities than I can write in a reasonable amount of time, management prefers 'good enough' or 'not at all' to spending cash. It wasn't always this way, but discretionary spending is highly scrutinized right now."
Research time: Simply finding a tool that does exactly (or at least close to) what you need can be an obstacle to purchasing. Greg Howe says, "I know here we struggle with 'buy vs. build' and it usually comes down to one thing: time. The time we spend looking at third-party products, reading reviews, and testing it out on a test app (usually to find it doesn't quite suit our needs) is not worth it. We are a small development group and our project list is huge; if we had a few more developers, we would have the time, and would certainly buy about half the time and build the other half."
The "Cool Factor": Does the tool do something that will amaze your boss/client/users? That's a strong factor for many of you. Says Wesley Davis, "Too many components are functional but not cool. I want something with a 'wow' factor, something impressive. To the user, and to me at design time (such as more design-time properties, or better wizards)."
Do Your Homework
Few developers build everything, all the time. When it's time for you to shop for a tool or component to integrate into your own app, you want to do everything in your power to get the right software. After all, its quality is going to reflect on the app you're building. I talked with Mike Schinkel, president of Xtras.Net (http://www.xtras.net), who makes a living getting developers the tools they need. He has some insightful tips you can use when you're researching:
Licensing: Is it royalty-based? Server-based? Be clear what the licensing model is and that you can live with the expenses and monitoring that come with it.
Support: If the tool you buy stops your product dead in its tracks and you can't get help from the company you bought it from, the product's not worth it, no matter what the feature set or cost. Does the company have phone support? E-mail support? Peer-to-peer support forums?
Returns: Not all vendors accept returns. Know whether your costs are covered if you discover the tool won't work for you.
Vendor size, focus, and longevity: A sole-proprietor vendor might not be around for the long haul. Very large vendors - whose main business might not be the tool you're buying - could drop the product line. This might not be crucial if you're making a one-time purchase, but it can be important if you're expecting to upgrade over several product iterations.
Feature set breadth and depth: Do you need a component that does one particular thing with great depth, or a collection? Know what you're getting, and do your best to project how it will suit your future needs.
What other criteria do you have for deciding between building and buying features for your apps? Got any success - or horror - stories from choices you've made? What's the best tool you've ever bought? The worst? I want to hear from you. E-mail me at [email protected].
Elden Nelson is editor-in-chief of asp.netPRO and its companion e-newsletter, asp.netNOW.
Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.