A Refactorability Approach to Software Reusability
“If creating a cyborg by plugging human limbs and machine components could become a reality, why is it difficult to create software just by plugging other software components?”, a pal once asked me. “The answer is in the question”, I replied, “Creating reusable components is as much of a trick as a cyborg”.
Five years back, reusability used to be as big a term as it is today. New technologies and increasing business complexities warranted creating reusable components to improve productivity and faster go-to-market times. Five years later, today, we still have the same problems. Technology has grown, programming paradigms have changed, business needs are becoming complex. Factually speaking, reusability hasn’t solved our problems. The reason is simple: Reusability is generally approached with an as-is usage in mind – create once and use many times. On the other hand, reusability needs to be approached with an altogether different angle. Here’s why!
Traditionally reusability is about the infrastructure aspects of a software like caching, runtime management, monitoring etc. It takes time to understand new technology, identify reusable pieces, design generic frameworks around them, pilot them and roll out across projects. The question of creating reusable business components is even trickier to answer as business requirements vary across applications even within a given domain. Even if you do manage to create reusable components, the next problem is to gain customer acceptance for such reusable components and break even on the investments. Add the learning curve required to understand such components as well. By the time all of these happen, we have the next version of the technology or a change in business requirement to contend with, and we run into issues of upgrading the components or creating new ones.
Oops. Did I say “create new ones”? Well, weren’t we talking about “reusability”?
Only such code can be reused if it does something that you want it to do again in some other application at some other time. But applications are as distinct from each other as are the sun and the moon. Although commonalities do exist, there is also a significant variability to contend with. Reusability in its traditional view does not deal with this variability factor. But then how do we really address all this buzz about reusability improving productivity, and faster go-to-market times?
The answer lies in looking at reusability through the mirrors of Software Refactorability. The ability of a software component to be quickly refactored and fitted into the new application is how I would define the term. Instead of aiming to create components for using as-is across many applications, this approach to reusability insists on creating refactorable components, so that, such components can quickly adapt itself to different applications and amend its behavior as needed.
I would further expand on this idea and ways to achieve it in the following posts.