When we have the opportunity to reuse an existing component, but neglect to do so, a near copy of the original or a "clone component" is born. The cost of this missed opportunity is usually just counted as the cost to build the new clone1 . But this price is only the first one that we pay when we don't make an effort to reuse. There are even greater costs growing in the shadows of this missed opportunity. To understand these clone costs, we have to look at how we let them grow.
The system starts off with a simple, original component. Soon, an extension arrives where the original component should be refactored for reuse, but in our haste and shortsightedness, we create a clone instead. This is the first mistake, but it is usually not a single occurrence. If one new extension emerged, you can bet there will be another, and when the next one arrives, there are now two components to be refactored (the original and the clone). This makes the refactoring option even less appealing. Further, avoiding the reuse once has made it more emotionally acceptable to avoid it again. Sadly, Once we have created two clones of the original component, we have an even bigger problem. We now have a "pattern". This pattern only serves to further lower the barrier for more clones each of which increments the total cost of refactoring the system. How large can this problem grow? In one extreme case, I have seen cases where over 45 clones of a single, simple component were identified in a system.
So the cost of these missed reuse opportunities escalates to the total cost of all the clones plus the refactoring cost that we must take on to break the cycle. In this extreme case, the cost of the refactoring could not be justified. The refactoring cost was so high (at a multiplier of 45), that we could not show a return signficant enough to offset it. The cost of refactoring the system had actually exceeded the value proposition of the well-formed system itself.
If allowed to reach this extreme, another cost becomes apparent and this one becomes the most difficult to accept. At this point, any desired system enhancement may well require changes to all the components including the original and the clones. The total cost of these changes can easily outpace the business case that accompanies the enhancement. The result is that even simple changes in the system can be prohibited by overly inflated development costs. In the end, we are left with a system that can neither be refactored nor enhanced. It can only be maintained. The choice to avoid reusing components has resulted in a system that is a barrier to business innovation rather than an enabler, and that is a price that no one can accept for long.
The key to preventing uncontrolled cloning is to break the cycle as early as possible. In some cases, it may not be possible to stop the first clone. Often, the first extension is viewed as a "pilot" or a "test case" by the stakeholder, and in those cases, there can be reluctance to invest in reworking the original component. This may be fair, however, the extension must immediately be identified as a clone to both the stakeholders, and it should be documented as a clone to alert future developers. After this, a subsequent request to further extend the system must be acknowledged as a pattern. At that point, the original component and the clone must be refactored into a reusable, generalized component. If the stakeholder pushes back on this refactoring, cite the pattern and show them that this cycle will repeat itself unless it is halted. If they still push back, bring all of your architectural governance forces to bear to defend your systems against an attack of the clones.
________
1 The "reuse cost" of a clone is sometimes cited as 80% of its total build costs. Since reuse is not completely free, 20% of the original build costs seems a reasonable estimate for adaptation and reuse of the original component.
0 Response to 'Reuse and Win the Clone Wars'
Post a Comment