|
|
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)
|
|
|
|
|
Wouldn't this also be annoying if the 2nd guy was a total n00b like most in the industry? I mean, last thing I'd want is someone nagging me every 10 seconds about what is XYZ for. Or, even if they had a clue, with constant second-guessing I don't see how this is will increase productivity. Well maybe if person A really writes crap code a lot and can't debug for the life of him/her. Maybe more companies should implement the "find a competent coder methodology."
|
|
|
|
|
Jeremy Falcon wrote: Wouldn't this also be annoying if the 2nd guy was a total n00b like most in the industry?
If you do this in a short session it is a great way to transfer knowledge. The idea is the least qualified implements, so the "n00b" sits at the keyboard and you, as the expert, guide them. Because they are actually doing the work and pressing the buttons they pick up the information faster than if you just sat in a meeting room and explained it for the same length of time.
At least that's how I see it working well - as a teaching/learning tool.
Jeremy Falcon wrote: Or, even if they had a clue, with constant second-guessing I don't see how this is will increase productivity
If you are both equal then I don't see it working very well. There has to be some tutor/student relationship going on with the student at the keyboard. If you are both equal in terms of overall competance, then maybe you are unequal in terms of domain knowledge.
But, like I said, this is how I see it working well because it was scenarios like that where it has worked well for me.
|
|
|
|
|
Colin Angus Mackay wrote: There has to be some tutor/student relationship going on with the student at the keyboard. If you are both equal in terms of overall competance, then maybe you are unequal in terms of domain knowledge.
Even if they are "equal" it still does not mean they can not learn from each other. IMHO, the learning aspect of the pair programming diminishes if there are always the same people working in the same pairs - it is important to "shuffle" the players once in a while
|
|
|
|
|
Nemanja Trifunovic wrote: the learning aspect of the pair programming diminishes if there are always the same people working in the same pairs - it is important to "shuffle" the players once in a while
That's also true.
|
|
|
|
|
I and my teammate (who is my equal or maybe I'm his) commonly do this. We have too much work to do it all the time, but if one of us hits a particular problem, the other set of eyes comes in handy. Additionally, some of the tasks really can use two sets of expertise looking at them because no two people have the exact same skills. We tend to have the person whose task it is doing the work while the other looks over and provides suggestions. Once in a while, a suggestion isn't relayable, so we'll switch roles and the guy with the idea enters it in, explaining as he goes and tweaking what the other person notices along the way.
I've done this in two different situations now and both were very successful. the key is, we don't let egos get in the way. If both developers respect their counterpart and make it clear to the higher ups (in both cases, that was the company owner) that it was most definitely a team effort, it can be very successful.
I have tried this with others who wanted to either take all the credit or didn't bring any significant skills/perspectives to the table. Some success can be had with the mismatched skill sets in the teaching arena, but it actually slows down the development efforts that could have been accomplished by the senior person alone, and the egotists who want all the credit just can't be worked with as they want you to do the work yet them to get the credit.
In short (too late), equally skilled can be very successful if they are friends (or at least respect each other) first.
|
|
|
|
|
Draugnar wrote: but if one of us hits a particular problem, the other set of eyes comes in handy.
I've done that a few times myself, and it went ok. For me, I was under the impression "pair programming" was a constant thing rather the "at-times" thing to do. 40 hours a week of someone right there over my shoulder would be torture. 
|
|
|
|
|
Colin Angus Mackay wrote: as a teaching/learning tool.
In case it may be a very good idea. I was thinking along the lines of day-to-day activity.
|
|
|
|
|
No, it's not a problem unless your n00b partner doesn't know they suck and tries to lead the coding down a path you know to be wrong, without heeding your criticisms.
Back when I worked in a company in 2006 which (at the time) did TDD and almost exclusively pair-programmed, one of the other guys was a complete n00b with Java, not to mention J2EE, servlets and the frameworks we were using. It was okay because most of us were interns and decent coders to boot. Whenever I was paired with him, I encouraged him to pipe up and ask whenever he was confused, which he soon learned to do. After a few weeks, he was doing pretty well.
Apart from that, when working with the more experienced coders, it was always helpful as when one of us was tired/hungover or just not firing on all cylinders, as your partner would drag you onto your feet and catch some of your mistakes and poor design decisions. And vice versa. Also, knowledge transfer was quite effective, especially when we ventured into unknown territory.
|
|
|
|
|
I'm forced to implement this relationship on a moderately regular basis, but that is because most of the people I work with are 45+ year old engineers who are trying to do something painful like perform a sophisticated analysis with excel using macros out the ying yang. They come to me and I stand over their shoulder for hours at a time until finally I snap and take over the keyboard because they were typing at about 1/5th the speed I type when I'm simultaneously sick and have sliced up fingers that hurt to type with. After that, theirs eyes just glaze over as I end up rewriting all of their code and at the same time muttering that they should have just used a real language.
|
|
|
|
|
. . . if she were very cute, unattached, and frisky.
I would, of course, need to observe her, at first.
After the initial period we would, of course, alternate as to who was supporting who.
They should have thought of this years ago.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
