There is an easy way how to save many man-days and thus also money on a project by adding some work to the key team members. You must be thinking that I’m crazy if I want to add even more work to the already overloaded senior developers and an architect but I’m sure you will agree at the end. The additional work, which will later save you many, many more, are code reviews and pair programming of an inexperienced and a senior
Read more at :
You are crazy!!!
Pair programming is not intended as a training exercise for junior developers and if you use it for this you will not save money in the long run.
No company is going to be happy about a junior developer sitting and watching a senior developer bang out code, or be told verbatim what to type. Juniors will NOT learn this way.
One-on-one training courses have their merits, just not on projects.
The point of pair programming is to have developers of similar skill levels working together on a problem where both of them are qualified to make design and coding decisions and are able to spot possible issues that may not have been immediately obvious the one driving at the time.
The autor just says that pair programming (senior + junior developer) can be used to teach newcomers. He doesn't dispute the pair programming as it is defined in agile methodologies (two developers of the same level).
In my opinion there is nothing wrong with senior developer spending some time with a junior developer at the beginning of his work.
You are both partially correct in that pairing is helpful for both mentorship of junior team members and for providing continuous design review, and I would encourage you to read Alistair Cockburn's and Laurie Williams' article "The Costs and Benefits of Pair Programming", available <a href="http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Bjsessionid%3D6B3A8C3F98FD0CF4C3B5F6AFB0087D35%3Fdoi%3D10.1.1.26.9064%26rep%3Drep1%26type%3Dpdf&ei=9Np4TeSiMMLXrAGF7uHCBQ&usg=AFQjCNFaToOyox8mViKgUxkyOPSZrY0-Pg&sig2=WjnjSo5Dr7pSaCeKdWxBjw" alt="link_to_article">here</a>. Effective pairing provides many benefits, including defect reduction, increased satisfaction, improved design, continuous review, better problem solving, improved team building and communication and reduction of staff-lost risk.
- Also, utilized as very good knowlege transfer technique.
- Pairing with inexperienced developer is extremely painfull to deal with and some annoying (depending on the person you pair).
- Pairing through-out the day is very exhausting.
Guys, I am not saying pair-programming is all that bad. People in the name of "pair-programming" utilize this for the selfish purpose. This is out of my experience whether or not someone agrees.
My suggestion about the pair-programming is Do Pair when you need to pair. Dont pair just because you have to follow the "process".
Do Pair when you need to pair. Dont pair just because you have to follow the "process".
I agree with Shawn.
<!-- end of col1 -->
I agree with the author. I would take tow hours a day to make pair programming with junior developers. Many times you let them work by their ouwn and months later you discover what they've been doing and you want to cry !
Bye, Marcos.
Thank you for the interesting blog post. I find the idea of blending Agile methodologies into inital training of developers quite refreshing. I do agree with the previous comments, that pair programming shouldn't take place just because it's defined as a process. But that's the whole point of Agile: from personal experience with Agile and scrum, I can say that the whole idea of Agile ivolves ongoing observation and reobservation of your work process (as a single employee and as a whole team), so it's not a bad idea to implement this attitude to a newbie. It might not be that bad for a senior developer to have to explain her way of working, coding, and thinking either -- she might not love to admit it, but even an experienced developer should take a look at her own work habits once in a while.
As far as I am concerned, Agile is just another term for spastic or incompetent. I worked recently with a manager who legitimized his inability to concentrate on one subject as being agile. Spastic was more like it
