The last few weeks I have been working on a project that was initially designed as a general solution ready to be sold to many different customers out of the box requiring only some configuration. Since then many things changed, one of the two customers who wanted the solution changed his mind as he considered it too expensive, my company also decided this was not their core business and that at least for the moment, the solution will not be sold to new customers.
The generic solution that was being made was over-complicated, hard to understand and maintain. As a new person starting on the project, and the old developer all leaving it was nearly impossible to continue working on the code before getting familiar with every aspect. As time was closing on us, it was decided to abandon the old generic code and start from scratch with a customer specific solution. In this blog post I intend to discuss the benefits of both approaches.
When starting a new project the most important criteria to determine whether to go specific or generic is by how many different customers/users it will be used. How different is the usage of all these users, well let me tell you that every customer wants things to be different, maybe not much, but I have to encounter the first two customers that want the exact same product.
All the advantages of a generic solution come from the re-usability of the solution. If it can be reused with just some minor configuration changes then you can sell the product cheaper, deliver faster, to multiple customers at a time and thus earn more money. If you have to design a complete new solution each time, you can only handle one customer, it will take a lot of time and costs to deliver it. The main disadvantage of a generic solution is the complexity, how much do you want to be configurable? If it is too little you can’t sell it just like that and you still have to make changes, which may be costly as well. If it is too generic then you have to put a lot of effort in configuring the entire product which will also take time, and you have actually moved the cost from software development to product configuration.
Another clear disadvantage of a generic solution is that the customer can not choose freely how the software will look and feel like. He will also be more limited in what is possible (unless you are prepared to make many changes). A customer might value the possibility to have an application according to his design highly. How to sell a generic differs from selling a specific solution, in the first situation it is you who tells the customer about the software, tells what it can do, while the customer can ask for some changes or improvements. When selling specific software the customer can ask for as much as he wants as long as he is willing to pay for it all, it is more about designing something for his needs instead of molding the existing software to his requirements.
Having one generic software application may be harder to maintain, but having a dozen of specific applications will be even harder, unless they are maintained by different teams, but this quickly becomes way too expensive. In my experience it is also very hard to determine what needs to be configurable in a generic solution, especially if there is only one customer at the time of designing everything. You will often end up with many things that need to be configured but will never actually be used.
So what should we choose? Do we create the software customer specific or do we choose a generic solution. If you only have one customer, it is best to just design the software to the customer his needs. But keep in mind that good software design will be important if later on changes are required to match the needs of other customers. It is best to represent the core concepts of the application and use a decent level of abstraction and encapsulation. If this is done right you can later on create a more generic solution based on the specific one you created earlier. This way you can handle multiple customers while at the same time keep development costs low.
One final remark, and something I have seen gone bad at my previous job, make sure the configuration does not become too complicated. Just as with code give the configuration files a good design, and on top of that use some decent default values such that those can be omitted if they do not need to be changed.