|
I'd certainly consider trying coed naked pair programming...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
You're naked with a hot woman, and you want to do... programming? 
Oh, well, at least you didn't say you want to go debugging. 
Cheers,
Vikram.
If the radiance of a thousand suns
Were to burst at once into the sky
That would be like the splendor of the Mighty one—
I am become Death,
The shatterer of Worlds.
|
|
|
|
|
i'd LOVE to debug a bit, but first you need to refactor.
|
|
|
|
|
Maaate - that's not an image I want hanging around.
Cheers,
Vikram.
If the radiance of a thousand suns
Were to burst at once into the sky
That would be like the splendor of the Mighty one—
I am become Death,
The shatterer of Worlds.
|
|
|
|
|
Vikram A Punathambekar wrote: Oh, well, at least you didn't say you want to go debugging.
he he he!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
"If it were machines, the pair_programming seem to work, but for humans it is pair_crackdown that seems to work! " - Nisamudheen
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
at least one other person knows what the **** you are doing... after that, you are on your own.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
My pair would be Sarah...
And of course I would have to be the observer and not the programmer...
|
|
|
|
|
Well, Joan, why don't you post pictures of Sarah, and we'll decide? 
Cheers,
Vikram.
If the radiance of a thousand suns
Were to burst at once into the sky
That would be like the splendor of the Mighty one—
I am become Death,
The shatterer of Worlds.
|
|
|
|
|
I used it for critical components in critical project times, I beleive it's very useful in these cases.
|
|
|
|
|
hspc wrote: I used it for critical components in critical project times, I beleive it's very useful in these cases.
I used to code by pair programming but i used to be mentor and have 3 student who review my code ...! 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
|
right you say!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
As said before, this is ideal for teaching, not in real productivity environments.
At least I've never developed anything thapair programming could really add something to the scene.
I prefer:
- Contract good programmers
- Write a good the project specifications
- Write a good Framework as a base for the project
- Keep in touch with the team (or make part of it) permanently. Weekly meetings is just not enough.
Based on this 4 rules everyone knows how to do things and where to point at as the finish line. No need for a police man at your back.
|
|
|
|
|
in the end programmer is human.. and humans are prone of errors.. so it better some one reviewing your code side by side, and it might help person code much better and efficiently .. and might help you save minor error which arise in testing. as it will save on overall development cost!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You/codeProject$$>
|
|
|
|
|
I don't think so...
You won't remove testing from your development cycle just because you're using Pair Programming are you?
So this will be a double check...
Another aspect is that the Tester may not be a programmer... or at least not an experienced one... it's a tester. Someone with testing skills and methodologies.
This tester will have a better abstraction from the development routine that developers gain that the developers themselves.
So, if you have 2 developers put them to work together but on different tasks.
If one needs a 2nd opinion on something asks the other.
When it comes to testing let it to the testers, they will always find ways to blow your code on the 1st round... even if you're implementing a ultra density "quadruple programming" 
Cheers
|
|
|
|
|
AlexCode wrote: I don't think so...
You won't remove testing from your development cycle just because you're using Pair Programming are you?
you can't , testing is essential part of SDLC, but you could reduce testing time!, by removing minor bug at development stage only!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
"If it were machines, the pair_programming seem to work, but for humans it is pair_crackdown that seems to work! " - Nisamudheen
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Imagine a 2 day task... a Windows Forms manage form, read, write, edit, list report, whatever...
Pair programming is being used...
How many errors do you do in a 2 day task?
How many of them are undetectable by the coder?
I may say from my experience that undetectable errors are not detectable during code writing but during the test phase. You need to test other ways to do the same thing, click the button instead of striking Enter on that damn textbox...
2 developers won't test these scenarios and their level of knowledge on the subject is similar because both read from the same project specifications...
You never get a good test from who actually wrote the code...
Another thing:
Development time is way more expensive than testing time.
Even because usually testers are cheaper than coders, but even if more expensive, testers are allocated to a project fewer time compared to developers. So they represent a lower cost to the project.
If this time is cheaper you have to use this resource as much as possible to decrease development costs.
Releasing the coders from the testing will enable you to put assign them another task while the tester(s) are trying to blow the thing up. The code may return with 10 bugs one or 2 days after but you have one or two tasks completed by those coder in the meantime.
Cheers,
Alex
|
|
|
|
|
The idea is that the second developer might see something that first one didn't because he/she is too busy typing away.
Resulting in less bugs for your tester to find. Less bugs to fix for your developers. And the way I see it...there is a big chance that the bug that your 2nd developer will see would be something silly to begin with. Something that shouldn't be there anyways. In this case the pair programming would save time for everyone.
I also believe that pair programming is like everything else in life: "Best taken in small doses.". A few hours per week in strategic code sections or for learning better practices and experience, but no more than that.
Dewm Solo - Managed C++ Developer
|
|
|
|
|
I don't know...
To this technique have any success coders must be very similar.
One can't read the code faster that the other, or architecture techniques can't be too different, otherwise they'll spend too much time arguing with each other instead of being writing code.
Some times they'll have to explain ideas so both get the same snapshot of the problem... way to much time wasted...
Like I said before, I prefer a good hand of developers sitting on the same room doing their own work and available to contribute with ideas on each other problems than having pairs of them coding the same thing.
If the problem is too deep then the team must do a brainstorm, throwing ideas to the table and discussing them. When a solution is found there's no need to have a policeman on your back to say that your 'if' clause is not right.
Cheers,
Alex
|
|
|
|
|
True enough!
I really don't know. The whole productivity thing is pretty much dependant on the point of view of who debates on it at a particular moment. Other than having good programming practices there doesn't seem to be much that is mostly agreed upon by the community of developers.
The only thing that I think is really neat from pair programming is that it is a nice opportunity to learn from somebody else's experiences. Making you a better developer in the process. It little waste of time on the part of one of the two developers that can result in some nice time savings in the future.
Dewm Solo - Managed C++ Developer
|
|
|
|
|
...I said 'No' 
|
|
|
|
|
When there was a very good looking woman in the class to work with.
John
|
|
|
|
|
John M. Drescher wrote: When there was a very good looking woman in the class to work with.
No... you don't sound desperate at all! 
|
|
|
|
|
I was desperate then (back in the late 80s when I was a computer nerd).
John
|
|
|
|
|
John M. Drescher wrote: When there was a very good looking woman in the class to work with.
we didn't have programming classes to pair up with. I did end up teaching at the university unofficially my senior year in school because programming was too hard, but there still wasn't pair programming. Now dissection, the ladies generally grabbed someone who would do all the dirty work.
for some strange reason, 4 years lettering in Math/Computers at science fair, two years in mock trials, etc. may fill up a lettermans jacket, but it just doesn't attract ladies the same as football. 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
