The importance of refactoring

Describing refactoring to a non-developer person can be tough. Especially when this person does not understand the implications of the absence of clean code or other code-quality improving techniques.

If you try to explain code-quality improving techniques to non-developer persons, you might hear questions like “why haven’t you done it right the first time?”.

Even explaining why code-quality matters is really difficult, particularly when money is involved. For a person who is only interested in making money with the resulting software, improving code-quality sounds like a waste of time and money, because the software might work, even without improving the code-quality.

But if you want to continue developing the software, the code needs to be maintainable, well structured and as small as possible but still understandable. Because if it isn’t, developing new features and fixing bugs will become nearly impossible.

Communicating the importance of code-quality to a non-developer person verbally is hard. To make the process of highlighting the importance of code-quality and refactoring more easy, I created a four-quadrant matrix.

The Refactoring-Matrix

alt text

As the old saying goes “a picture is worth a thousand words”, this graphic is meant to explain the importance of refactoring and code-quality without going into detail too much.

The axes

In the grahpic, you can see two axes. The x-axis describes the time, which is spent in the current project (the time spent on the software).

The y-axis describes the time, which is spent on the implementation of new features or the time spent on bug-fixing.

The matrix in general is meant to describe the correlation between time, which has passed, and the effort which is needed to implement new features or fix existing bugs.

The red and green lines describe what happens if you do/don’t do refactoring

?

The quadrant on the lower left is the quadrant in which every new project starts. It’s too early to say something about the quality of the code, because there simply isn’t much code.

This should not happen

The quadrant on the upper left should never be reached in any project. If this quadrant is reached, it means that you need a lot of time do implement new features in the early phase of the project. This might still happen, if

  • people use a technology which is not suited for the task or outdated
  • people use a technology they are not familiar with, so they have to learn the whole language/framework
  • people put to much effort in thinking about absolutely every little detail instead of writing code

no problems

The quadrant on the lower right is the quadrant in which every project should be. In this quadrant,

  • new features are easy to develop in a short amount of time
  • bugs are easy to detect and easy to fix
  • the code is as small as possible and as big as necessary
  • there are many tests
  • tests are easy to write

This quadrant can be reached by constantly doing refactoring and constantly thinking about improvements of the code-quality and software architecture.

As you can clearly see in the graphic, the green line does not converge to zero, it’s more like a sinus curve. This means, that you can’t develop the “perfect” software architecture and never need to think about this stuff again. It means, that whatever is done in the project, the developers have to think and do something about the software-architecture/clean-code.

danger zone

The quadrant on the upper left is the quadrant, which a project should never ever reach. In this quadrant,

  • the code is unmaintainable,
  • the code is complicated/hard to understand
  • new features take a (very) long time to implement
  • bugs are hard to fix
  • there are no or too little tests
  • tests are (really) hard to write

The red line in this quadrant looks like the half of a parabola, which means that the red curve will rise very fast. Every feature implemented in such a project will take longer and longer for every feature that is developed.

This means, that after some time, the software will not be maintainable anymore. New features can’t be developed, because they would break something somewhere. It is therefore very important, that a project never gets too deep into the “danger zone”, because it might never leave it again.