This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Keeping in Tune
I was discussing refactoring the other day with a friend of mine. As is usually the case, the concept of code Smells came up. Once again, I thought about how amazingly uncomfortable I am with that nomenclature. I have had too many programmers come up to me and say that some other programmer’s code “stinks” or has a lot of bad smells. Its just too personal. It also implies something that is inherently wrong, possibly with the person who wrote the code. Rather than saying there is something here that feels just not quite right, we get something of a personal indictment of a person’s programming. Since agile development is all about valuing people, and fostering better communications and team work, it just feels wrong. This is along the same lines as my earlier post on why I don’t like the Scrum concept of Pigs and Chickens.
So how do we refer to code that is a good target for refactoring? I thought about other things that bring out the same ideas. What is there that, while you are experiencing it, feels just not quite right? Sometimes it is so out of whack that it is glaring, and sometimes it is more of a subliminal thing. The metaphor that works for me is music. The code doesn’t smell, its just slightly out of tune somewhere.
Now, I’m a musician. Worse than that, I’m a trombonist. This means I am intimately familiar with being out of tune! One thing about tuning is that it can be very simple, say one member of the orchestra is slightly flat, to extraordinarily complex. Say some members of the first violin section are sharp but others are flat, with the concertmaster the only one on pitch.
I see code the same way. You are in the code, and as you are working on it you find that something is not quite right. The first thing you do is look for the more obvious areas that are out of tune. Maybe an overly complex set of if..then..else statements. You write your tests and fix the tuning of this one area. Your tests become your “tuning note,” a common note that all instruments play and adjust toward. In orchestras that note is the concert “A”. You run your tests, and they all pass. But something is still out of tune. You go to the next section and find out who is out of tune.
Now there are all kinds of analogies we can use to totally abuse this metaphor, and I plan on exploring as many of them as I can in the future. For instance, you may decide that you are “in tune enough”. I wouldn’t choose to do this too often, but it can indeed happen. If enough of the code is out of tune, you may describe the design as cacophonous, which is always fun to say. Every musician gets out of tune. Good musicians are continuously tuning, even while they are going about the business of making music. It becomes a part of the fabric of her music making. Note that when you go to a concert you will never see a separate section on the program for “tuning”. That doesn’t mean it isn’t done, it just means it isn’t something special that is added to the list of works that will be played.
So let’s be nice to each other. Let’s think of code refactoring, whether we are doing extreme programming, scrum development, or any other software development process, as a way to tune our code, thus making it that much more pleasing to the end recipient.