Generic vs Non generic solutions - which one is best?

Note :This post is still in draft mode, please feel free to add your comments to it.

------------------------------------------------------------------------------------------------
In this post, I have blogged down my thoughts from my past experiences. The topic discussed is about the pros. and cons of a writing generic code/solution. I have tried to put them from various dimensions of SDLC. To be more realistic, I will take a scenario of generic solution and revolve all arguments around it.

Scenario:
I am sure you all are aware of master screens. Lets say we need to develop a generic solution for master screens. Instead of coding individual master screens what if we think of a generic component/code that will handle all types of master screens.

1. Development complexity
Definitely the complexity of a generic solution will be higher. The reason is very simple. We need to consider the union of all requirements, in our case we need to think of all possible requirements arising out of all masters. We will also have to think of what possible new scenarios might come in future and how much of it can be accomodated in our design.

2. Maintainability
All designs look good initially. We may as well comprehend all requirements and design a good system. But it is an accepted fact that requirements never freeze in the software world. So, if the requiremens in one of the master changes and this feature is not available in our design, then we are screwed. We end up enhancing our design. The design has become more complex now. What I mean to say, is that if there are possibilities that requirements are diverisfied then a generic solution model might become too complex over a period of time and cannot be maintained easily.

On the other hand, a generic solution will definitely bring down the development time. Say a new master has to be developed, it can be done quite easily. Offcourse as long as the requirements are well withing the design limits.

Also remember that if there is a failure in the component all the screens are non functional.

3. Development time
Development time for generic solution will be high initially but will definitely save time later on.

4. Performance
It is a known fact that a generic solution might always be relatively slower. The reason being its genericness. Lets say the generic screen reads some configuration data and dynamically builds the UI. Obviously it will be slower than a traditionally coded screen.

5. Testing cycle
The benefit you get with a generic version is that once you test it, its almost done. You need not test again for a new screen in future. However there is a catch here. If your design changes, you need to re-test the entire component with all possible scenarios (all master screens), even for a change that was triggered by one of the screen.

6. Feasibility
A generic approach is always attracting, but before iniating any action, it is always good to do a feasibility analysis.

Some sample questions
Do we really have so many masters?
Will be have new masters coming up so frequently in future?
Is the development time for generic solution exceeding traditional development time for all masters?
Will there be high cost on maitaining the design?

7. High level Design complaince
Sometimes, the generic design might not be implementable due to constraints posed by the high level architecture or design of the business application. For example, the business application is totally object oriented. In such a sitation, the domain classes cannot be generalized. We still need to have seperate classes for each of the master entity ( say Item, Unit etc.). If this happens, then we need to accomodate these requirements too. The design is again becoming complex.

Alternatives

Generic component is not the only anwer for RAD. Instead of developing a generic component, we may as well think of a code generator tool to reduce our development time. There are plenty of tools in the market. However the major issue we land up with them is that they dont properly fit in out project environment (standards, architecture, design etc.) . The benefit you get with this method is that you reduce your time and still have the flexibility to customize code.

For example, in our scenario, we might want to try out tools that generate master screens autmatically based on database definitions. If you think its okay that master screens do not need to follow the same project standards, then these tools are really usefull.

Some known tools:

http://www.ironspeed.com/products/

http://www.codesmithtools.com/


Summary

At the end of it, it all depends on the decisions that are taken during design. My suggestions would go as follows.

Generic model :

  • Requirements are all similar for all masters and they will not change much in future.
  • There are numerious master screens.
  • Strong tech. team available to maintain it.
  • Lot of new masters will be added later on.
  • I would like to use this component in all future projects of my company.

Non generic model:
  • There are fewer master screens.
  • Functionality is varying.
  • Business logic might change in future.
  • Should be easily maintainable with any developer.
  • Very less possibility that new masters will be added in future.

2 comments:

Shaik Phakeer said...

It is amazing analysis

Thanks

Kishore said...

Good work Prashant.

I have one more issue. The genericity has many more dimensions. When we say tool, its just not only for building but for deployment too.

The very idea of being generic or not is highly dependent on productization aspect of solution development.

If I wish to develop a product then I will look in for generic.

There is a important distinction we should make here. Is it "generic" for RAD or "generic" for adaptation. We may adapt the theme and reuse the code snippets. If the case is executing a project with limited resources in terms of time, developers etc, then a non-generic solution is my choice.

Let us work more on this. Thanks for forcing me to think.

So a library and an API with multi-utility components may be considered.