Stop Apologizing for Your Code
Have a habit of apologizing for your code before showing it to someone else? You’re doing it wrong.
I’ve been the only TDDer in my team for about a year now. When I just joined the team, my TDD ways were looked at as a weird fad. Nevertheless, I kept working in my ways, know that, at least for me, it works best.
Working like that can be very frustrating. You make sure your code is clean, well tested and refactored. Then comes along someone that makes a small change and your tests no longer cover that part of the code. You open up some other part of the system, see bad code and though you try to follow the boy-scout rule, you can’t because you’d need to harness 10 computers and a goat to test the code in its current state.
A few months ago I asked Uncle Bob what is a programmer to do in such a situation. His response:
It’s frustrating and difficult. But what choice do you have? All you can do is keep at it. Shame the others by keeping to your disciplines.
And boy was he right. As months passed, and people glancing over saw me running hundreds of tests in a second and being able to make quick changes without fear (or very little), I noticed a weird pattern.
Whenever people asked me to lend them a hand with a piece of code, the presentation of the code started with a disclaimer: “Never mind how ugly it is“, and “I know it looks bad”.
At first, my ego always happy to boast, I took it as a compliment. Later, it dawned on me that it’s not that my code looks like pure prose simply because it’s TDDed.
What that apologizing means is “I’m sorry I don’t care about the code as much you do“. Uncle Bob was right, people were actually ashamed. Sounds weird right? But then again, if you do care, why haven’t you removed the need to apologize after the second time?
Get out of this shame-phase. Being ashamed means you care, do something with it. The next step is simply making the code cleaner. Some of my team-mates have already started down the enlightened path.
Remember, coding is a social activity. When you disrespect the code, you disrespect your friends. When you rock on, you all enjoy. As a wise man said, keep working on your code till you’re ready to project the code onto the wall for the whole team to see.
And if you’re in my shoes, keep it up. Sometimes all it takes is a little push.
You should subscribe to my feed and follow me on twitter!
Good post.
In a way code reflects many things such as organization structure (see Conway’s law, works vice versa), trust, personal values ie.
If you don’t trust your environment (other libs in this case) you are bound to code more defensively. On the other hand if there are no bounds, you are free to do pretty much whatever you want.
It’s interesting to see what having a few tests around does to your confidence. I know having tests pass doesn’t mean the code is correct. Even still, it’s cool to see that if I modified something (refactored even), it still ought to be pretty ok.
Of course sometimes having bad tests makes it twice as worse. You have to worry about both the code ~and~ tests. It’s not always easy to test the right things. I think this is one of the biggest hurdles especially for beginning testers.
I agree.
After I learnt TDDing; rarely I had to apologize for my code. For simple reasons:
1. When I write code; I do it ‘just enough’ to make a new test pass. If I don’t do this, I make the design unduly complex.
2. If I think my code is not clean; I go & refactor it. In most cases why developers shy away from refactoring is they fear of breaking something that they don’t know! TDD helps developers to get aggressive.
However, I find the name somewhat misnomer. Tests really don’t drive the development; they guide it. Drive comes from within programmer – his creativity. Tests make sure his creativity has a direction & gives him courage to refactor. There are examples like BubbleSort where tests drive you to the algorithm automatically, but that’s not the case always.
Also, TDD is not something that is confined only to software development. It has applications in every other field; but I wonder why they aren’t much talked about.
I have shared my thoughts here:
http://manojphatak.blogspot.com/2009/11/tdd-and-science.html
Your views welcome.
I’ve heard this “Never mind how ugly the code is” sentence way too many times in the past. I even managed to change some of these dudes who said it. But some like to stay in their comfort zone, or call it in the job-secured fox-hole. It’s damn hard to get these dudes going – the only way I know of is to keep being more successful then they are. Eventually they will break.
And for those who won’t… a good friend once told me: “if you were the leach that was clinging to the organization’s back for the last 10 years, would you change?”