Team anti-pattern: The Helpful Teacher
Note: This post describes an anti-pattern that I have observed with software development teams. I wrote it as a contribution to Ola Ellnestam’s under-development book on Software Development Team Anti-Patterns. I recommend taking a look at Ola’s book for more anti-patterns. I like the short and concise definition of anti-pattern that Ola use in the book, taken from Wikipedia:
An anti pattern is a repeated pattern of actions, a process or structure that initially appears to be beneficial
The Helpful Teacher
“If we would only use test-driven development, our design would be better.”
As the self-designated technical leader of your team, you are constantly trying to help your colleagues understand and use good practices for writing high quality code. Even so, the code base is a mess and it is not getting any better. You have tried everything, from buying them books (with your own pocket money!) to showing them your own great code during a monthly meeting. The best you have managed is to convince some of them to try, but after a short while they always give up while telling you that it does not work. You are back to square one, or worse since now there are people saying that the practices you are promoting does not even work!
Studies in psychology* have shown that if we ask a person about their ability and competence in some skill, most people would estimate themselves as ranking above the average. (For an example, try asking people about their driving skills.) If we ask a group of people to estimate their own competence relative to the rest of the group, again most people consider themselves to be among the “better part” of the group. In fact, as the above referenced study shows, even the most unskilled people estimate themselves above average, because coupled to the lack of competence is a lack of awareness and understanding of that skill.
To be able to teach someone to use a new skill, they must at least see some need for it. Otherwise, from their perspective, you are only trying to push something not needed on them. Since they are unaware of the problem you are trying to solve, and therefore cannot distinguish your proposed solution from their defunct practices, all of your teaching goes in through one ear and directly out the other. “We are practicing test-driven development. We write tests in a Word document and run them manually before release.”
Before you can teach someone a new skill they must become aware of the need for the skill and their own deficiencies in that area. In other words, if you want to promote good technical practices for writing quality code in your team, you must first talk about the need for high code quality. The team needs to have a common understanding of what code quality means to them, otherwise everyone will just think that they are writing quality code and they do not need to learn new practices for improving on it.
Here are a couple of things you can try with your team to increase awareness on the value of high code quality, and to create a common understanding of what it means to your team. The thing in common between them is that they all encourage reflection and discussion.
The mother of all knowledge-sharing techniques. If you want to spread an idea to your colleagues you should never sit alone and program. No matter how nice code you write no one is going to notice it, and the practices you follow to achieve it will be completely invisible to the others. Try and spend as much of your time as possible working together with someone else. Do not push for all the practices you would like everyone to use, but use the opportunity to show your partner what you can do and the great results that follow.
- Code Reviews
Lots of organizations use code reviews as a way to achieve higher code quality. However, in my experience they are used in a command-and-control way, where you as the developer submit your code for review to the mighty architect, who then returns it with a number of things for you to fix. While some bugs and other problems can be avoided this way (depending on how much time the reviewer has to look into the code), it is not an efficient way of promoting high code quality in a team.
Instead, schedule a regular meeting where the entire team meets to review and discuss some piece of code from your project. As an alternative you can pick some open source project and review code from there. That way no one in the room is criticized, and it is easier to have open discussions about issues in the code sample. Rotate the role of selecting the code to be reviewed, make sure everyone has the code in advance to review ahead of the meeting, and then spend an hour or two discussing it together over coffee and a snack. If you want to you can follow up by actually implementing the improvements discussed in the meeting.
- Coding Guidelines
Again, most teams have a coding guideline that prescribes what is good code. They can contain things such as naming guidelines, where to put the curly braces and how many spaces the indentation should use. Sadly though, these are documents written a long time ago, by someone who is not part of the team or sometimes even no longer in the organization. As can be expected, they are not meticulously followed and it is not uncommon for people to be completely unaware of their existence.
Creating a coding guideline for a team should be a collaborative activity for that team. Gather everyone once a month, discuss what people think is important when writing code and find out what everyone will agree to do. Write this down, preferably on large flip-charts posted in the team room. After a month, meet again and continue the discussion. It is not really the results that are the most important, the discussions are where awareness and understanding is spread throughout the team.
If you can create awareness on the need for high code quality you will not need to teach your colleagues how to do it. They will already want to learn, and all you have to do is answer their questions. (Not quite, but lets not get into that here.)
* See for instance “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self Assessments (Kruger & Dunning, 1999)” for more information.
Use this link to trackback from your own site.blog comments powered by Disqus