Comments on: Pair Programming in the New York Times http://pathfindersoftware.com/2009/09/pair-programming-york-times/ The Fastest Way to Launch Successful Software Thu, 19 Jan 2012 16:36:03 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Adam D. http://pathfindersoftware.com/2009/09/pair-programming-york-times/#comment-9779 Adam D. Sat, 24 Oct 2009 00:05:05 +0000 http://www.pathf.com/blogs/?p=4178#comment-9779 Don't worry about the naysayers. Too much navel gazing is prevalent in this industry. Too much time is spent down a rabbit hole chasing a go nowhere solution. No matter how many code reviews you do, you'll still have as many coding styles in your projects as you have devs. Too much bad design and code goes unnoticed. What pair programming does not allow equates to 10x the productivity, not 30% or 50% that the short sighted "how many feature points can a pair hack out vs single dev" experiments yield. Until the Nathaniel Anthonys of the world "get it" we all have a lot of money to make as consultants taking companies out of projects gone bad. I don't think that's any time soon. Bring on the next version 5 disaster... Adam Don’t worry about the naysayers. Too much navel gazing is prevalent in this industry. Too much time is spent down a rabbit hole chasing a go nowhere solution. No matter how many code reviews you do, you’ll still have as many coding styles in your projects as you have devs. Too much bad design and code goes unnoticed.

What pair programming does not allow equates to 10x the productivity, not 30% or 50% that the short sighted “how many feature points can a pair hack out vs single dev” experiments yield.

Until the Nathaniel Anthonys of the world “get it” we all have a lot of money to make as consultants taking companies out of projects gone bad. I don’t think that’s any time soon. Bring on the next version 5 disaster…

Adam

]]> By: Aron Pilhofer http://pathfindersoftware.com/2009/09/pair-programming-york-times/#comment-9778 Aron Pilhofer Mon, 05 Oct 2009 12:17:11 +0000 http://www.pathf.com/blogs/?p=4178#comment-9778 Funny thing: That piece could have been written about pair programming AT The New York Times. We do it all the time in my group. I agree (in small part) with Nathaniel that the benefits can be overstated, and taken too far. But good vastly outweighs the bad. Funny thing: That piece could have been written about pair programming AT The New York Times. We do it all the time in my group. I agree (in small part) with Nathaniel that the benefits can be overstated, and taken too far. But good vastly outweighs the bad.

]]> By: Pair Programming: Lone Programmer Shoots Back | Pathfinder Development | Software Developers | Blogs http://pathfindersoftware.com/2009/09/pair-programming-york-times/#comment-9777 Pair Programming: Lone Programmer Shoots Back | Pathfinder Development | Software Developers | Blogs Wed, 30 Sep 2009 20:38:59 +0000 http://www.pathf.com/blogs/?p=4178#comment-9777 [...] got a few angry and scolding comments on my last post on pair programming. Let me address each of the issues in [...] [...] got a few angry and scolding comments on my last post on pair programming. Let me address each of the issues in [...]

]]> By: Maxime Robert-Schreyers http://pathfindersoftware.com/2009/09/pair-programming-york-times/#comment-9776 Maxime Robert-Schreyers Tue, 29 Sep 2009 07:34:38 +0000 http://www.pathf.com/blogs/?p=4178#comment-9776 Hello, The Pathfinder blog is a great source of interesting opinions and informations. However when making bold statements like "two developers working apart are less productive than two developers working together (fact!)", it's better to either reference some studies or to leave out the "(fact!)" which doesn't add much credibility to the statement (a bit like "not lying, I promise!"). A quick googling gave http://portal.acm.org/citation.cfm?id=1161678 and http://www.springerlink.com/content/mpv6y08254rqw98h/ Besides that detail, keep the great posts coming :-) Maxime Hello,

The Pathfinder blog is a great source of interesting opinions and informations.

However when making bold statements like “two developers working apart are less productive than two developers working together (fact!)”, it’s better to either reference some studies or to leave out the “(fact!)” which doesn’t add much credibility to the statement (a bit like “not lying, I promise!”).

A quick googling gave
http://portal.acm.org/citation.cfm?id=1161678
and
http://www.springerlink.com/content/mpv6y08254rqw98h/

Besides that detail, keep the great posts coming :-)
Maxime

]]> By: Nathaniel Anthony http://pathfindersoftware.com/2009/09/pair-programming-york-times/#comment-9775 Nathaniel Anthony Tue, 29 Sep 2009 01:23:01 +0000 http://www.pathf.com/blogs/?p=4178#comment-9775 It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy. I also do not understand what the obsession is with that retarded "Bus" analogy. I've heard it over and over and over again and rarely have I ever found it to be true. I'm not saying that it is not true because no one ever gets hit by a bus (sure, it could happen), but because it is rarely the case that a developer will leave suddenly as if they were hit by a bus. When core talent leaves an organization it is because the organization is not able to hold on to an essential asset. Management rarely ever likes to acknowledge being the cause of someone leaving. If someone is an expert within a subject and is constantly assigned to the same type of work, that is a flaw of management not trusting a developer to work on something else out of fear it might take too long. What ultimately boils my skin about things like pair programming is that it is the sort of thing that niche companies expect as a requirement for employment. Software development is such a fragmented industry that someone with valuable skills gets ignored because there is no common comparison between a developer with one skill set and a developer who has experience with something entirely different. It is amazing how insulting people can get when waxing on about the benefits of Pair programming. It is one thing to make the business case to an organization that Pair programming can be beneficial to an organization, but it becomes downright mean when developers get classified as being lazy because they are not paired up. As someone who has spent many a night working (alone) for as long as it takes to complete a project on time without anyone noticing, I seriously disagree with the notion that by not pair programming, developers are lazy.

I also do not understand what the obsession is with that retarded “Bus” analogy. I’ve heard it over and over and over again and rarely have I ever found it to be true. I’m not saying that it is not true because no one ever gets hit by a bus (sure, it could happen), but because it is rarely the case that a developer will leave suddenly as if they were hit by a bus. When core talent leaves an organization it is because the organization is not able to hold on to an essential asset. Management rarely ever likes to acknowledge being the cause of someone leaving. If someone is an expert within a subject and is constantly assigned to the same type of work, that is a flaw of management not trusting a developer to work on something else out of fear it might take too long.

What ultimately boils my skin about things like pair programming is that it is the sort of thing that niche companies expect as a requirement for employment. Software development is such a fragmented industry that someone with valuable skills gets ignored because there is no common comparison between a developer with one skill set and a developer who has experience with something entirely different.

]]>