Quality Dream

It seems obvious that each team would like to have source code that is :

  • quick to read
  • quick to understand
  • quick to modify
  • quick to extend
  • … quick to do anything with it

We just feel good if we sit in a tidied up room. Same about code – we feel good if we have quick orientation in it. Isn’t it true?

It’s been so common that each developer would like to work on new code, not on maintaining legacy code…. How many times did you hear this? 🙂

Quality Reality

So the question arises : how fast new code turns into legacy code that we do not like it any longer?

Or maybe let’s divide into me and others… :

  • how fast my own code becomes to be legacy one (so that I do not like it any longer and I am ashamed of it)
  • how fast my colleague’s code becomes to be legacy one? (so that I do not want even to touch it and I do perceive it only as a source of troubles)

My experience shows that other developer’s code becomes disliked a lot much faster that my own code. Clean Code is understood differently by different people. Therefore we need to find common way to understand what Clean Code means to the team and how to write such code (or is it even possible to write such code that others like from the beginning?).

Quality forever when started from scratch?

I’ve became a team leader that started from scratch. Fresh new code… Who doesn’t like it… It looked like a dream that now everything will be in such a good shape… We knew it is our “five minutes glory” and we can have the code quality we want, that we are the drivers of the quality, we are the only ones that are responsible for it.

We had Crucible reviews after each change (reviewed at least by 2 other developers) and we thought this way we can achieve the quality we want (code that is readable, understandable, extendable, …).

So how come that after 6-9 months since the beginning (and only after 6 months since reaching team size of 4 developers) we found ourselves in a place where each developer was complaining about the code written by others, and at the same time each developer was able to prove how good (clean) their own code / design is?!

Refactoring coming to the rescue

This was the time to start introducing habit of refactoring into our team. All of the team members knew that “refactoring is changing the code without changing its behaviour”. But the message “we can refactor” remained just a message that we didn’t feel a need to act upon. And “refactoring” word was rather understood as “re-writing”. It was not clear that refactoring can be small changes that are improving the design and are indeed done in small but (very) frequent steps.

Therefore I’ve decided to dig up (and clean-up) one of the trainings I’ve invented (and conducted lots of times) 2-3 years ago called “Effective Refactoring”. The plan was to make a trial within my own team by conducting 5-6 small live-refactoring meetings with content of this training and see if it can give us visible gains in quality and maybe make this training available for other developers in the company as well..

Before I conducted the first team-internal session of “Effective Refactoring” I made an experiment. I found a piece of our own code that we did not like completely (because it was too big) and prepared a plan how it should be refactored in small steps into better code. Next I performed this live-refactoring to show what we can achieve. This experience was very important to us because it began the very wanted and needed discussion: what is the code we want to have and how it should look like. We could also see that we indeed are able and brave enough to refactor our code in small steps.

Refactoring becoming a habit

When we were practicing more refactorings during our training sessions we decided that each of us will find the places that they do not like and put them into a document called “refactoring opportunities”. Next author of each “hate” could set up a meeting and prepare / conduct live-refactoring of such code into the shape they like.

Each such a meeting was accompanied by further discussion if the direction of changes is good for us. Sometimes we’ve ended up with the design proposed upfront (by the leader of meeting), sometimes we’ve invented together solution that nobody separately would probably thought of (Stephen Covey – 7 Habits of Highly Effective People: Introduce Synergy).

Code Review cannot replace continuous refactoring

Currently we use Crucible a lot to perform code reviews, because we know it can allow us to find mistakes, defects. But our experience shows that it does not lead us too much towards better design.

Better design / code can be achieved when discussing / refactoring it together. Therefore once needed, we set up a meeting and refactor given piece of code as a team. This turned up to be much better approach than only reading it in Crucible and exchanging comments. Anyway before each such session we need to be prepared, read and understand given parts of our code.

One final point I’ve noticed is trust and openness. When we were introducing our first refactoring sessions then each of us has struggles in not being defensive (feeling attacked) when “my own code!” was being refactored, although “my design was so well thought”. But during this sessions each of us could understand what others expect, so we write code that will be perceived as clean by the other members of the team as well.

To summarize : I think it is not possible to have the code we like if we skip refactoring. Refactoring is key part of development cycle. If we do this, “we become to be part of the solution, not part of the problem” (Stephen Covey – 7 Habits of Highly Effective People).

Spread the word. Share this post!

Leave a comment