Continuous Alignment

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 book. 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.

Here are a few scenarios where refactoring opportunities can be utilized:

_Horizontal logic mixed with app-specific logic:_This is typically manifested in two flavors – cross-cutting functionality that is horizontal across several applications or domain-specific functionality that is applicable to a product line. Cross cutting functionality such as authentication, logging, error handling etc. can be refactored from app-specific to distinct components.

_Redundant definition of business objects:_maybe two or more of your projects are redefining a core concept from your problem domain and refactoring can help align them to a common definition. Once a common definition is used, add tasks into your iteration plans.

_Manage application configuration:_If several applications use ad-hoc set of practices to manage runtime configurations (e.g. xml configurations, property files etc.), refactoring them to use a consistent strategy would certainly make sense. This refactoring can be done one component at a time if time constraints make it harder to transform an entire suite of components in the app.

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.