Last night,I had a talk with one of my friend who is also a developer at some other company,In his project,client is always looking for cutting the corners by which he could save on cost of development.
As a clever IT manager,For faster development,client’s IT manager is insisting on a design which has reusable components identified and well laid out,while my friend is collecting requirements and doing the requirement analysis. But to my surprise,my friend is also feel good about this notion.I think I am bit behaving like a pessimist here but I am somehow feeling uncomfortable because of this thought…since here they are treating the goal of system designing or architecting as reuse while ignoring the sole goal of architecture is to better serve business…to find the solution for business…
In my opinion, reuse should be side effect of your design and not the goal of your design.
Certainly reuse is a good thing to have inside your system but it should emerge rather than we impose reuse as goal on our design.It suppresses the creativity of fitting and integrating the different aspects of the system as well as it dangerously introduces the dreadful impact of looking the entire world into black and white rather enjoying the diversity and cleverly utilizing diversity as a strength of system.
The trap lies in perspective of architect or people who are designing the system since “emerged reuse” can co-op with inherent business changes that are going to come in lifetime of system while in case of “artificial or induced reuse” system can not withstand with the upcoming changes of business.This happens and I had observed it since "intended reuse" imposes "reuse" as a goal rather than just a strategy inside the system.
So the components are built with keeping today’s constraints in mind.While architect or even end users of the systems are not sure that whether today’s constraints will be there in future or will be removed.
Just on a curious note,Have you anytime observed reuse as a goal?
|Share this post :|