Solo Programming Xp Workarounds

Let's say that you're the type that enjoys PairProgramming, and perceive its benefits. What do you do to make up for the disadvantages of SoloProgramming when you have no choice?

To improve the quality of your code:

To improve focus: To get collaboration: To increase CollectiveCodeOwnership: To decrease loneliness:


I should add: make sure your project manager doesn't read this very page and realizes you're employing these strategies.

Joking aside, I don't know if some of the above can be qualified as good advice.

Let's say you're a soccer player and you like your style (let's say you're Brazilian and you like to do a lot of dribbling) and then you transferred to England where you are supposed to kick the ball and run (well, kind of, but in essence opposed to Brazilian style). So is playing Brazilian style no-matter what team you are in a good thing to do? Is it a professional thing to do? Maybe. If your coach tells you to do your game you can do just that, but if your coach requires you to fit into the English style, you also have to do just that. If everybody in the team acts as he sees fit you're not going to do performance, you can play in the amateur league. If you can't absolutely play the English style, you're better off finding a transfer to Italy or Spain. And that's only a matter of principles.

If we go into details we see:


I'm unconvinced by the arguments above.

  1. Why on earth can't you ask someone who's responsible for the implementation of an interface why he implemented it that way? I can't think who else you'd ask. If you work somewhere where such questions are viewed as dangerous, it's time to move.
  2. The point about taking breaks often is that it (allegedly) increases the amount you produce. Not to mention making you less liable to RepetitiveStrainInjury.
  3. If you have a bug and are having big trouble finding it, asking someone else to help you is pretty much guaranteed to be more efficient than doing it yourself. Unless everyone around you is so overloaded that they can't spare ten minutes to give you a hand (in which case, again, it's time to move) any half-sane project manager will be glad you did it.
  4. I don't think the original author was proposing anything like refactoring the whole architecture once a week. Full-blown XP groups don't refactor the whole architecture once a week.

1) Is not your damn business. You're wasting the other guy's time. If the methodology at hand has peer reviews you let that guy's peer to inspect his code. But just going around and willy nilly asking why the circle is round is counterproductive. Let's say you're on doing the JavaScript and fancy HTML layout and that's your job in the specific project with some specific methodology other than XP. If you're going to come to the DBA and aks him all kinds of things you hardly have a clue about, the most judicious response he could give you is to go and do your studies first.

Straw man. We aren't talking about someone who knows nothing about a major area of computing bothering someone else who's expert in it with meaningless questions. And we certainly aren't talking about "just going around and willy nilly asking why the circle is round".

2) The point about taking breaks often (how often?) is controversial. Each developer should have at least enough brains to know what works best for him. Some people can easily stay fully concentrated in full intellectual capacity for 8 hours and more. But it has nothing to do with Solo vs Pair, XP vs whatever methodology.

One of the principles of XP is shorter working hours than are common in the software industry. So this does have something to do with XP.

3) If you have a bug and are not able to repair it yourself, you are incompetent. So you call in another guy to help you find a bug. How are you going to know it's going to last ten minutes? Let's not forget that the specific statement was to get somebody else to pair.

Straw man. Who said "not able"? It's often easier to repair a bug with help. Sometimes much more than a factor of 2 easier. If you don't do this when it's appropriate then you are shortchanging your employer. It's true that you can't know it will only take 10 minutes. I don't know what point your last sentence is making. To "pair" is simply to work in a pair; it doesn't need to imply working for a long time, or anything like that.

[There's also the classic situation where you can stare at a bug for hours without figuring it out, and someone with a fresher perspective can spot it in minutes. I would suggest that it is the person who doesn't realize that they are stuck and/or doesn't ask for help who would be incompetent.]

4) Good, so you are rediscussing the architecture very week. For some projects and some architectures and some architects it might be useful, for other situations it might be just a waste of time.

No one ever claimed that everything on this page is a good idea in all situations.

Who says you need to discuss the whole architecture? Make it a theme meeting, and discuss an aspect of the architecture that is recognised as having a problem. This makes the discussions relevant, and ideas for improvement can be taken onboard. I've never worked on a project where there wasn't something that had a problem. -- rw

But the main point you failed to address is that one should always play by the team rules. If the team is supposed to work with all 1,2,3,4 , then, by all means, go ahead and do it. But if not, not.

The people I work with are not in any sense doing XP, but they do not forbid any of the things described above. Plenty is left to the discretion of individual workers. If it weren't like that, I would leave.


Let's say you're a soccer player and...

But we're not discussing soccer. We're discussing programming. One of the underlying motivations for XP (as I see it anyway) is that programming is unlike other disciplines, and therefore requires a different set of guidelines and practices. -- MikeSmith

And programming, even by XP, is usually a team play (with the possible exception when I'm hacking on my own for fun). The premises of this page is that you are in a team that doesn't do XP. If you're going to do XP on your own, against the practices (style/methodology whatever) of the team, either they make you play with the team, or they have to let you go. If you're stubborn enough to think XP is the one and only true magnific way and can be practised no matter what the whole team is doing, well, go ahead , but don't be surprised when you are thrown out the door.

According to the conclusion at the bottom of the ArgumentByAnalogy page, where does the analogy work? Where does it fail? When it fails, why does it?

Soccer team == Programming team

Soccer team != Programming team Following most (all?) of the tips on this page don't involve undoing anyone else's work, or fighting against the team in any way. Am I wrong?

For example, how is WatchAllCodeChanges somehow born of the idea that "XP is the one and only true magnific way and can be practised no matter what the whole team is doing"?


Amusingly enough, for me, I've never really magically solved a problem overnight. More specifically, I've never woken up with a great epiphany as to how to solve a problem (though when I'm lying down trying to sleep, pondering over a problem, I occasionally come up with a solution that sends me racing to the computer). Some time ago, I was working on a project I had badly mis-estimated, getting about three hours of sleep a night (heh, so much for SustainablePace), and one evening as I slept I had a vivid dream of glowing code, a dozen solutions to that one unsolvable problem that was tormeting me. When I woke up to my alarm, I rushed to the computer to get all my ideas down - and suddenly realized that the problem I had solved in my sleep, well, wasn't a problem. That is to say, my mind had constructed an imaginary problem and solved it with amazing, subconscious skill.

I guess that when I sleep, my subconscious doesn't solve problems. It exercises.

Additionally:

-- JosephRiesen


See SoloXpProjects


EditText of this page (last edited February 10, 2005) or FindPage with title or text search