My code is better than your code
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?
Use this link to trackback from your own site.blog comments powered by Disqus