[viraptor]

That looks like the manager's (or any other person spending money, not writing code) point of view... In reality you missed a couple of things:

- Buy an off the shelf program and take 3 hours to read their proprietary API for extra functionality. Then learn that you cannot integrate it into the current system (because of licensing, data format, missing features). Since you cannot make changes to the off the shelf program, you have to rewrite most of the existing code, just to satisfy the programs expectation. Or spend a month writing software that does a two-way sync between the proprietary API and the current data. Then learn that the API documentation is not complete/correct, then that new versions come out once a year - whether you need a bugfix or not.

I agree with the rest though... if there is a library, use it. Pay for it if you really need it. Just make sure you can modify it when needed and that you can do what the api/docs says you can - otherwise the software you bought is worth nothing as soon as you hit a problem, or you spend more money working around the problems than rewriting the software from scratch would cost.

[jaddison]

I'd say that if you're buying an off the shelf program, it's likely because implementing it would take FAR longer than the (example) 3 hours to investigate their proprietary API.

I think there is still a valid trade-off in purchasing - it just has to make sense, is all. If the problem is big enough that it's unwieldy enough (ie. take too long to develop and TEST internally), then it definitely makes sense to investigate 3rd party options.

That said, developing internally is sometimes the only answer: when you don't get a good feeling from the 3rd party options (based on research), when the 3rd party cost is too high, etc.

Of course... it's usually more fun to develop internally. :)