Quite a long time ago I’ve written a post about refactoring sessions I’ve introduced into my team. They went very well for quite some time… and disappeared. How come when everyone said they liked it? Fortunately the idea came back in a new form as inspectoring sessions which happen from time to time… but very regularly.

In this post I would like to write about three things

  • Why our refactoring sessions disappeared?
  • What are our inspectoring sessions?
  • Why our inspecting sessions has become and continue to be part of our team work?

The key point that joins all three questions seems to be motivation. The refactoring sessions required the leader of the meeting to be prepared, to have a (rough) plan of refactoring, the goal, the refactoring steps. This entailed that the leader was (could be put) in front of 100s of questions and (maybe) better ideas.

This way conducting such a meeting required a lot of preparation and effort. Moreover meeting by meeting you had be prepared better and better. This way – as perfectionism kills – it seemed to be more and more difficult to decide to set up, prepare and conduct such a meeting.

 

 

It is called “trap of vicious perfectionism circle”. At some point you want to be so perfect that you are afraid even to try. I remember when one of the managers in Ocado was encouraging his teams to experiment every Friday on new ideas with a strong emphasis on 50/50 chance of success. And he was 100% right! If your experiment cannot fail (or at least is expected to succeed) it is not an experiment! The only expectation for experiment should be to draw conclusions – from the failure or from the success!

 

 

Our refactoring sessions has a strong expectation of success. Maybe it was just followed by the refactoring trainings I’ve conducted – as lots of people did really liked the refactorings we did. This was because these refactorings were (of course) prepared to succeed (like in such a training). In my opinion as a result of this (not written) assumption our refactoring sessions were organized more and more seldom.

Fortunately one day one of my team members (thanks Jakub!) proposed a different approach. He suggested to set up “inspection of code” meeting. The formula – taken from his previous job –  was going to be completely different. The meeting should have

  • 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

The meeting went quite smoothly although it’s formula was slightly strict. As you know developers want to be flexible & agile, not strict. Therefore during next “code inspection” sessions we experimented more and more. The experiments led us to loosening up a little the rules and adding what we liked from the refactoring sessions – live code changes during the meeting and discussions.

This way we ended up with code inspectoring sessions (inspection + refactoring together) that

  • Could be conducted by anyone
  • Did not require the leader (reader) to be prepared
  • Did not expect we will end up with much better code
  • Were strongly expecting the attendees to be involved
  • Where each opinion was considered and discussed

The above is called “anti perfectionism circle of thinking”. We were expected to understand better given piece of code / functionality. To discuss it, and maybe to make it more readable if needed. We were (and are) striving for improvement (of our knowledge, of the code quality) but not for perfectionism. That’s it!

 

 

In the next post I will share more of my thoughts about refactoring – why it (or does not) happen in the companies. I will look at it from many perspectives like business and development team relations, (agile / lean) process management, product management, people management.

Leave a comment