In a recent twitter conversation with Tracy Harms, @kaleidic, he discussed an element in how he worked and liked to work, called ‘mental coding‘. This is pretty much exactly what it sounds like: solving problems in your head (with full syntax).
A question a lot of folks have, and one Tracy brought up, too, is whether this kind of working is forbidden or made impossible by either pairing or test driven development (TDD). The answer is a plain no.
In extreme programming (XP), we have strict practices about what can and can’t be checked in. Specifically, code that was not created via pairing or TDD is not allowed in, and we require the whole team to rule on any exceptions. At first blush, this rule seems to exclude not only Tracy’s work mode, but also any of the other thousands of folks who’ve built their skill by means other than the official XP ones, which is practically everyone.
In 10 years of helping teams go to XP, I have seen many folks who were quite concerned about this. Years ago, at a very large printer company, I worked with a team that was piloting XP. We’d been going on it for a while, when I learned in casual conversation that one of my teammates was spending several hours each night working on studying and understanding the existing code, in addtion to the 8 hours a day she normally worked. I probed, and found that she did that because she felt that if she didn’t, she wouldn’t be able to pair positively with anyone else. She was quite convinced that she was such a bad programmer she could never pair with anyone because they’d be mad at her lack of skill.
I told her I wanted her to make a change starting that very day. She was to stop her nightly study sessions, and instead bring them into the workplace as a normal part of her workday. (I also urged her to come pair with me the next few times, so that I could help guarantee a positive pairing experence.) She was pretty amazed by how firm I was on this issue. She was also surprised, having read the pairing and TDD practices as the only thing she was allowed to do during the workday.
Regardless of the problem that cost of cialis affects libido, it will be difficult to restore it once more. Yes, cialis 50mg foods can be medicines. So for this take proper information about the medicine so always make sure that you consult a good doctor s guidance as a proper tadalafil buy cheap guidance is required in such cases. Around 25 percent of men who experience less than a single morning erection in a week are three times more likely to develop ED in men. * AntidepressantsDepression is also one cause problematic for vardenafil india the quality of sexual health.
I expect high-functioning teams to spend from 3-5 hours pairing and TDD’ing a day. (Every now and then, I work with teams that seem to routinely work like this all day long. They’re outliers.) What do you do when you’re not pairing?
Anything you want that isn’t part of a check-in cycle code is allowed. Code, talk, draw, read, as much as you want. Grab a pair when you’re ready. Write the first test when you’re ready.
Pairing is not about being chained together.
TDD is not about restricting how one prepares.
Extreme Programming is neither stupid nor mean.
If you find yourself doing stupid or mean things, call one of the XP pros, including me, right away.
Miguel,
Love it. I’ll add, if you’re [normal and] pairing/tdd’ing well, you’ll find anymore than 3-5 hours to be breaking another XP cry of “Sustainable Pace”. In other words, you’ll feel fried (and good for you for it!), and working in this fried mode is, well, ick.
Also, sorta reminds me also of Weinberg’s classic advice (granted in a different context, one of consulting) to split your time effectively. Plenty of your time to do “the other things” that aren’t explicitly your primary purpose, but that support your primary purpose.
Cheerios
MB
I admit that I’ve formed misconceptions about *pairing*, TDD and XP. It’s probably because I’ve never found a good source describing what a typical work day might be for a developer in such an environment.
Thanks for making it sound so straight forward and accessible.
Thanks, I definitely find this reassuring. I’ve struggled with the apparent contradiction between Agile emphasizing things that make so much sense, and TDD requiring adherence to rules that seemed quite the opposite. In particular I got hung up on the insistence by Robert Martin that not one line of code should be written without using the TDD discipline. I imagined that if he needs to calculate a square root he starts by coding a failing test!
From now on I promise that if it seems stupid, I’ll assume it isn’t actually part of the TDD approach.
I recently stumbled across a compelling white paper on pair programming. The results were based on research studies that showed, among other things that problem solving is greatly enhanced by working with someone else.
That same paper has a great quote from Ron Jeffries, XP legend on a humbling and revealing experience he had when paired with a novice:
“I was sitting with one of the least-experienced developers, working on some fairly straightforward task. Frankly, I was thinking to myself that with my great skill in Smalltalk, I would soon be teaching this
young programmer how it’s really done. We hadn’t been programming more than a few minutes when the youngster asked me why I was doing what I was doing. Sure enough, I was off on a
bad track. I went another way. Then the whippersnapper reminded me of the correct method name for whatever I was mistyping at the time. Pretty soon, he was suggesting what I should do next, meanwhile calling out my every formatting error and syntax mistake.”
– From http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
Back in Feb: http://agileinaflash.blogspot.com/2009/02/what-to-do-when-not-pairing.html