Home > Software Engineering > To rewire, refactor, or rewrite

To rewire, refactor, or rewrite

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
  1. April 12, 2010 at 2:53 pm

    As a product owner/manager I have made a deal with engineers that they can allocate up to 20% of the available bandwidth to refactoring and strategic code improvements. The rest goes to solving relevant customer issues and implementing new features for the roadmap.

    I can’t say that I’ve seen a huge payoff in terms of saving on the future cost of refactoring. We still occasionally hit a speedbump where we must refactor, but otherwise, it’s been working quite well. Not surprisingly it’s also good for engineers’ motivation and psychological wellbeing since they now get a dedicated slice for paying down their “technical debt”.

  2. April 18, 2010 at 7:41 pm

    The biggest challenge I’ve faced as a developer is quantifying the technical debt, qualifying it’s negative effects, and giving management a reason to justify spending resources to fix it before it’s a much larger problem.

    Any suggestions on how to frame that discussion to ensure, well, more optimum results in the long-run for both sales and development?

  3. Steve
    August 18, 2010 at 7:41 am

    It is all about the risk governing when to rewire, refactor, or rewrite.
    This is not a fixed quantity and evaluating it depends upon the particular product and related factors for example projected lifespan of the product, is it core to the business plus many others.

    Convincing the management is another story, 99% of the time they don’t really care if the software contains a superb codebase. “Eye Candy” and “does it work” are about the only important issues. If you suggest new features will take longer to implement in the future this will not work neither. The answer every time is “use more programmers”. Of course we all know this never works, “it takes nine months to have a baby, no matter how many women you throw at the job”.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: