This week's book giveaway is in the Programmer Certification forum.
We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 and have Jeanne Boyarsky & Scott Selikoff on-line!
See this thread for details.
Win a copy of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 this week in the Programmer Certification forum!

Damon Black

+ Follow
since Oct 10, 2007
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Damon Black

Originally posted by Ilja Preuss:
...I seriously doubt that it's only about "liking to think out loud".

Agreed, it was about much more than just that. A fair number of XP's practice went against the grain for me.

After some more thinking, I might come up with the idea that it was *me* who failed to influence the process in a way that was both acceptable to me *and* my teammates.

Yeah... well it wasn't my teammates who fired me. They were actually quite accommodating. Regardless, I tried taking this on myself for two years, thinking all along that something was wrong with my approach or skillset that kept me from thriving in an XP environment.

I've heard it said that XP isn't for all programmers and I have to agree. Given the industry's limited experience adopting XP in broad fashion, I suspect it may yet turn out to be a poor choice for most programmers. But that's just a guess.

I'm still quite open to the spirit of Agile and XP, though more cautiously. I don't think any methodology is perfect, and XP is no exception. The one thing I will seek to avoid is any shop that assumes that their pet methodology answers all questions, especially if its every breakdown is blamed on 'operator error'.
[ November 12, 2007: Message edited by: Damon Black ]

Originally posted by Lasse Koskela:

Agreed. People over process. Again, however, I've found XP and Scrum being much more "people over process" than any alternative I've seen.

I still think it's mostly a matter of temperament. For people who like to think out loud and thrive on constant interaction with others, XP feels like "people over process". For me it was the opposite.

Originally posted by Rusty Shackleford:
The problem with any process is that it is a one size fits all approach. What makes XP worse is that it is very rigid. One part fails, the project starts spiraling down.

Whether XP is supposed to be so rigid or not, I've seen it applied in exactly that way. All of my attempts to modify the process to work for me were rejected outright.
[ November 12, 2007: Message edited by: Damon Black ]
Heh... I just realized you authored one of my favorite programming books. I wish I'd found it sooner, as I'd already been working at Agile for a year or so when I read it, but it really helped me see things in context and filled in more than a few blanks. Thanks!

Originally posted by Jeff Langr:
- the discipline to always write tests first
- removing as much possible duplication in code when refactoring, to keep the code base clean. Most developers, even senior ones, don't do this enough.
- figuring out how to automate acceptance tests

We managed to test-drive pretty consistently, but often the red-green-refactor cycle devolved to red-green-"next!", especially under time pressure.

That last one was spotty. We squeezed quite a lot out of Fitnesse, but in my opinion over-used it for page display tests. Selenium looked promising but was deemed too slow.

Of course pairing has my vote for the 'weakest link', but that's more my deal than anything inherent in XP.
[ November 08, 2007: Message edited by: Damon Black ]

Originally posted by Ilja Preuss:
... not a flaw of XP itself.

out of curiosity, what are XP's flaws, in your opinion?
I read the second book first, then the original. My general impression was that the first took on a more confrontational tone, where the second seemed more inclusive of the business perspective. And I have to agree with Jeff, the second book did seem to suggest more flexibility. If Kent Beck is saying that both books describe the process, then I'd say we have to take his word for it. But there do seem to be subtle differences in the message. Maybe he needs to do a third edition to clear things up.

Originally posted by Jeff Langr:
But XP version 1 explicitly expected developers to pair on all production code.

Ayup. We were explicitly a version 1 shop. Our 'coach' bought up a bunch of copies of the first edition book and made sure everyone read it, rather than the second edition.

I think the business can and should mandate that code is reviewed rigorously--they need to protect their investment. I don't think most organizations should go as far as mandating the means. That could be through pairing or some other mechanism (Fagan inspections?).

Oh yeah... I definitely see the need for review. I read Peter Goodliffe's Codecraft a few months ago. While I gather that much of what was in the book was considered 'traditional wisdom', most of it was new to me. In particular I liked the idea of regular code reviews, as it seemed like a great way to see the big picture and maintain knowledge of the architecture as it develops. Like most of my impulses, the idea was rejected out of hand by our 'coach'. "We do continuous code review, that's what pairing is." I can see how that's how it should work, but it rarely did.
[ November 02, 2007: Message edited by: Damon Black ]

Originally posted by Jeff Langr:
In all honesty, most "agile" shops don't do pairing, or if they do, they do it infrequently and inconsistently. It's mostly the shops that actually use the word "XP" that are doing the pairing. So I don't think you have to worry too much about places to choose from.

That's reassuring. And it's more or less the impression I got at Agile 2007, where a great many of the sessions were about convincing management to try some agile practices. None of the people I talked to there worked in in shops as rigidly agile as my previous employer. I'm going to go on the assumption that seeing "agile" in a job ad doesn't necessarily mean they pair, or do the bullpen stuff.

I've written a few articles on pairing; I usually talk about how I came from your position of resistance, but that I grew to really enjoy it and have gotten a lot of benefit out of it.

For me, it sort of seems the opposite. See, I started at an XP shop and initially I was very enthusiastic about all of it, including pairing. But from the beginning I felt awkward and clumsy when I tried to pair. For a long time I assumed it was just a matter of my inexperience. I assumed that as I became more confident and skilled (at both coding and pairing), things would improve. So I've spent the last year and a half working hard to make that happen. But even though I'm a better coder, and somewhat better at pairing, it still feels wrong.

The thing that really gets me, is that when I do have the luxury of working alone, the difference is like night and day. Everything makes sense, I'm calm and focused, and productive, and I actually have fun while I work.

I would be leery of working in an organization where someone up above (a VP, perhaps) insisted that every team had to pair.

That's exactly the situation where I used to work. I really do think pairing would be far more useful, and enjoyable, if it was treated as a tool that programmers can use when the need it. To apply it as a mandated practice seems to be a misapplication of the stated values of agile and xp.
[ November 02, 2007: Message edited by: Damon Black ]

Originally posted by Damon Black:
I guess it's the "If done properly" clause that's the kicker. In my few years of dealing with it, that's been a rarity. So I wonder, how effective is a discipline that is so easy to do poorly?

Originally posted by Jeff Langr:
I could say that about just about anything, including Java development itself, or RUP, or waterfall.

I suppose you could. And given that I've never done 'waterfall' and that I don't even know what RUP is, I'll have to take your word for it.

So, in your opinion, is there a place in an 'agile' shop for someone who works better in a quiet, focused setting (not pairing)?
[ November 02, 2007: Message edited by: Damon Black ]

Originally posted by Ilja Preuss:

Originally posted by Christophe Verre:
I hope you'll not say that this as an advantage of pair programming

But it *is*. Seriously.

I can attest to this as well. It's one of the most useful benefits of pairing in my book. Honestly, seeing these shortcuts used repeatedly, and feeling a subtle pressure to use them yourself, helps push you into learning them (when you might not have gone to the trouble otherwise). And I've never heard anyone grumble about it once they adopted the habit.
[ November 01, 2007: Message edited by: Damon Black ]

Originally posted by Mike Dawson:
If done properly it brings a dynamic all of its own where you can learn.

I guess it's the "If done properly" clause that's the kicker. In my few years of dealing with it, that's been a rarity. So I wonder, how effective is a discipline that is so easy to do poorly?

That's where I start to see much of the XP/Agile zeitgeist as pie-in-the-sky fantasy. It doesn't help that most of the theory was cooked up by gifted, experienced coders looking to work in a way that was comfortable for them. My guess is that if you assigned several of these guys to a team they could successfully work through (or around) just about any methodology. The real test is how the average team in the trenches deals with it. My experience with that end of it argues strongly against XP.

As far as pairing goes, I still think it's largely a temperament thing. If pairing is an optional tool that programmers can use at their discretion, it can only help. But as a required practice it flies in the face of 'People over Process' in a big way, ignoring the fact that some people have a really tough time 'thinking in unison' with another person.
[ November 01, 2007: Message edited by: Damon Black ]

Originally posted by Ilja Preuss:
...I also wonder whether the team did iteration retrospectives where such issues where discussed openly.

I missed this comment earlier. We did, in fact, have weekly retrospectives. It was in these that I began openly doubting our company's dogma on XP. We had one the morning before I was fired.

Anyway, I'm beginning to see my dismissal as something long overdue. I need to get very far away from 'agile', especially 'XP', for a while.

I see a lot of good things in agile practice. TDD, 'simplest thing that could possibly work', short iterations, on-site customer - all these and more seem like practical, common-sense solutions. But I've grown very weary, and wary, of approaching these techniques as a means of 'revolutionizing software development'. I just want to write code. I'm not interested in political, or religious, devotion to any methodology, least of all one that insists that I must program in a way that directly impedes me.

Originally posted by Ilja Preuss:
Anyway, if we ever meet, I would be highly interested in trying some pair programming with you, just to see what happens. I'm sure we both would learn something from the experience...

I'm sure of it! I can actually enjoy pairing, if the point is mentoring, or if one partner is looking for specific advise in some area. But if the point is be 'productive', it doesn't get me where I need to be.

Originally posted by Stefan Bell:

As a lead developer and technical architect, I have experienced mixed results. Some of our most productive and talented programmers have not faired well in PP. I know what Ilja will say, but we tried different partners, coaching, basically everything and it just didn't improve. The others and particularly the junior developers thrived in it.

My two cents.

That correlates well with what I've seen. I also think that people just have different capacities, and different tolerance, for verbal interaction. It breaks somewhat along temperament lines (introverts do seem to have more trouble with it), but not strictly so. As I said before, I just feel like I'm thinking in a completely different way when I'm coding than I am when conversing with someone. Shifting back and forth between the two keeps me perpetually off-balance.

it doesn't sound like there was a lot of effort to try to work on your problems...

It's actually been an issue for several months. As a new programmer, I'd mostly assumed my level of discomfort was due to inexperience. As I've learned more and become more confident in my skills, I've seen something different at play. The pairing has become the single biggest impediment to my effectiveness at work.

As far as efforts to work on my problems, there really hasn't been much. They've been patient with me, I suppose, but they've also been very clear that 'pairing is what we do here'. Most of my effort was directed at trying to get better at pairing. In the last few weeks, as that began to seem more and more futile, I started trying to persuade our team, and by extension the company, to be a little more flexible in our application of 'agile'. They seem to have had much less patience with that approach.

That's strange, because when pair programming, you should constantly be communicating with each other, anyway.

I understand that. But for me, unfortunately, that equates to constant distraction.

I assume you didn't have a coach that helped you with the adoption of pair programming?

Did the team already do pair programming when you joined?

We do have a coach, but his job seems to be more about laying down the law on what our practices will be, rather than helping us implement them. The company had recently done a full scale conversion to XP shortly before I got there, and I get the impression that they feel that if they give in at all to those resisting the change, it will all come unraveled.

I can even understand to a point. In XP, pairing is the glue that holds the whole process together. Without code reviews (something that sounds like a great idea to me, btw), pairing is the only way team knowledge and quality control really happen in XP. But I've never seen it function particularly well in that regard. Even amongst those who can tolerate, or even enjoy, pairing, the results are random and spotty. Our code is full of half-baked attempts to apply various design patterns or refactorings, only to be abandoned by the next pair to touch the code (we swap pairs - and tasks - often, which ensures maximum vertigo for me) who either didn't understand what the previous pair was up to or decided things should go in a different direction.

I think the trick you need to learn for pair programming is "thinking out loud".

That does seem to be the key. Even harder, for me, is "listening while thinking". I can do this in most situations, I enjoy conversation and I'm pretty good at it. I'm not one of these techie-nerds with no social skills. But I do prefer to have only one voice in my head when I'm programming.

That's interesting. Every single developer I know is more creative when working in a pair - simply because of the stimulation by thoughts from a second brain. Being relaxed is a prerequisite, of course, and that might take some work to accomplish.

Well I guess I can be your first counter-example. Most of the developers I know (and nearly all of them are from the agile shops I've worked in, where pairing is the norm), tell me that they do their best coding alone. In theory, I can see how pairing offers benefits to creativity and productivity, and benefits to team knowledge, etc.. - but my experience has been that the practice is so fragile, and so dependent on highly disciplined techniques, that it makes a poor choice for routine practice. I'd certainly not want it to be the norm if was signing the paychecks.

Thanks for the comments, btw. Hopefully you can understand how I might be coming at this topic from a particularly negative place right now, but I'm trying to keep my observations as honest and unbiased as possible.
[ October 12, 2007: Message edited by: Damon Black ]

Originally posted by Ilja Preuss:
Damon, this is an interesting report. I'm curious - please allow me to inquire a little bit...

No problem. I should have plenty of time since I was 'let go' today for my inability to bend my 'people' to their 'process'.

What do you think is it about pair programming that holds you from "thinking in code"?

I think I'm in a different place in my brain when I'm programming. And it's nowhere near the place where I deal with interpersonal communication. Each time my partner says something, sighs a little loud, or even fidgets in their chair, my attention is diverted away from the kind of thinking I need to do when programming.

One more question: when you pair program, how much of the time do you find yourself being the driver (the one typing at the keyboard)?

Not much. I know it's what needs to happen for engaged pairing - and I've really tried to do it. But as tedious and frustrating as it is to watch someone else program, it's even worse trying to program and not being able to maintain a consistent train of thought. When your pair partners all seem to prefer it that way, it's just much easier.

Can you say what lets you get distracted easier when pair programming?

It's not that I'm more easily distracted, the problem is that there's much more distraction. I'm actually probably a little more easily distracted programming by myself, my thinking tends to be more relaxed and creative. But I deliberately work (when given the choice) in an environment where I can remain free of unwelcome distractions. The problem with pairing is that the distractions are so much more frequent and intrusive.

It's natural that there is kind of a buzz in the team room...

I liked your idea about the bells and passed it along to our team, before I got fired that is.

The 'not-noise' is the real distraction of the bullpen stuff. It's tough NOT to listen to another human voice, especially if the voice might have important information for you. Someone might be just be clearing their throat, or making a joke, but you have to listen for a second to discern that, and as I've said, that's a jarring shift in perspectives for me.
[ October 11, 2007: Message edited by: Damon Black ]