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:
- Ask for peer review (pairing after the fact).
- CardboardProgrammer/RubberDucking (summary: enunciate your problems, preferably out loud. A real person is not always required.)
- Constantly switch between zoomed-in and zoomed-out viewing of the effects of the changes you make.Pair programmers can split this task cleaner, where one is focused on the solving the immediate problem at hand, while the other is focused on how it fits into the bigger picture. You'll have to juggle.
- SandglassProgramming (summary: force yourself into small cycles. Use a sandglass or timer to build the habit. The page mentions both test/code cycles, and pair switching.)
- Sleep on it and look at it later. You'll almost surely spot improvements you missed the first time around.
- ChangeBrainstorm (summary: now and then, look at your code and try to imagine how it would respond to significant change, such as internationalizating everything.)
- High-level documentation.
To improve focus:
- Take breaks often, even if just to read email or chat. Check in with all tests running before each break.
- Alternatively, take breaks never. I am currently doing SoloXp?, and I've found that I can easily get distracted compared to when I am pairing. I'm prone to indulging myself: Rather than facing a grotty problem I'll "take a break". After I'm done, I'll return, see the grottiness, and "take another break". Before I know it, my velocity's shot.
- LeaveaTestBroken (summary: when you stop, stop in the middle of some task, so that it's easier for you to get up to speed when you resume.)
To get collaboration:
- AllEngineersInOneRoom. Everyone shouts out questions as they have them, and the answers come just as quickly. The bullpen-style environment alone can give you many of the benefits of pairing.
- Get people to pair with you every chance you get. Good occasions to pair are for specific needs ("I can't find this bug", "I can't see how to simplify this solution").
- Code review with colleagues at least twice a week. Chalk talk alternative architecture at least once a week. Join a company brown bag lunch group and a local technology interest group.
- InstantCodeReview -- StephenHutchinson
To increase CollectiveCodeOwnership:
- WatchAllCodeChanges by the rest of the team. Ask why things are the way they are without implying that they should be otherwise.
- SwitchImplementors (Summary: If you're writing a piece of functionality, and so is your coworker, get about half way done. Now, you finish his code and he'll finish yours. Give feedback as you go)
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:
- asking why things are the way they are can be disruptive. You can't ask somebody else who is responsible for the implementation of an interface why he implemented the way he did.
- take breaks often is OK only if you are extremely talented and can get the tasks accomplished in time. Still what's that got to do with XP/PairProgramming/SoloProgramming? Not to mention that if you have that much time you can do better by checking in your code sooner, and eventually get some more responsibilities if possible or pay more attention to quality of you code.
- getting people to pair is also disruptive. It is the project manager who takes this decision. He is responsible for how project is organized, who works on what feature, for how much time and so on. If he's an XP-er he'll choose PairProgramming. If not, get over it, buddy. You're not second-guessing him.
- Chalk talk alternative architecture at least once a week. Wow, that would be cool. But I hope you won't try to refactor the whole architecture once a week. Yes, some people can get the things right the first time, or almost right so they need only minor adjustment. Get over it. My favorite quote on this: There's never enough time to get the things right the first time, but there's always enough time to go back and do it the second time.
I'm unconvinced by the arguments above.
- 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.
- The point about taking breaks often is that it (allegedly) increases the amount you produce. Not to mention making you less liable to RepetitiveStrainInjury.
- 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.
- 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
- There are plural people
- There are specific goals
- When the people undo each others work, the goals are harder to reach
- People who make the goals harder to reach can't expect to stay on the team very long.
Soccer team != Programming team
- Soccer has one ball. Programming has many simultaneously controllable elements. In soccer, the team needs to decide whether they're going to move the ball by quick dribbles or kick & run. Programming gives you more freedom in this way, because, for example, you can have some people pairing, and others soloing.
- Soccer has one goal per team. Programming has many.
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:
- I've found that being a smoker helps my programming dramatically. No better way to take regular short breaks to get a breath of fresh air (albeit mixed with smoke) and to think about a problem away from the computer. Not only that, but you get a nervous system stimulant out of the deal. I gather the side effects to my health are something of a problem, however. =)
- On a more practical note, one suggested development practice for team-oriented XP is to work two days, goof off on Wednesday, work two more days, then totally leave behind work for the weekend. (Anybody remember the wikiword for the page that suggests this? I know I read it somewhere...) As a contractor, that doesn't work out so well for me when there's always 'something needed for Monday' - typically I work Sunday-Tuesday, goof off Wednesday, work Thursday, and do personal stuff Friday-Saturday, but the concept is the same.
--
JosephRiesen
See SoloXpProjects
Solo Programming Xp Workarounds