3rd party components are a boon in today’s development environment- the can reduce considerable development costs, but they pose a considerable risk to the overall project if some important factors are not taken into account. I will like to put some of such steps which a developer/development team should ensure before making a choice of such component. These practices have become a part of our working at iSense India
- Performance of 3rd party components – It is always a good practice to try out a new 3rd party component by doing a spike/proof of concept before actually working on a concrete user story which would use these component. Usually developers do this spike in the development environment and make conclusions over the performance. The catch is that software code performance varies on different inputs and environments. To make a decision on using the component, a good idea is to test the 3rd party component with production or production alike environment. Components which would perform in the range of milliseconds in a development environment (with non-real and small data) will may become unusable/perform poorly when tested in production alike environments.
We at iSense India have a rule corresponding to this and can be helpful to others – Before making a decision to use a 3rd party component, always performance test the 3rd party components on a production alike test environment to avoid last minute surprises.
- Deployment issues with the 3rd party components – 3rd party components are built and field-tested for specific platforms and by external users. There is a good chance what works on one machine does not work on another. In case the production environment is not well defined before the start of the project, teams can make wrong choices on choosing such a component.
So in short: Always ensure that you have verified or know that the software you are developing will work on the final production environment
- Support : Most of the times there are options in choosing a control – Commercial/Open Source. Usually when you buy the commercial option choose the one which comes with the source and binaries. This would ensure that even in the future you can change or adapt the code to your needs. In case of commercial software you would also like to check what level of support the vendor can provide and if they have an active forum list. With Open source solutions this is not a problem as the source is always available. Also it’s a good idea to check the bugs/issues related to one’s required functionality
- Code Quality – At iSense we ensure that all code developed passes code metrics and analysis parameters. Usually, the codes in these 3rd party components do not score high on code quality metrics and practices and this can affect your complete application code quality.
- Additional training – Sometimes using a 3rd party component takes more time than developing it yourself, this happens when either the 3rd party control is a complex application, or one which has no documentation/information available and hence becomes complex to understand and execute within a set time. In such cases it’s better to put some effort and getting an available training from a fellow organization member/commercial vendor or partner who has experience with the tool. This training can save a considerable time while executing the project. This should also be factored in estimating the time to develop the software project.
After all nobody wants to re-invent the wheel, using 3rd party components can help you reduce the time ,effort and the cost but be careful with the fine prints when choosing one.






