I’d say “Stop me if you’ve heard this one,” but Iknow you’ve heard it if you’re a coach:
“Dude, I write a hundred lines of code every day, but your TDD is going to make me write 50 lines of test, which is really just code, and 50 lines of code, and that means my productivity will be cut in half! QED.”
Someday, I swear, I’ll just stop right there, and say:
Dang-it, You’re Right!
Can’t Believe I Didn’t Think Of That!
Ok, Thanks, I Guess I Should Leave.
For a coach to not have an answer to this, she would have to be very stupid or very malign or both. No matter. Take deep breaths. Being a coach means possessing preternatural patience. Resist the natural impulse to become sullen and resentful.
See, the person who says those words has fallen for the lump-of-coding fallacy. This fallacy is simple. It says that what a developer does all day is “coding”, a great big lump of ineffable coding, like this one:
So there we are, game over, yes?
You see, coding is just shorthand for all the things a geek does all day:
Easy To Defeat
There’s a pretty simple technique to help the geeks around you to see the lump-of-coding fallacy for what it is.
Ask the team to list on the board all the things they do that are in, around, or about coding. A pro tip, I always make sure debugging is on the list, since it’s at the very least a third of coding time in most shops.
When the list is up on the board, just write in large letters at the top: CODING.
Gently remind them that anything that reduces time on a sub-activity increases productivity.
An example: debugging is an important part of coding because of the information it gives us. What if we could get the same info in a tenth of the time?