Refactoring software

If you have done professional software development for some years then you know the value of refactoring. As time moves on, more and more
features are added to the software. The team learns a lot about the domain, problem at hand, broken assumptions and design mistakes. It is
natural that the team wants to correct the software with this new found knowledge. But most of the teams never do it. Sometimes there are valid
reasons for not doing it for eg

  • The software works and meets the user need. And the software has already matured enough. There will be no more active development.
  • The software contains lot of fixes with respect to issues from the field. If a refactoring is done then all this polishing will be lost.
  • There are no unit tests available for the software. So there is no way to check the refactoring for correctness.

But there are times when a refactoring is being avoided for the wrong set of reasons like

  • The product owner wants new feature over refactoring.
  • The team is lazy and considers the complexity as a pride.
  • There are no resources available to do refactoring.
  • Team wants to do a reengineering instead of refactoring.
  • The manager believes that refactoring is a waste of time.

From my own experience all these reasons can be avoided and refactoring can be done. Let me take one by one and see how we can get around.

Product owner wants new feature over refactoring

Refactoring will not provide anything new to the user. The user still provides the same set of inputs and the software responds back
in the same manner. So if we request the product owner to allocate time only for refactoring then we will never receive the time for it.
And the alternative is to take the entire new feature request and based on priority trade the least priority items for a refactoring. This way
product owner gets the new feature and the development team gets some part of the software cleaned up.

Team is lazy and considers the complexity as a pride

Most of the software development team starts with a clear and concise design. Over the time with the advent of new features and new team members
the design accumulates lot of incidental complexity. Instead of planning some time to identify and fix this situation, some teams tend to enjoy
this complexity. Smallest of the fix takes lot of time, new developers often find themselves lost in call stacks and no one can guarantee something
will work by design. If this situation is not properly handled then in the near future the whole software will need a reengineering. An expert
will always come up with an elegant and simple solution. So teams need to get out of their comfort zone and cleanup things then and there.

No resources available for refactoring

Most of the time finding resources to do refactoring is always hard. There are different solutions to this one and I have one solution that
always worked for me. Whenever I get a new team member as a replacement for some attrition I spend some time in training them. As a part of that
training I request them to refactor some part of the software. Yes new developers are crude, they lack the knowhow, they may complicate that
part etc., And one important fact is they have lot of energy and want to prove themselves. For me the refactoring succeeded most of the times using this technique. Give a try.

Team wants to do reengineering instead of refactoring

Most of the time if the topic of refactoring is started, some teams always want to throw the whole thing into bin and start a fresh. This may look
fascinating. But old code is not bad. It is not a rusting iron. Actually old code has accumulated lot of runtime knowledge. It contains lot of
small tweaks here and there with respect to customer feedback. So if a team is matured then it will always prefer to preserve the old code and
cleanup only those parts that are ugly.

Manager believes refactoring is a waste of time

In any industry the highest paid person’s opinion (HIPPO) has lot of value. So if you really want to do refactoring the manager has to be
convinced about the advantages and benefits. Here I have seen always show the benefit as something concrete. For eg number of saved man days,
amount of money saved, code/design metrics etc., Managers tend to believe hard facts and numbers over qualitative statements. This too has worked for me in the past.

So take that extra effort and cleanup the code.



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