BrainsLink

Linking the left brain and the right brain

Make It Simple and Fast Then Refactor for Better Software

Refactoring is a controversial topic within agile software development. There is no clear and simple definition of “refactor”. Martin Fowler wrote an entire book of over 400 pages on the subject called “Refactoring: Improving the Design of Existing Code”. You can find it on Amazon.

The generally accepted definition of refactoring goes something like this: changing the internal structure (or composition) of the software without changing the externally observed behavior (or interface).

That’s a pretty broad definition leaving much open to interpretation. Let’s examine some areas that are valid refactoring activities and some that are not.

Here are some areas that are covered by refactoring:

  • Cleaning up software source code to make it simpler or more easily maintained.
  • Adding test conditions to the software to help with automated regression tests.
  • Breaking up the code into modules.
  • Replacing an algorithm with one that is more suitable.
  • Changing data structures to make them more cohesive.

Conversely, here are some areas that are not considered refactoring:

  • Fixing defects.
  • Implementing new error handling logic.
  • Adding code for logging and tracking purposes.
  • Adding a feature that was inadvertently left out of a sprint.
  • Changing the code because the business has requested something new.

Refactoring is an important activity for agile teams. Just because code needs to be refactored doesn’t mean it was poorly written. Software developers routinely deal with incomplete information and tight deadlines — also known as uncertainty.

When faced with uncertainty, the most agile approach is almost always the simplest and quickest one available. Why spend a lot of extra time when you don’t know all the facts or you expect changes to be made? Do it simple and fast then refactor as needed.

The best agile teams understand the importance of refactoring regularly. Just don’t get carried away. Refactoring the same area of the software over and over is a signal that something is wrong with the stories, the design or the developer. What are your thoughts?

Updated: May 1, 2011 — 10:35 pm
© Damicon 2014 Frontier Theme