30 Jan 2006
For some time now component technology has been touted as the saviour of the software development industry. The theory being as a developer I can purchase a set of components off the shelf and glue them together with my own code to create a completed application in double quick time.
As is often the case the reality is often quite different from the theory, over the last week I have been working with several frustrating problems in third party components in my own software.
Most commercial software has bugs, it would be quite unreasonable to expect components to be any different from the rest of the software world. The problem comes when your component supplier's priorities don't match your own. My business is small and flexible enough to address most issues in the product within a day or two, this gives us a huge advantage over bigger competitors who might not be so nimble.
Unfortunately even if your component vendor is able to respond as quickly as you you are still looking at double time to fix and resolve any problems. Sadly it's usually much worse than that, it's quite rare to find a component developer who gives support a high priority.
One option is to purchase source code to the components you are using, you can then dive in and fix any problems you encounter yourself. Back in the real world this isn't much of a solution, the code is usually written with different conventions to your own and the learning curve is often substantial. Right now I'm struggling with some code in a HTML printing library, the issue I have will require many changes throughout the code.
Having gone through these problems with every third party library or component I have used I am coming to the conclusion that I will end up rewriting the code for all of them myself in the end. As to whether it makes sense to avoid using components from the start I'm not so sure, getting your product to market quickly is probably more important.