Web Development

Ask something
Discussion Locked

Paired Programming in a Small Shop

0 helpful
5 replies

by orangestripe

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
I have been the stand-alone programmer in our MIS department for a few years now. We are finally able to hire another programmer and I am really looking forward to having a collaborator. I am wondering if it seems reasonable in a shop this small to try paired programming. I have done paired programming on some side work and think it can be an effective way to get good applications. I think it might work pretty well at work, plus it provides a way to insure that both of us will have some background in the custom applications we develop in-house. Does anyone out there have an opinion on this? Have you tried it in very small shops? I know we need to hire someone open to paired programming, but after that, do you think it could work?

5 replies

by ledelste

I think you have a good idea there. I am just about to try pair programming with someone for the first time myself.

Really, it's sort of obvious - you know some stuff, the other person knows some stuff - you should sit down at a computer and collaborate. In your situation it sounds like a particularly good idea. In a small company, multiplying the skills is so important.

I would make sure that your prospective partner is cool with the idea, and that you yourself are ready to work with someone that way. I figure that the success of the venture probably depends heavily on you giving the newer person enough consideration during your sessions, not being overbearing, giving them some "space", etc. If you are a naturally good people person, if you are patient, if you are interested at least as much in hearing what someone else thinks as you are in telling them what you think, then you should be well-poised to work with this new person and kick some butt.

by padster.reynolds

It works extremely well in the following circumstances:
You get on well as mates.
Honesty .. if don't know, say.
Full code share (sounds obvious but sometimes people don't like to pass on those secret code gems easily).
Mutually supporting expertise (ie: two java good dev's, one's a whizz with JSP, the other a dude with trigger's and sprocs .. two identikit guys end up fighting over minutea).

I've had experience of reducing problematic programming from weeks into days.

Old agade "Two's company .. three's a crowd' rings true.

by gigel032004

I tried it once, but my "pair" turned out to be an idiot without even the basic knowldge about programming, so the experience has rapidly evolved in a time consuming, irritating, teacher pupil relationship. I consumed about tree times more developing in two than developing the same thing by myself.
About "multiplying the skills", it works only for the badly prepared persons. Go to school and forget about pair programming.

by blaine moore

I have had better experience keeping a common source control database, and every time there is an update having each person test the changes. Then we are not tied down to working on the same area of the application at the same time, and can each work at our own pace.

Need help or somebody to kick the creativity into gear? Set your cubicle up next to them and babble back and forth as necessary.

by outsourced

I agree about source code control. With a team of two, you're already as agile as you're gonna get. I think XP is best suited to "Wolf Pack" projects. That is where the company focus is on a few projects, and their best people are brought together to get the job done quickly. Corporate IT and day-to-day production stuff is best done with "specialists" or experts (well partitioned responsibilities). With a team of two, 100% redundancy (a goal of XP) is not efficient. The XP process prescribes a team size of 5-7. Certainly though if you fill like helping a colleague out, or wish to have assistance periodically, that is sometimes very effective in conquering new challenges.

This discussion is closed to new replies.