Episode 35: Why Comments Are Evil and Pair Programming With Corey Haines

Tuesday, August 11 2009 - Podcast

Subscribe to the show via or

 

About This Episode

In this episode Keith and Woody sit down with friend and traveling developer Corey Haines.  Here's a question, how many times have you written comments in your code?  Probably a lot!  In this show Corey gives some valid reasons why developers shouldn't have comments in their code (with a few exceptions).  The guys also discuss pair programming, what it is, how it is done, and the benefits of doing it.

Thanks to our guest this episode

Corey Haines is currently a freelance developer and journeyman, traveling around to pair-program with other developers. He is an active member in the software craftsmanship movement, focusing his attention on post-apprenticeship activities. He started programming in the early 80's by cheating at video games (they weren't compiled back then) and fell in love with development as a teenager. He currently specializes in Ruby, but will pair in just about any language you want. Corey can be reached via his website: www.coreyhaines.com Twitter http://twitter.com/coreyhaines

 

Show Notes

• The "How I Got Started In Programming" Interviews
• Cleaning Up Your C# Closet, Making Messy C# Code More Readable
• Witty Twitter

Download Show

Subscribe To The Show

There are three ways to subscribe to our show so you can stay current. We support standard RSS, subscriptions via the iTunes Store and we are also available in the Zune Market place. Chose your poison by clicking on your choice below.

#1 Anonymous on 8.14.2009 at 4:18 PM

I tried pair programming (was forced on me!) and it just sucks. I was doing it for hours everyday and I was tired by the end of the day. Watching someone mousing around on the screen and trying to follow their steps is tiresome. And unless they are talking all the time or you're asking questions about what they are doing, it's a waste of time. Two good developers working alone is more productive than one watching the other code. If you need help is some code or design, just ask.

I don't like someone watch me code. I want to take a break, browse the web, Google something, eat,drink, fart, pick my nose, snack, call someone or whatever and I can't stand it when someone is aware of all my moves. You have to excuse yourself every time you leave the desk. arrg! It's like someone breathing down your neck.

It's sucks big time. I complained to my manager that it doesn't work for me. I like to work alone. Eventually I left the company. What a relief!

As for the comments, just comment when necessary with one liners. It doesn't hurt anyone or the compiler.

#2 Corey Haines on 8.17.2009 at 11:43 AM

It is very true that pairing is much more tiring than working alone, exactly for the reasons that you mention about someone watching you code: it demands a much higher degree of concentration, focus and 'staying in the zone' than working by yourself.

From your first paragraph, though, it sounds like you weren't really in a productive/experienced pairing situation. Was your pair experienced, or was the idea mandated 'from above' with little to no training? A true pair-programming session does not involve a silent partner 'watching someone mousing around on the screen.' Instead, it is a collaborative event centered around a conversation that results in code being written.

I agree that with your statement:

"Two good developers working alone is more productive than one watching the other code."

The fallacy here is that this is a description of pair-programming. One person watching another person code has a specific, appropriate time and place, but I completely understand how you can get frustrated if that was your experience.

In the end, however, not everyone is equipped to handle the intensity, transparency and accountability of pairing. I don't meet a lot of people like that, but I've met a few; It sounds like you are in that group. It is a good thing that you eventually left the company; I hope that you weren't there too long, as being miserable at your job is an awful experience.

#3 bob on 8.19.2009 at 4:21 AM

hm

Not impressed. 101 lines of main method to 23 lines?

If you had a real job where you were working on applications with millions of lines of code, your 75 line savings would mean jackshit.

Write notepad in 50 lines of code the whole app. Write twitter in 50 lines of code the whole website.

Visual studio refactoring, what a joke you have to be kidding. VS is absolutely PATHETIC.

I wanted to like this, but this is a hick programming blog, and stop selling crap refactoring tools.

"There are some good open source [tools]", pls OMG.

Why do you use VS if its such a POS?

Pls stop blogging.

STOP MORONS

#4 steven on 8.19.2009 at 4:25 AM

@bob: troll more

#5 bob on 8.19.2009 at 4:43 AM

Yes, I am surely a troll because I've heard this podcast bullshit from 14 year old programmers, and I really dont need to hear this bullshit from 40 year olds building 50K line .NET apps to print invoices in the local hardware shop.

Or Ruby pussies talk about TDD or whatever. Yeah IM the troll. Cuz IM the one posting this utter garbage as if its enlightening to anyone who gives a shit.

I try to NOT insult ppl. SO shut down this BS blog and then you will cease to be a troll.

#6 bob on 8.19.2009 at 4:51 AM

As a newsflash, could the podcasters please mention how many millions of users their software has on a daily basis?

You can say 1, Ill assume the metric is in millions of users.

SO 10 would mean 10 [million] users.

Do you have that many? what about 80 [million]?

For software you have written yourself. The entire thing.

How many millions of users, online every day, do the esteemed podcasters have (combined)?

Combined would be fair. Im open to combined.

My guess would be about 100 [not millions]

How many beans in that jar boys?

#7 mknopf on 8.19.2009 at 5:47 PM

Great show, I am a developer who does in fact comment their code regularly and I believe that the reason is something that you may have missed during the talk.

The #1 reason I comment my code is so that other developers, who may not be at the same level I am at, can understand what i'm doing syntacticly. We have a Sustaining Department who currently are responsible for about 300 diverse applications. These guys are often intermediate developers and because I use Generics, Delegates, and other "not so easy to know what the hell that line of code means" code I comment it so that they can learn what it is I'm doing/using in order to better understand the overall program.

I call this "Programming for maintainability" because the guys who will maintain these apps are sometimes green, a few helpful comments can avoid HUGE confusion on there part.

I also agree 100% with what Corey said about Pair Programming, I'm a big advocate and we do this regularly (especially with the greener guys).

By the way, I work at NASA which is why we have so many applications in production (more then 14,000 currently).

#8 Jeffrey on 8.24.2009 at 9:07 PM

I would love to try pair programing at work but at work right now we have 4 developers and each works by themselves on their own individual project or two. Is my company too small too use pair programming? Can we pair program and still do as many projects in the same amount of time as we would if we programmed alone? Each pair would have to take on two projects at one time no?

#9 keithelder on 8.28.2009 at 2:04 PM

@bob

You are missing the point. Those 100 lines still exist, the difference is developers don't have to read 100 lines anymore, they only have to read 23 or whatever the number was.

I'm sorry bob, but reading 23 is less than 100 anyday in my book and is a big deal. That's a 75% gain in productivity for someone that needs to go in and edit the code after another developer has written it.

BTW, this isn't a "blog" it is a podcast and we sir, aren't going ANYWHERE.

-Keith Elder

Host of Deep Fried Bytes

#10 Ivan Assenov on 12.05.2009 at 3:37 PM

Hey, I noticed some interesting things.

First, it is not important how long the method, function is. More important is how many things it does. Method of 6 lines could do 4 different things. So the amount of lines means nothing. Also, it is important what language type you are using: dynamic or static. Dynamic languages would force you to write smaller methods, 100% code coverage etc..

Second, big enterprise applications are written by tens, hundreds people. Most of them are developers, not Software Engineers/Architects. What that means: comments are either bad, or missing. I often see something like issue#xyz DC 2/2/2000. The first thing I do with this is to remove it. Second bad comment I see is old code commented and left there for years. one time I found commented code for more than 10 years.

Third, XML comments are mandatory in my mind. Even if the method is private I would put xml comment, because I believe private should be tested as well, unless you use Eiffel.

Four, your code does not belong to you after you post it to the repository. I often hear: my code, my code, my code. It is not your code anymore. The code has to blend with the rest of the application. Now imagine if two guys are placing code in to same application. One guy makes one method with 1300 lines of code. He reports that he is done before due day. The second guy produces 100 methods and he is late for the due line. A month later the first bugs are starting coming. Who do you think the management will blame: the guy with 1300 lines method? I do not think.

Five, I never attend code review at the end of the cycle. This is already too late for me. I have seen for a long time code reviews done after the application is already done.

Six, I personally do not recall what my intention was when I write code. That is why in the xml comment section I would describe it with an abstract description. This way the code is maintain for developers, clients, anybody.

In general great topic. I think we need more of these conversations. We need to see people talking about quality. Thank you Corey.

#11 Kyle on 7.03.2010 at 10:33 PM

"It is very true that pairing is much more tiring than working alone, exactly for the reasons that you mention about someone watching you code: it demands a much higher degree of concentration, focus and 'staying in the zone' than working by yourself."

In my rather extensive personal experience, this is the exact opposite of reality in virtually all production shops (there are some exceptions, certainly). Pairing is 99% of the time used as an excuse for one member of the pair to check out entirely and shirk responsibility for a while. Then, they switch and the other person does the work. This is the reality of pairing in virtually all real-world scenarios. Software craftmanship, XP, and pair programming are great ideas, but they only even come close to working reasonably when both parties share the same values. Since 99% of developers don't, pairing doesn't work in the real world. The real world isn't full of boutique software shops, it's full or large-scale engineering operations. What works in a boutique shop will rarely work elsewhere.

My opinion is that software craftmanship is like socialism: it's a great idea if you can get it to work outside the lab, but you probably can't. Doesn't mean you shouldn't try, but keep your expectations realistic.

Leave a Comment