Together with Marcus, I recently designed and led a workshop on refactoring, unit testing and other techniques for producing good code. To start the day off we asked the participants to list some characteristics of good and bad code. After getting most of the usual suspects on the list, one participant shouted out a new one, which should be pretty obvious. On the good code side is my code, on the bad code side is your code. Everyone had a laugh, but the fact is this is probably true if you ask most people about code.
As I said, it should be quite obvious that most people consider their own code to be better than someone else’s code, but I think we can make some profound realizations from looking into this more closely. There are two questions that are important to think about here. First, what is the effect of this issue? Second, how do we use this knowledge when working with a development team to help them produce better code?
An escalating mess
If I encounter some bad code, I will try and make it better. Since I believe my code to be good code, I will of course try and change the bad code to become more like my code. So, the code is better and everyone wins, right? Well, what about the other guy? He sees my code, and since from his perspective his code is better than mine, he will of course try and change it so it becomes more like his code. And round and round it goes. Each of us are trying to make things better, but together we are actually producing an ever escalating mess.
So, the important question then is how can we help developers realize that their good code might not be the best for the team as a whole? My bet is on communication. Using practices of communication and reflection between the developers in a team, we can create a common understanding of what good code means to us, and break the escalation.
Talk about code
Any time spent away from programming, instead talking about code and coding, is time well spent in a development team. If we want to get a common understanding of what good code is, then we need to have some formal structures in place to insure that this talking about code happens. Do you use pair-programming as the default mode of working? Do you do code reviews, where everyone on the team sits down and talks about some piece of code to learn from each other about how it could be improved? Do you collectively break down user stories (or other requirements) into tasks, using CRC design and similar techniques for exploring what a good design would be? Are you running a study circle?
What techniques and practices does your team use to make sure that you talk about code enough to have a common understanding of what good code means to you?
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.