Refactor Code Often, Continuously, Every Iteration

March 24, 2013

Refactoring is a way to improve code quality over time using incremental set of improvements – the idea is to increase the ability to make changes safer and faster and is not meant to deliver new functionality per se. For systematic reuse to succeed, refactoring has to happen often and on a continuous basis.  Why? It provides several benefits from a systematic reuse perspective. For instance:

  1. You will learn which aspects of the code base have the most technical debt – what’s complicated to understand and extend/enhance? which parts of the codebase are difficult to verify via automated tests?
  2. See repetition more often and will eliminate redundant methods, classes, even entire chunks of functionality – over time, you will see the same capability being provided by a different library, or there is a new requirement in a project that can reuse the capability if changes were made to it etc. Finally – and this happens to me a lot – you ask yourself – “what was I thinking implementing it a certain way when there is a better approach?”
  3. Systematic reuse needs deep understanding of the domain – the team needs to tease apart different technical concerns, identify which ones are relevant for the business, and identify variations within the scope of candidate reusable components. Which brings us to the most important question – are the assumptions made earlier about the domain and the subsequent design still valid? This continuous validation and re-validation of the core underlying assumptions and design choices will ultimately decide the reuse effectiveness of the component
  4. Over time, doing this will provide the team with a valuable data on providing estimates – which parts of the codebase are tricky? which ones lack tests? which ones are bug infested? All these aspects weigh into an estimate and continuous refactoring will give the team very good insights.

So, please don’t wait for a project or a deliverable to arrive – start refactoring every day and across every project 🙂

Paper On Incentive Compatibility and Systematic Reuse

March 10, 2013

This paper on Incentive Compatibility and Systematic Software Reuse provides several insights on incentives and organizational structure that will impact and influence systematic software reuse.  A few questions and points to ponder:

  1. Are you tracking cross project dependencies with an eye towards developing and sharing reusable components? Is this word of mouth, best effort or more systematic and instutionalized?
  2. Do you understand the cost of systematic reuse? what is the cost of discovering and evaluating a component for a particular use case? what is the cost of developer training and learning curve?
  3. How is funding allocated for ongoing maintenance/upkeep/bug fixes etc. for reusable assets? In short – how do you keep the program humming – will it become sustainable?
  4. Which role will provide the curator or expertise with reusable asset integration? Which role will provide guidance on when to use and when not to use a particular component?

This paper provides several models for enabling and operationalizing systematic reuse. There are several organizational considerations to picking and adapting these models. Regardless of which model is picked it should become quite evident that enabling reuse isn’t a purely technical endeavour. It is much more than that – from understanding the true costs behind reuse to continuous governance – it takes considerable effort and lot of discipline to get returns.

Facilitate Reuse Through Interfaces

March 10, 2013

Predicting and designing for systematic reuse is hard – in trying to design for future requirements, team often bake in accidental complexity. One effective way to avoid that trap is to separate your concerns via well designed interfaces. It is important to point out that although separating concerns is essential, which ones to prioritize and plan for is heavily dependent on your problem domain. Additionally, it is not pragmatic to provide for variability across all points in your design.

Here is an example of facilitating reuse via interfaces – the example class takes a ReportResult object and needs to format them into a variety of formats (XML, PDF, etc.). Although this is a simple example it is powerful – as new requirements for supporting additional formats arise it can gracefully be extended. Plus, more importantly, formats that aren’t required don’t have to be implemented until there is a real requirement.

public interface Formatter {
    public T format(ReportResult reportResult) ;

The above can be implemented using specific formatters as shown below:

public class XmlFormatter {
    public String format(ReportResult reportResult)  {
       //implement logic for XML formatting

With the report generation and formatting separation in place, additional formatters can be implemented with ease – e.g. PdfFormatter, HtmlFormatter, or PlainTextFormatter, etc. This decouples formatting logic from report generation classes thus enabling reuse for the report generation functionality.

%d bloggers like this: