This content has been marked as final. Show 4 replies
I spent most of my early career implementing basic and not-so-basic algorithms, because at that time there was no choice. I got to learn the foundations of computing rather well, say Knuth vols 1, 2, and 3, (especially 2 which is all mathematical), in environments where we were shipping licensed software products in quantity, so I also learned the disciplines required. Those disciplines don't always apply in the average programming shop, and, with respect, the average programmer isn't really up to the task of API design and algorithm implementation. Also, unlike me, the average programmer isn't actually a mathematician at all: you only have to look at the confusion created daily by floating-point to see that. Given the opportunity to rebuild any of those systems, I would certainly use as much existing software as possible, and as many commercial products as made commercial sense. In fact I was given such a chance, as long ago as 1992, and the design I specified did exactly that (we never built it, for other reasons); and indeed I am doing exactly that right now: I am shipping a system built on somebody else's framework, that uses upwards of twenty third party APIs, some of them indirectly, and five or six third party server products. And this is the industry norm these days. Unless implementing algorithms is your designated job, which implies that you have been (a) selected as being good at it, and (b) told specifically to do it, with (c) a suitable time budget, you shouldn't really be doing it.
Ultimately this comes down to price. If you embed a third party product and the royalties become painful enough, it may well become economic to reimplement it yourself. But you almost certainly shouldn't start out that way: you need to lower your risks and time-to-market and ship a product. After you've done that and it is selling, you are immediately in a different business. For release 2 or 3, which is basically paid for by prior releases, you can contemplate re-engineering to raise your equity in, and therefore your margins on, your product.
How that fits into your subscription model is another question, but I've always believed in corporate membership of relevant bodies. Three grand a year is around 7 days of programming time, less when you include overheads, and that's not even for somebody good.
Related to the previous response especially as related to something like Knuth....
The vast majority of programming will not use the vast majority of algorithms covered by something like Knuth.
Additionally there is a difference between having such code available and knowing when to use it.
1. You or other developers actually understand what the third party service encompasses.
2. You know that your development needs will need those.
3. The license is not restrictive.
Then $3000 is relatively cheap.
If any one of the above is not true then it will likely be a waste of money.
At various points in my career I've recommended buying 3rd party "widgets", "tools", or library subscriptions in lieu of developing them inhouse. They have always performed well, met our immediate needs, and operated fairly flawlessly under the configurations we purchased them. Problems have always arose as our fairly dynamic business rules mutated over time, and when we decided to migrate to different platforms for our enterprise.
Here are basic considerations you should have:
1- how dynamic are your business rules governing the specific function you are looking to purchase
2 - what is the responsiveness of the support for the product you are considering for changes
3 - what happens if you need it changed specific to your business rules
4 - will it impact your technology plan for the scheduled life of the product.
In almost every case that we purchased product or bought into libraries, our needs changed beyond the scope of support available from the vendors within 2 years and we ended up developing the products inhouse after all.