Thank you for giving me your vote on the hurdles for software reuse. From the results, it is clear that the number one reason for not being able to build reusable software is the lack of time in the development process. This isn’t surprising at all and reiterates the core message that I have been communicating in this blog. Agility and refactoring are your friends with reuse. Take a very pragmatic approach to the reuse effort and you will increase the odds of success considerably. The strategy that I have successfully used with reuse is to pursue continuous alignment.
What exactly is continuous alignment?
The idea of continuous alignment is very simple – place value on moving towards your target state with every iteration, every release, every project. You may not get there day one and that is perfectly okay. Align your software assets closer and closer to a desired state using relentless refactoring and code reviews. Do this often and over a period of time you will transform your codebase.
Let me provide a simple example to illustrate this idea. Let us say you have a piece of code that sends email but is coupled with email addresses stored in a legacy database. You get a user story that wants alerts to be sent via SMS. Your initial iteration might implement this send SMS message without being aware of the existing email component. Why? Because you may not have time to pursue this and get the other stories implemented within the iteration window. In your subsequent iteration you refactor the legacy email code by making it generic so it can take any email address and removing the tight coupling with the legacy database. You take the code for this new reusable component outside your application codebase and update the SMS code to use this new email component. Be sure to add automated tests to your regression suite.
Now, this might be done in one, two, or multiple iterations. If you cannot get it done you add it to your list of known refactorings with your backlog of tasks. When the next iteration comes around and you get a similar story you go back and work on the known refactoring.