Quality Dream

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

  • read
  • understand
  • modify
  • extend

I think we all like when there is order around us. Then, for example in binders, it is easy to find something, or it is easy to insert a new document into the right place.

Unfortunately, often due to a mess, many programmers want to work (only …) on new code. Clutter keeps us away from legacy code, especially when we can’t efficiently refactor it to turn it into Clean Code.

Reality in working on code quality

And now the question arises: how quickly does this new code (theoretically Clean Code), written by us, become a Legacy Code? When nobody wants to work with it anymore, saying that now it would have to be rewritten? Because it’s no longer readable, testable, or extensible? And now this code is useless?

Or maybe let’s ask ourselves this question differently

  • how fast my own code becomes to be Legacy Code? Moreover I am ashamed of it now?
  • how fast my colleague’s code becomes a Legacy Code? When I do not want even to touch it and I do perceive it only as a source of troubles?

My experience shows that code written by others quickly gets worse. It is much less liked than my “own code” (if you can call it “my code”). So when indeed such a “clean code” is understood by the entire team as really clean? How to create such a code, and maybe how to change the current code so that the whole team follows the common standards of coding style and architecture?

How long does the new project contain better quality code?

A long time ago I became the leader of a team that was just created. So I was the first person in this team so the code we wrote was created from scratch. This is probably the dream of every programmer … It seemed that this “Clean Code” would be great and everyone would be pleased with it. A this point we knew it all depends on us now.

We used good practices such as code reviews. We were convinced that we create Clean Code, that is one that is readable, extensible and testable. What a surprise it turned out that after 6-9 months from the beginning of our project, each of us complained about the code written by others. Additionally, at the same time they were able to prove that it is his / her idea for design that is the most appropriate.

Download Free Training Sources & Join Refactoring Newsletter

Webinars, Articles & Online Courses / Onsite Workshops

Send me your newsletter (you can unsubscribe at any time).

I do accept terms and privacy policy

Refactoring coming to the rescue

There came a moment when we started experimenting with refactoring in the team. We all knew that “refactoring is changing the structure of code without changing its behavior.” On the other hand, I think that we didn’t quite know how to introduce this refactoring to our team permanently. Often times, refactoring is understood as rewriting the code (in better form). Meanwhile, real refactoring is the continuous improvement of code quality through small, but very frequent and continuous changes.

Therefore I decided to dig 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. I decided to conduct 5-6 small live-refactoring meetings with content of this training to see if it can give us visible gains in quality. Moreocwe – maybe later – make this training available for other developers in the company.

Before the first session of “Effective Refactoring” I did an experiment for my team. I searched for a piece of code that was very controversial. I prepared a plan of a refactoring this code to change it into a more readable one. Then I presented this refactoring “live” to show what we can achieve during such refactoring meetings.

The above experience was a very important point for the entire team. It initiated the discussion of what code we want and what should be Clean Code. We began to work on building a common understanding of the quality of such code, to create it according to our common standards. In addition, we saw that the code refactoring in small steps with simultaneous discussion is possible. Through this experience, we have built a team spirit.

Code refactoring sessions in the team

When we were learning refactoring while practicing my training, we decided that each of us would find examples in the code that we do not like. We then included these examples in the “Refactoring Opportunities” document. We decided that the author of such a reference would prepare a refactoring session, set up a meeting and carry out this refactoring “live”.

Each such refactoring session was combined with a discussion on the direction of changes in our design, our implementation patterns. Sometimes the meeting ended with accepting the change proposed by the author of a given refactoring. Sometimes the proposal provoked a stormy discussion. Then this discussion ended with the so-called “The third (best developed) solution” – the result of the commitment of all (Stephen Covey – 7 Habits of Effective Action: Synergy).

Code reviews cannot replace continuous refactoring

We can also use code analysis tools to look for places to improve code quality. Our experience shows that although such tools can find code duplications, in the end, team work on a solution is required. Live discussion, not through comments in Gitlab or Crubicle. Comments in these tools are for simple changes, corrections, but rarely for larger ideas.

We can achieve Better design / code 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.

Refactoring together is a team builder

The last point I would like to write about is trust and openness. During our first refactoring sessions, each participant – when it was “his / her code” was modified – struggled with a defensive attitude. This attitude was to defend their earlier idea of architecture. As time went on, we started to notice that none of the team were really attacking anyone. Each participant wanted to understand the existing solution or propose improvements to make it more readable. On the other hand, no one has ever intended to prove that something is badly designed or written illegibly. These things are very relative.

To summarize, I believe that it is not possible to have high quality code without constantly working on Clean Code. Refactoring is a critical part of the development process. When it happens in a team it “becomes part of the solution, not a problem” (Stephen Covey – The 7 Habits of Effective Action). Then you do not need to look for additional time.

Spread the word. Share this post!