Collaborative development, pair programming, etc.
There have been some interesting discussion on our internal “agile” alias around pair programming, with some advocates and some skeptics.
I wrote something in response to one of the skeptical posters, who (to paraphrase badly and perhaps miss his point) said that he was an introvert and preferred to work alone. Not that I’m advocating forcing something like pair programming on anybody.
Here’s what I wrote, slightly edited to protect the innocent.
*****
The introvert/extrovert concern is an interesting one. I like to be left alone at times, and I’m also a big fan of flow state.
But I’m also pushing for us to *experiment with* pair programming in our next cycle. Why?
Well, I’ve been on a lot of projects in my career, and I see the same bad things happening over and over again. Code reviews that don’t happen. Important components that one or fewer people on the team understand. Overly grandiose architectures. Re-inventing the wheel. Solutions looking for problems. Bad bugs that are really expensive.
Who is at fault? Well, we are.
For example:
You’ve just finished adding a new feature, and to do so you had to do a bit of re-architecting to fit it in. Do you ask one of your co-workers to review what you’ve done before you check it in?
Reasons you get the review
-
It’s the right thing to do
Reasons you skip the review
-
You’re an introvert. Given the choice between personal interaction and working on something new, you usually choose something new.
-
Your co-worker is also an introvert.
- Nobody really understands your code because you’re the only one who works on it, so the review may not give useful feedback
-
You have to get up, leave your office, find the person, and bring them back. Lots of time, and they may not be there.
-
You get evaluated on the features you produce and don’t feel review pain because of the bugs in your code.
-
It’s early/late, and you’re by yourself
-
You don’t want people to say bad things about your code.
There are a lot of factors pushing you to do the wrong thing, so it’s not surprising that the right thing rarely happens.
So what about TDD? Well, I think TDD is a great way to get code that has fewer bugs in it, and I don’t underestimate the value in that. But TDD doesn’t address code maintainability issues – you can still write overly grandiose and poorly factored code using TDD. You can still write code that is inconsistent with code elsewhere in the project, or using the wrong library. You can still spend hours trying to figure out something where the group knowledge could have solved it in 5 minutes. And – as I am chagrined to admit – I can still write code that should be under TDD but isn’t because it wasn’t convenient.
I don’t think that collaborative development – by which I mean anything from co-location in a big room to pairing – is a silver bullet that is going to solve all these. But I think that it can make a pretty big dent. And as a company, I think we have to figure out a way to stop producing big legacy codebases that nobody wants to work on.
Recent Comments