Bhoo wears the thinking cap!

As if that is possible!

To refactor or not, the classic dilemma for ISVs

Posted by bhoo on October 5, 2006

Current dollars Vs future dollars:  To re-factor or to run with the current code-base?

It is a classic dilemma for ISVs.

If you are running a software product company, you probably are very familiar with these conversations…

– The current code-base is not designed product-class. 
— It takes too much time to make any changes. 
— It is built using archaic technologies – we need to change it to the current technologies
— We need to reengineer so that all the customizations can actually be configurations
— If we reengineer the core product, we can cut customer implementation time by half
— We are not able to do any regression testing as the code-base is not coherent
— We cannot automate testing due to the way the code base is built
— Reengineering?  You must be kidding!  That is too much effort.  Not worth it!
— Our developers are too busy attending to the maintenance and enhancement issues thrown by customers.  How can we leave the revenues that can be earned by fixing immediate customer issues and focus on reengineering for the future?
— I agreee. Ideally, we should take a team out to look at reengineering efforts independently – but where is that team?  All our people are too busy – in fact we are leaving revenue on the table as we do not have sufficient engineering hands!

What is the solution for this conundrum?  Should you or should you not reengineer?  Here are some factors to consider:

1) Distinguish between being “occupied” and being “busy”

Are your engineers running from pillar to post on issues that are all related to the design of your software?  They are perpetually busy, fixing old problems and hence there is no value add to your product?

2) Think and define a Product Roadmap

More often than not, putting all the improvement ideas in the form of a product roadmap and fixing definite deadlines for releases and feature-sets of releases will fix the issue.  Sounds simple, right?  For those of you who manage it this way, it will sound too simple.  But, for a whole load of others, it will be best said and not done.

3) Think outside your internal resources a.k.a outsource

Absolutely!  If you ask internal guys, they say they are busy.  But, think beyond and look at long term.  After all, beg, borrow, steal – in short, be aggressive is the way for success in this age.

4) Is there real profitability?

More often than not, you will not clearly analyze profits in each customer instance, and that may end up as a sticker shock.  May be 80% of actual profits are hidden in 20% of the work that you do, and time to eliminate the remaining 80%.

5) Get external consultants

Many will scoff at me for writing this.  The reputation of consultants is such.  But, there is real value in consulting with people who interact with multiple companies that go though similar situations.


One Response to “To refactor or not, the classic dilemma for ISVs”

  1. Visit out Site

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: