Archive

Archive for April 11, 2010

To rewire, refactor, or rewrite

April 11, 2010 3 comments

What is one of the major risks – one that cannot be taken lightly – that a software company may face during a period of rapid growth?

Refactoring.

Let’s stop for a moment and ask:  what is refactoring?

Refactoring is a conscious decision to make fundamental changes in a product architecture (take one step backwards) in order to accelerate delivery of future releases (make several steps forward).  These releases may include long awaited functionality, new competitive features, improved performance.

It’s important to note that the single most important reason which drives the decision to refactor is acceleration of future releases.    Mature products with a short list of pending features do not typically become the target of refactoring.

What are some of the symptoms that refactoring may be necessary?

– Fixing one problem leads to several new and unexpected problems

– The backlog of critical new features is growing longer

– It takes more time to add new features with each new product release

– It also take more time to test each new product release

– Competition is able to deliver new product releases faster

Refactoring is very expensive and carries significant business risks.   That’s why most refactoring efforts tend to be reactive (in fact exacerbating business risks).    Because refactoring is so disruptive and often viewed as a measure of last resort, aggressive timelines and pressure to correct what has not been dealt with (aka “technical debt”) for a long time escalates the risks exponentially.

Refactoring does not have to the measure of last resort.

Complex, enterprise software product continuously evolves, with each new release adding new functionality.

The product’s architecture and code base should also evolve with each new release.

The key to success is commitment to continuous refactoring – or better viewed as ‘rewiring’:  eliminating duplicate code, making tactical changes to improve automated testing, increasing separation of concerns.

When ‘rewiring’ no longer produces results, the two remaining options – refactor or rewrite – become the subject of many healthy debates.

Commitment to ‘rewiring’ – or dedicating a percentage of time spent on each software release to make tangible code improvements – will yield significant benefits, either delaying or reducing the scope of major refactoring efforts in the future.

At some point, every software company faces the decision to refactor.  Refactoring is inevitable.  The only question is the extent of future refactoring efforts.

Categories: Software Engineering