fbpx

Hierarchy impedes team empowering

Some time ago I wrote a post on introducing code refactoring sessions to the team. For some time Clean Code refactoring sessions were very popular in the team. Then, however, the meetings suddenly disappeared … How is that possible if all of us really like the code quality meetings?

After some time, however, the topic of meetings on code refactoring returned. In a changed form, it settled permanently in the form of a code inspection session (this is our proper name). Although these sessions are not held every day or week, they have become an integral part of building team spirit.

In this post I would like to write about three things

  • How refactoring sessions could have disappeared?
  • What are new inspectoring sessions?
  • Why inspecting sessions has become part of our teamwork?

I think that the key and what the answer to all three of the above questions have in common is the motivation to refactor the code. Refactoring sessions (according to our definition) required the leader to prepare each such meeting. We expected from the person leading a ready refactoring plan, individual steps and definition of the final goal. This meant that when the “why so and not” discussion began, the moderator who wanted to present his idea was defending their solution.

Perfectionism kills motivation

Conducting such a meeting required a lot of work and effort. Moreover, one had to prepare more and more for each subsequent meeting. Better and better because of the longer and longer discussions. For this reason, each of us less often decided to prepare and conduct such a meeting

Vicious circle of perfectionism

This approach is known as the vicious circle of perfectionism. When you want to get better every day, you’re finally afraid to take the first step. Ultimately, in fear of failure, you even avoid your initial actions.

Our refactoring sessions had just (albeit unconsciously) this expectation of success. Perhaps it was carried over from the refactoring training I was doing. It was during my trainings that the planned refactorings were always successful. After all, it was a prepared training, so it is difficult for the presented refactorings to lead nowhere.

Let’s learn from failures

I remember when a manager in one of the companies encouraged his team to spend time on experiments once a week. He stressed that these experiments should have a 50% chance of success and a 50% chance of failure. And here he was 100% right. If your experiment cannot fail, it is not an experiment! The most important consequence of an experiment should be to draw conclusions – both from success and failure.


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 meetings 2.0

After several weeks without our refactoring sessions, one of my team members (thank you Jakub!) Suggested a different approach. He suggested organizing the “code inspection” sessions he had dealt with in his former team. The formula of this meeting defined the following roles

  • Code Reader – responsible for reading and explaining what the code does
  • Conclusions Writer – responsible for writing down action points
  • Code Author – answering questions if the reader cannot understand the code
  • Moderator – taking care of the whole process of the meeting

Despite the very restrictive formula, the meeting went very smoothly. But as you know, nobody likes rigid rules …. We want to be “agile”. Therefore, during the next “code inspection” sessions, we started to change the meeting rules. Experiments led to a slightly looser formula of meetings. We added what we liked. during refactoring sessions – that is, cleaning the code in real time.

This way we ended up with code inspectoring sessions : inspection + refactoring, Here are our new principles

  • Anyone can be the reader
  • The reader does not have to prepared
  • We value conclusions over much better code each time
  • We expect refactoring ideas to Clean Code
  • We discuss each idea

New motivational approach

This approach is named the “anti-perfect wheel of thought.” The only expectation is a better understanding of the code.

Together, we look for the reasons for the lack of readability and carry out live refactoring to Clean Code. Now all changes are the result of our joint discussion. Thanks to this, we exchange experience and build a common understanding of the quality of our code.

So the goal becomes continuous progress, not a perfectly set goal!

Spread the word. Share this post!