Friday, July 11, 2008

Buying in components

As a developer I like the challenge of writing new components and like nothing more than seeing a working, tested library which I can re-use and continue to tinker with for some time to come.

Now that I’m looking at developing a commercial product I need to decide if I’m going to develop the entire thing from the ground up or buy in some components which will jump start the project.

One of the core components I need is an e-mail library which supports SMTP, POP3, IMAP and SSL. My current prototype for the application already has a functioning POP3 Client and Server library which works very well. But, I would now need to work on adding the other functionality required.

So, I’ve decided to use a simple algorithm to determine if I should buy-in a tested, and supported, component or develop my own.

IF (DailyChargeOutRate * EstimatedDaysToDevelop) IS FAR GREATER THAN (CostOfComponent) THEN BUY-IN ELSE DEVELOP;

Using this algorithm already shows that buying-in a $300 component with a good track history, large customer base, all the functionality I require, no run time licence costs, no restrictions on commercial release and good support makes far more sense than developing from scratch.

It’s an algorithm that’s been used to good effect at home, with some minor tweaks:

IF ((HourlyChargeOutRate * HoursToCleanTheHouse) * DislikeOfHouseCleaningFactor) IS FAR GREATER THAN (CostOfHiringACleaner) THEN HIRE-CLEANER ELSE PICK-UP-BRUSH;

By allocating a few hours of earned income to this I save myself what could end up being weeks of development time.

No comments: