My Risk Plan for Software Development projects has a list entry highlighted in red: Review Ready to Use – Highly Customizable Assets handling.
When designing a solution, we all have clear criteria about what needs to be taken into consideration when selecting and adopting base components. We are usually aware about the complexities and risks when deploying on a new Operating System, Data Base engine, e-Commerce platform or when developing a new program from scratch. That said, in some cases we decide to use some Software Assets that can be used either as they come out of the box or can be highly customized if we wish.
The risk I have identified in the past is that many teams make the assumption that because those Assets are ready to use and have a brand or community behind, they will always work properly no matter how we use them, therefore almost no time is planned for tuning or customizing them. But this is not clearly the case, indeed most cases than less, when the team starts customizing the Asset the performance/stability starts falling below any acceptance criteria.
Let me illustrate this thought with a couple of scenarios where I have severely suffered this pain with common widely adopted products: jQuery and Hibernate. The first allows building extensions or overloading any of its function, the second allows the programmer to replace ORM automatically generated instructions with custom made ones.
Regarding jQuery, I have seen teams selecting it for being without a doubt the richest Java Script library available. The willingness to modify it, usually, comes from the need to get a tiny small incremental UX value, but teams do not realize that cost to make those small new features may end up being the most expensive elements of the project. My recommendation in this case is clear; do not try to customize it, use as it is and, if you need additional features, search for 3rd party components developed by companies where their live motif is to extend jQuery. Even though many of your programmers would tell you that they feel capable to modify/extend jQuery, use their talent to build new core business requirements.
Quite different is the strategy for Hibernate. While with jQuery my recommendation is not to modify it at all, when using an ORM you can’t avoid opening the hood and tailoring any poor performance set of queries. But in this case the challenge is to find the right Engineers. ORM does an excellent job with 80% of the cases, but the remaining 20% of automatically generated Data Base tables and queries could bring your application down on its knees. Optimizing this 20% can’t be done by any junior or medium skilled programmer. While the software automatization has increased software development productivity by an order of magnitude, it has, as well, shifted focus on most of the programmers and not many of them understand and care about the impact of poorly written data base queries. I know that in the new hierarchical model world with map reduce architectures your engineers would state that SQL and its performance problems are issues of the past, but the truth is that traditional SQL Data Bases still handle the biggest percentage of existing and new projects. In summary, if your project is expected to handle high requests volume make sure to have a Senior Engineer with performance optimization skills and put him at optimizing your ORM queries. Obviously if you don’t use an ORM software, you still need the expertise, the main difference is that in this scenario the need will appear obvious and explicit to your eyes. Should I add that the optimization effort needs to be made from the very beginning, I have seen teams delaying the optimization for a later state… unfortunately they never found the time to do so and the pain was severe.
In summary, when adopting a Highly Customizable Software Asset, evaluate when it is necessary or pays off opening the hood and evaluate if you have the required skills to do so. Where you expect a quick win, you may be opening a new and unexpected can of worms.