Code Reviews vs. Pair Programming (mavenhive.in) 186
An anonymous reader writes: I've spent nine years working in teams which religiously follow pair programming. I'm used to working that way and appreciate the benefits it brings. We didn't have the luxury of pair programming all the time in my last project. This required us to do code reviews to ensure the quality of the code we delivered. This post is an attempt to consolidate the upsides and downsides of doing code reviews instead of pair programming in my three months of experience.
Nine years of pair programming? (Score:4, Insightful)
Re:Nine years of pair programming? (Score:5, Interesting)
(Going anonymous)
You are likely running this through a cultural filter.
The Indian teams that I have worked with are a lot more about huddling around a computer working things out, than the typical US approach of developer with headphones collaborating a couple of times a day. Different cultures do things differently.
Looking at *real* salary information between two geos (Bangalore and Silicon Valley) comes out roughly as follows.
Architect level 2:1.
Junior level 5:1
You can have pair programming for junior staff and still have a very strong cost advantage in India. That cost advantage plus a cultural tendency would make pair programming fairly easy to apply.
Not making any comment about the quality of code or quality of engineers on either side of the pacific...
Re: (Score:3)
Re: (Score:2)
Does having 5 people huddled around a computer increase productivity or increase slippage?
Re:Nine years of pair programming? (Score:5, Funny)
Re:Nine years of pair programming? (Score:5, Interesting)
If you have a few individuals who are new to an organization or becoming acclimated to a new project they've not worked on previously, pairing can make some sense. On the other hand if you've got a rock-star developer that's head-and-shoulders above the rest, it's probably not worthwhile to pair them with another person.
Re:Nine years of pair programming? (Score:5, Interesting)
This is nothing new.
The effort of every individual in a group of people has been measured by Ringelmann in 1914, for army's purposes.
Here is the original article: http://gallica.bnf.fr/ark:/121... [gallica.bnf.fr]
And the results are (number of people => measured effort)
1 => 100%
2 => 93%
3 => 85%
4 => 77%
5 => 70%
6 => 63%
7 => 56%
8 => 49%
This is called "Ringelmann effect" or more recently "social loafing".
As you can see, 8 people produce the same amount of effort than 4 individuals.
Re: (Score:3)
Re: (Score:2)
Actually I have learned quite a bit about efficiently running IDEs, debuggers and troubleshooting techniques from pair programming.
The amount of time devoted to efficiently learn *those things* should be very minimal compared to the total activity time.
Coding, not so much- I can pick that up just looking at someone else's code.
Or by doing, or reading, or applying general principles. Coding is such a basal thing. A good student right out of school should already know how to code well. What we get with work experience is the knowledge needed to work in projects, in organizations, in seeing troubleshooting patterns, in foreseeing issues, etc.
Re: (Score:2)
Re:Nine years of pair programming? (Score:4, Insightful)
If you've got a "RockStar" - odds are that noone else can follow his work, so there's benefit in pairing there to get extended life and maintainability out of his productivity, enabling others to better maintain his(/her) code and freeing up your superstar to continue breaking new ground instead of getting bogged down in maintenance of the old stuff.
If your "RockStar" does produce code that is readable and maintainable by mere mortals, then you definitely want to pair them up with the plebes so they learn how to do that, because most programmers can't.
If spending 4 to 8 hours a week "paired up" with colleagues is too much for your precious flower to handle, watch out for exploding egos and horrible personality clashes.
Re: (Score:2)
Code review before the "RockStar" can merge his code in, should give the same result. Your new feature is not done until someone else can use it & maintain it. Otherwise the business is screwed if you get hit by a bus.
Starting a policy of reviewing all code may seem like a waste of time. But as a team works together more, code reviews should get faster.
To cover some of TFA's "Downsides";
Working on stories which have dependencies is hard
Yes. If you find you need to reuse some common code between two feature branches, first refactor & rebase that c
Re:Nine years of pair programming? (Score:4, Interesting)
You're maybe a better coder than I or people I've worked with. I find the majority of my time isn't spent "writing" it is spent finding the stupid little errors like a != that should be an == or forgetting to do a null check etc. I type about 60wpm but commit maybe 100 loc of production ready code a day. The bottleneck isn't writing. It isn't thinking either: my list of "good ideas" and simple should do refactors grows faster than I can do them. I'm limited by my ability to find and debug stupid mistakes in code, whether mine or falsely blamed on me by CI.
Pair programming could help with that I think (haven't done it for more than an hour at a time so don't feel confident stating an opinion one way or another0 because my tendencies towards stupid mistakes might not be the same as my pair. A quick: wait that is dumb every 10 min could save me hours of debugging. My guess though is that you should change pairs frequently so you don't start falling into the same mistakes as your partner or end up with 2 people that are the only guys that can review each others work because they are the only ones that have worked on X for a year.
Re: (Score:2)
You're maybe a better coder than I or people I've worked with. I find the majority of my time isn't spent "writing" it is spent finding the stupid little errors like a != that should be an == or forgetting to do a null check etc.
You'd probably benefit from a good static code analyzer. While they can't catch errors in logic where your code doesn't meet your requirements, even the simple ones can catch a lot of dumb things like skipped null checks, boundary violations, pointer violations, memory leaks, etc. The better tools are very sophisticated and can do deep examinations, and will track your code quality over time. They are also available as IDE plugins, you can run them on a build server, or both. They can save you hours of
Re: (Score:2)
How do you measure productivity?
Delivered code per engineer, or delivered code per dollar (rouble, rupee, etc). Depends on your measure. As AC says above, the costs for junior engineers are disproportionally lower.
Re: (Score:2)
Functionality delivered per engineer is a reasonable, although obviously incomplete, measure for managers to appraise individual engineers or teams.
Functionality delivered per dollar is a useful measure for customers to appraise projects, where a "customer" might be another business unit or an executive who authorizes funding for an internal project just as easily as a traditional (external) customer.
Both measures can, and often should, be used -- but obviously by different audiences, and for the different
Re: (Score:3)
Does having 5 people huddled around a computer increase productivity or increase slippage?
I think you misunderstand the meaning of the word "pair". Unless you're thinking two pairs and a hot-spare.
Re: (Score:2)
Does having 5 people huddled around a computer increase productivity or increase slippage?
I think you misunderstand the meaning of the word "pair". Unless you're thinking two pairs and a hot-spare.
Depends on the problem set - back in 8 bit days (when I was about 13) my school entered a "programming competition" where the code for competition had to be typed by hand into a single machine (per team). You could have other computers for parallel development, but the competing code was restricted to the single keyboard and screen interface. Teams were limited to 5 programmers each.
About half the teams "huddled around a single screen" and the other half (including us ;( ) split up onto 5 machines and the
Re: (Score:2)
Re: (Score:2)
From experience, I would say it ensures no good solution gets a chance.
Re: (Score:3)
I've had to deal with the client and the new support company several times over the last year and I agree that the mindset is completely different. They tend to work in teams of 2 or 3 with only one person doing any actual work at any given time. I'd love to say that the this results in either increased productivity or a better code
Re: (Score:2)
Retarded Array of Indiotic Doersoftheneedful.
Re: (Score:2)
In University in the 1980s, we called them "lab partners" - back then, a decent PC cost 2 month's gross salary of a starting BS degreed engineer, so there weren't that many machines to go around. It can work, it can work well, and it can go poorly - all depends on whether or not you've got a good working relationship with your "lab partner."
At University, it was a challenge to hang on to good lab partners with the courses shuffling two or three times a year - in a professional situation, if management and
Re:Nine years of pair programming? (Score:5, Insightful)
Nine freakin' years, the mind boggles.
On occasion I've sat with someone as we've worked through a complex thing and a second set of eyes was useful, and it wasn't terrible. I've definitely done code reviews, and it can contribute to better code.
But 9 years doing pair programming? Good lord, my first though is "you're doing it wrong".
If I wanted to spend 9 damned years helping a junior anybody build their confidence and skillset in anything ... I'd have gone into teaching.
This just seems like you get half productivity all of the time, instead of two people pushing out code on different things, and then reviewing/debugging it later.
Do we ever see "pair accounting" or "pair plumbing"? To do this all the time seems wasteful, and ridiculous. Nine years of it seems like madness.
Re: (Score:2)
Pair plumbing is actually quite common - though one half of the team (generally the "master plumber") is mostly engaged in sales and customer interfacing, while the junior is the one pulling toilets and sweating joints.
Re:Nine years of pair programming? (Score:4, Insightful)
1. Find a better teammate then. Tossing the baby out with the bathwater just because it didn't work for you is irrational.
2. When both of you are "in mental sync" it works great ! When not, it is a waste of time, for both of you. :-/
3. Did you forget Brook's Law? There is no silver bullet Why? Because it depends on _context_.
Re: (Score:2)
Well, given that morons amplify each other, I expect that the business model here is really not dependent on code-quality. Hence I expect the OP can just continue as they did so far. Defense contracts?
Re: (Score:2)
Clever PHBs... (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yeah but there is a definite downside - half the time your partner will be coding...
If you read TFA, pair programming typically got skewed so one person was using the computer, typically them ore senior. So...not really half and not sure which person, but one of you will be sitting around while the other does the work.
There is a third option (Score:3, Insightful)
...and it is rather simple.
Design > Discuss > Refine > Implement > Run code analysis
This can be done in any workflow and in pairs. You don't gobble up the time of two team members but you still get to discuss the most important part of the implementation. You can even do a light-weight review afterwards with a check list of practices to focus on.
Re: (Score:3)
+1
A common issue with code reviews is that the engineer making the change presents the completed implementation and the design *at the same time*. The collaboration early on to ensure a good design or theory of operation really helps cut down on the pain of code reviews.
Re: (Score:2)
+1
A common issue with code reviews is that the engineer making the change presents the completed implementation and the design *at the same time*. The collaboration early on to ensure a good design or theory of operation really helps cut down on the pain of code reviews.
Then that's not a code review. Anywhere I worked as a developer, we had separate design reviews that took place prior to the code being written.
Watching someone code drives me insane (Score:5, Interesting)
Re:Watching someone code drives me insane (Score:4, Interesting)
There's no way in hell I could function in that close proximity to ANYBODY for 9 years. Not even my wife, and I kinda mostly like her.
I don't wish to spend my day with someone right up along side me.
My experience with it is 1-2 hours is the absolute upper bound, and then it's going to turn into two kids in the back seat of a car on a long ride.
What idiot thinks doing this all day every day would increase productivity?? That isn't a team mate, it's a fucking cell mate.
Re: (Score:2)
Most projects the last year, where I was involved in coding and not architect, scrum master or dev ops, we did in pair programming. Not 100% of the time, but certainly around 75%
I doubt there was any way to be faster in those projects. The productivity boost of 'good pairings' os far beyond factor two. If you split the pair, both do individually less than 50% of the work they would do together.
No idea where this pair programming hate comes from yelled out by people who clearly never ever really tried it.
Jus
Re: (Score:2)
>
No idea where this pair programming hate comes from yelled out by people who clearly never ever really tried it.
Easy, if you're not the sort of person that easily spends extended time with other people then it's going to be something close to hell. Introverted people have to put effort into social interactions, and so will never ever want to spend 8 hours a day interacting with someone else, even someone they really like.
You don't actually need to try it to know that, it's down to how people are wired interpersonally. I can understand how it might work for some but I'm sure as anything it won't work for me as a defau
Re: (Score:2)
There's no way in hell I could function in that close proximity to ANYBODY for 9 years.
Somehow, based on your post history, I believe that lol
Re: (Score:2)
LOL .. and I have never claimed otherwise.
Re: (Score:2)
So, I'd say, if you're "coding" a full 8 hours a day, you're probably doing it wrong.
Some time needs to be devoted to defining the problem (this usually involves talking to people), some time needs to be devoted to research, review of existing code, tools selection, etc.
Some time needs to be devoted to keeping in sync with other aspects of the project, whether it's other software modules, hardware, whatever.
Heads down coding, 40 hours per week, will probably result in 20 hours of wasted effort due to insuff
Re: (Score:2)
I'd say if you're doing architectural stuff every day that you're doing it wrong. There's no way you should be pratting around with tools selection on a daily basis, and even your customers are unlikely to need to be pestered daily.
I suspect the problem is you've assumed everyone is working on the type of project you are, you're probably doing some customer facing UI type application like a web page. Not everyone is, some people work on libraries, others on compilers, others on large back end systems. These
Re: (Score:2)
You might be amazed how much "code" that is not web-pages still interfaces with people. If libraries and compilers aren't used by at least 100x as many programmers as the ones required to write and maintain them, I'd call "you're doing it wrong" on the libraries and compilers. I'll grant that "large back end systems" require a lot of effort, and maintenance, but in this case your "customers" are the programmers that interface to the system - and, in a way, the specifications of those interfaces.
If a codin
Re: (Score:3)
Watching someone else code is the most maddening thing. They always seem to take the long way of doing something; use the mouse and doing eight clicks where a keyboard shortcut would do, etc. I do my best to not watch people code when I'm trying to help them. I would have killed someone years ago if I did that full time.
Same here, it's one thing to discuss structure, interfaces and workflow but pair programming is two people painting a house with one brush. Even a training session with me typically starts with show and tell then handing off simple assignments to work on your own pace. You have the documentation, compiler, you can run it on some test data and I'm often going to outline a solution in the beginning. Even if we're two experienced developers working on it I'd rather play tag team or good developer/bad developer
Ensure quality? (Score:2, Troll)
This required us to do code reviews to ensure the quality of the code we delivered.
Ensure quality - that's adorable.
Re: (Score:2)
I am highly annoyed with code reviews, because people really aren't doing them. I find all sorts of bugs that should be caught by any cursory code review but they sneak past. I think most people just say "yup, looks ok, does the job, pass" without spending any meaningful time scrutinizing the code. Then I end up seeing the code and feel like an ass if I ask people to change it after it's already been done. Especiallly with things that work, aren't bugs, but just violate a lot of other common sense thing
Re: (Score:2)
I have found code reviews to be more about conformity and coding to the lowest common denominator than code "quality" (whatever that actually means). When there's complex and/or sophisticated code involved, even with in-line commentary, unless the reviewers are near, at or (preferably) above the skill/experience level of the coder, the exercise turns into either (a) a coding lesson or (b) directives to dumb it down -- and this doesn't usually help if you're the most experienced one. I don't mind the ment
Re: (Score:2)
coding to the lowest common denominator than code "quality" (whatever that actually means). When there's complex and/or sophisticated code involved, even with in-line commentary, unless the reviewers are near, at or (preferably) above the skill/experience level of the coder...
Reminded of the various quotes along the lines of: "I write a long letter because I don't have time to write a short letter"
"Anyone can write complex code, it takes a good coder to write simple code to complex problems"
Your job is to do what your company employed you to do. So your attitude could be correct, depending on your job.
Are you paid to develop code that will never be maintained? (eg R&D where you work only on prototypes?)
Or does your company pay you to develop code that can be maintained and i
Code Review Pair Programming (Score:5, Interesting)
A proper peer review process is far superior. Review your plan with your teammates. If you're working with components that others work on, make sure they are part of the plan review. Once all questions are answered, put your headphones on and go forth and code. Rely on unit tests to catch the obvious problems, rely on integration tests to catch less than obvious problems, rely on QA to catch what your integration tests miss. Use linting, static code analysis, and other tools like Sonarqube to identify potential problems within your code that may not manifest themselves under day to day usage. Voila...
Is it perfect? Of course not. Will your software be 100% bug free? Of course not. It also doesn't solve problems related to lack of intelligence or experience amongst your teammates, and it doesn't solve problems related to lack of foresight from management who impose impossible deadlines or who close deals with customers that include features which don't exist. But the team will still be more productive than if they had to share computers and work in pairs. Programmers need focus and pair programming will ruin any focus you could have.
Re: (Score:2)
> No, a review process is useless.
then
> You need actual code reviews for it to work,
I'm not sure what you're getting at.
The last two jobs I've done had a review process where all commits to the RCS resulted in a notification sent to the entire team, and was expected to be reviewed by two or more people.
One nice thing about this approach as well, better architecture. Not because of someone's review, but because the review process works far better when commits are small. Keeping commits small helped to
Re: (Score:2)
Re: (Score:2)
well, at Job 1 it was hit or miss, but at Job 2 we have a formal code review tool: https://www.reviewboard.org/ [reviewboard.org]
So yes, you do know who reviewed what, and whether or not they give their seal of approval.
now I'll admit that someone can just mark a review as fine without having read it, but as I said, nothing is perfect. Our process could certainly be improved more if we used a Github-style way of managing code (pull requests and all that) but since we use SVN and do all our work on the master branch it won't
Re: (Score:2)
Re: (Score:2)
It's pretty easy to require formal sign-offs by reviewers.
In fact, that is how it's done in most mature IT organizations.
Re: (Score:2)
Re: (Score:2)
Maybe not, but the reviewers' ass is on the line for bugs found that his review should have caught.
Skim over reviews too many times and it's bye bye.
Doing a bad job should have consequences.
Though I admit that might not work in smaller organisations.
Re: (Score:2)
Nine years? Where? (Score:2)
>> I've spent nine years working in teams which religiously follow pair programming
I've been in software development for 18 years and pair programming has always sounded like a myth to me - I've never actually met anyone doing it for anything other than learning a new technology.
>> required us to do code reviews to ensure the quality of the code we delivered
Hell, at half the places I've worked code reviews were considered an unnecessary luxury. These days I'm just happy to hold the line at TDD
Re: (Score:2)
Re: (Score:2)
As no good coders work there (they have all gone to greener pastures), maybe you can bring code quality there up from "complete and utter crap" to "complete crap". Not sure this is worthwhile doing though. (Yes, I have reviewed code produced there. Several times. The sheer level of non-understanding you can find in there is staggering.)
XOR? (Score:2)
Any designs and code developed in my projects is going to get peer reviewed, whether pair programmed or not.
Collaboration (Score:3, Informative)
I wouldn't know a better way to destroy productivity than having people pair programming in a public space. How is anyone supposed to concentrate on their work or their coding partner while listening to the conversations of everyone else in the room at the same time?
Not big on pair programming but (Score:3)
Pair programming is like tandem bicycling (Score:5, Insightful)
There might be times when it's nice to have the second person helping pedal up a long hill. But you're certainly not going to double your speed or your stamina with two people on one bicycle.
Pair programming is like that. There are specific situations where it's useful, especially when you're dealing with a tricky algorithm or intricate business requirements. But much of the time, the second person is just dead weight.
Re: (Score:2)
What is right for mechanical work is not right for mental work.
Pairing mental workers usually increases their performance by factors of three to five and often more.
The key term is: synergy!
Re: (Score:2)
We should try quadding[1] them then. Will that make their productivity go up by six to ten, or by nine to twenty-five, or some other number?
Feel free to pull a figure out of your arse. You should be able to remember where it is.
[1] it is now.
Re: (Score:2)
Only if their productivity and result quality is exceptionally bad in the first place. In that case, it is still bad when increased 3-5 times and basically the only thing you can do with the results is throw them away. It is the cheapest option.
Team Reviews are far superior (Score:5, Interesting)
In our organisation, we have teams of six people that work together on their sprint. QA staff are included in this team.
On major features, the team code reviews the feature together in a special session. Roles are assigned. The author is present, a reader (who is not the author) reads the code. There is an arbitrator who decides whether a raised issue gets fixed. This arbitrator role is rotated through the team on an inspection by inspection basis. Finally, there is a time keeper role who moves the conversation to a decision if one topic is debated for more than three minutes.
This process typically finds a humongous number of issues. It takes us about 4 hours of applied effort to discover a bug in pure functional testing. This process discovers bugs at a rate of 1.25 bugs per man hour of applied effort. So if you have five people in a room for one hour, you have applied 5 man hours. You'd expect to find 6-7 bugs. If you include all the stylistic coding standards bugs, this is typically 10-15 bugs per hour.
So while on the surface it looks expensive to have all those people in a room talking. The net result is that it tends to accelerate delivery because so many issues are removed from the software. Better still, the review occurs before functional testing begins. This means the QA staff on the team can direct their testing at the areas highlighted by the inspection process. This further improves quality
It's true that about 50% of the ossies are stylistic issues. But usually we get 1 or 2 bugs per session that present a serious malfunction in the program. The rest could be problems under some circumstances or minor faults.
Team reviews are vastly, vastly superior to pair-programming. There really is no contest.
Re: (Score:3)
Re:Team Reviews are far superior (Score:4, Interesting)
You sound like a bean counter, and your organisation sounds like it is hell to work in. 1.25 bugs per man hour? Christ.
Well I'm the head of development at our place so I inhabit both worlds. Businesses like to measure return on investment. By being able to speak that language, I can generally frame activities developers naturally want to do in those terms. This leads to developers getting more of what they want.
You know what developers really, really, really hate? Having to work with technical debt and having no process to remove that technical debt because the program is now "working".
The best way around technical debt is not to put it in to the program in the first place. This process does a sterling job at that. So our developers are generally a pretty happy bunch.
Technical debt (Score:3)
Re: (Score:2)
Please mention the place so I never get into a mile of it. How would of Linus have created Linux without people like you? Didn't he understand the technical debt he was creating? He could have been finding bugs at a rate of 1.25 per applied man hour instead of actually creating something useful! Silly man. You process guys are useless.
I find this example really odd because Linux is built around a process of a huge amount of code review. They do it differently because they're a distributed team but they absolutely have a rigorous code review process.
Re: (Score:3)
No offense meant, honestly, but your place sounds miserable to work at. It's not the process, but the ridiculous level of formalization and standardization.
Code inspections work best when they're formal with clearly defined roles and clear reporting steps. There have been large scale studies done that confirm this. The research fed in to the development of the Cleanroom methodology pioneered at IBM.
The less formal the structure, the less well it works.
One of my big bugbears with software development as a craft is our failure to really learn from experience. There were lots of studies done on the craft from decades ago that cleanly establish these basic pr
Re: (Score:2)
Now if Microsoft would lock all their developers in a room for a year, we could get a stable release of Windows.
Re: (Score:2)
When I look at the list of 100 bugs found by a single tester in my team, who is not busy having review meetings and counting metrics, in a week, I laugh at these numbers.
If your tester is finding 100 bugs a week, you're doing it wrong. Your underlying quality is much too low. It's much more expensive to find a bug by functional testing than by code inspection. This is because all those bugs need to be fixed and retested. This usually requires a rebuild and other ancillary tasks that drive up cost.
Worse, it's usually a geometric progression with this kind of pattern in that for every hour spent bug fixing, there's a ratio of new bugs introduced that have to be removed by the
Software development has become idiotic... (Score:5, Insightful)
... I swear. Lean, SCRUM, XP, Agile, Waterfall, Kanban, Scrumban, TDD, BDD, Pair Programming, Code Review, User Stories... etc... etc... etc.
How about just be a responsible craftsman, understand the customer's requirements and needs, and implement your solution responsibly and with integrity? Whatever that means. If you need to pull someone in, then do it. If you don't, then don't. Christ, how complicated is this? It's one thing to be a junior developer and having to learn things. Fine. But an experienced software developer should not require constant canoodling to get their job done responsibly, with integrity, and with good quality. Is it really that hard?
I'm from a pretty old-school programming upbringing -- back when you were a "Programmer" or "Analyst" or "Programmer/Analyst". I'll tell you in those days... if a programmer demanded this kind of ridiculous hand-holding, canoodling, and process-implementation to get their job done... they would be fired. Plain and simple. This industry has become awash with process and tool zealots... while knowing the customer's needs be damned.
Re: (Score:2)
Re: (Score:2)
I don't get why you are riding on 'bugs found per man hour' since ten posts when the parent only wanted to make an example about 'when grouping up experts into one room for one task' has synergetic effects and the speed increae they solve the problems is higher than linear.
No one in the industry us measuring 'bugs found per man hour'. If we measure then we measure 'bugs introduced per man hour'. And probably we have to overlapping graphs of bugs discovered per sprint and bugs solved per sprint. And obviousl
Re: (Score:2)
If that was not clear for you: you should witch business.
I placed a curse on my employer. I think it worked because they lost a lot of money and fired my entire group.
Re: (Score:2)
Re: (Score:2)
Look man, we can't do anything unless there's a trendy buzzword name for it.
Re: (Score:2)
Naaa, craftsmanship and actual competence is something the MBA bean-counter morons cannot understand (as it involves the real world) and hence it is dead.
When I look what the younger generation is learning today, I expect that I will have a job writing actual good code far over my retirement-age, because most of them sure as hell cannot do it.
Pair programming is stupid (Score:2)
Pair sysadminning (Score:2)
Pair sysadminning is something I have actually done, and that has its uses. The guy who knows most has the keyboard, and the other guy has one finger tracing the manual's instructions, as well as a notebook where he writes down what happens and why, especially including things that won't be in the terminal session script like "I'll correct that later" or "This value should work, let's check".
But nowadays with Infrastructure as Code and Network as Code and what have you, you check your sysadminning code into
We are engineers, not monks! (Score:2)
I've spent nine years working in teams which religiously follow pair programming.
That is one clusterfuck of a professional experience. To me this tells me a lot of work in those years constituted code monkeying.
For starters, we are engineers. We are supposed to use general principles to solve real world non-trivial problems. This implies a need for adapting processes to issues at hand. Professional discretion is required when performing activities. Following something religiously gives me the notion of people going through the emotions by orders given from above. Good way for herding
Context Context Context (Score:3, Interesting)
Reviews always required (Score:3)
Even if you would think pair programming makes sense (I don't, but it might be cultural as some have claimed), they cannot replace code reviews.
Both "pair programmers" are following the same thought process and may fall in the same trap.
A fresh look, by someone who wasn't involved in coding is always required.
They both suck (Score:2)
Pair programming requires one to continuously socialize with someone nonstop for entire working day, something that most people, let alone most software engineers, can not do while maintaining concentration, creativity or sanity.
Code reviews encourage filibusters when someone keeps adding to the comment thread just because they personally want something done differently and others find it rude to approve the change and curtail discussion.
What works well is running lint and writing good tests. Then if someon
Vs? (Score:2)
Why vs? Neither of them is worth crap for actually improving code. Room and incentives to refactor and simplify plus unit tests (of functionality and not deeply dependent on exact implementation) does a lot more good.
Get a projector (Score:2)
The only way I could get pair programming to work was to get in a room with a projector, and give the one developer the control of the keyboard. The other developer gives instructions and directs the flow (while also writing things out on the whiteboard to teach the other). If some changes/fixes take a lot of time, this lets the both developers work on their own laptops.
This worked irrespective of whether the junior/senior dev was projecting. It is more hands on for the driver, while giving more flexibility
Team dynamics (Score:2)
Pair-programming is hard, code reviews are pretty easy. Pair-programming increases team cohesion, but it to be properly done or it becomes than useless.
There is the driver, who writes the code and the observer who review and thinks more about the general design. There should be a frequent alternance, unless there is a vast experience gap between the two people, then the less experimented drives more (to avoid the keyboard domination antipattern).
Pair-programming should only
Re:Count me out (Score:4, Funny)
You prefer peer review or test-driven?
Re: (Score:2)
Peer review is a must regardless if you develop test driven or not.
How do you make sure a test tests what it is supposed to test without a review?
I can certainly crank out 100 tests per hour that all are green and test nothing of any meaning.
Re: (Score:3)
If you haven't been to the range for a day or two than yellowish is OK.
You should see a doctor.
Re: (Score:3)
I guess if you crank out a 100 per hour, all green is somewhat to be expected.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Indeed. And no understanding what a good result actually looks like.
Re: (Score:2)
It's s reference to the movie Swordfish.