4 ms·

In my experience of the past 5 years: yes. Substantially better idea-to-production latency, given a high minimum standard for releaseability. Little's Law is i

In my experience of the past 5 years: yes. Substantially better idea-to-production latency, given a high minimum standard for releaseability. Little's Law is instructive. There are two ways to increase throughput in a system. One is to reduce latency. The other is to increase in-process inventory. They have very different dynamics.

scarface74 8y ago
Most software development like everything else is a combination of inspiration and perspiration. How much time is spent in average day coming up with “ideas” versus just doing the work? Or putting it in production terms, the number of people coming up with ideas for the iPhone in Cupertino is dwarfed by the number of people building them in China.
- jacques_chester 8y ago
  I'm not sure what you're driving at here.
  - scarface74 8y ago
    That you don’t need pair programming to do much of the grunt work that’s involved in development. Do you really need help making sure you write a for loop correctly?
    - jacques_chester 8y ago
      I do if I'm about to do it wrong, or if something other than a loop might be better, or to write the test that drives it out, or to show me a trick I didn't know, or to get me unstuck, or to tell me there's a library function that lets us skip a loop, or ... Is your argument that I don't know how pairing works? Because my estimate is that I have around 8,000 hours practicing it at this point, which I suspect may be 8,000 hours or so more than your own professional pairing experience. It's possible that I've been sleep-walking through the whole thing, but unlikely. One of the dozens of intelligent, helpful people I've worked with would've pointed it out.
      - scarface74 8y ago
        I’ve been writing code for over 30 years including two assembly language instruction sets (one before going to high school), and C on 4 platforms. I’ve been using my preferred language C# for a decade and JavaScript since it was introduced by Netscape in the 90s. I think I’m capable of writing decent performant code without pairing....
        jacques_chester 8y ago
        In my anger I turned this into a measuring contest. I think what you're reading is me saying "it's impossible to write good code without a pair", which (a) isn't true and (b) isn't what I said. What I'm reading is that you say pairing is strictly less effective than soloing, which (a) isn't true and (b) isn't true. If we were talking about professionally programming in assembly language, I would take your views seriously because of your relevant experience in that matter. In doing so I might not agree and I would very likely be wrong, but I would acknowledge your expertise on that topic. What I ask is the same courtesy when it comes to pairing.
        scarface74 8y ago
        The opposite of “pair programming” isn’t “developing solo”. Like I said above, most problems that developers are working on everyday isn’t some complex algorithm it’s translating business requirements to code. Collaboration is often definitely better than developing solo but it isn’t “pair programming”. But developing solo can be faster. The more developers you add to a feature, the more communication and coordination overhead you have (The Mythical Man Month a book written in the 60s). Honestly, we’ve found that three people working on three separate features solo can get more done than three people working on the same feature over the same amount of time. Again we make it a point to switch up so we can see the whole picture. When the product owner comes in and realizes we didn’t consider something, it’s almost always faster to have that one person who knows how the change will affect the whole stack - UI/Back end/database/deployment, infrastructure requirements than to have five people trying to coordinate the change. Collobaration can mean “war rooming” or “swarming”. War rooming for example is getting your back end and front end developer together in a room along with your QA person, your Devops, and your product owner working on their piece of the feature, rapidly iterating. I work on a team where each developer can easily go back and forth between the three languages we use (JS/C#/Python), front end development in React, database design, Devops with CloudFormation, CodeBuild, Code Deploy and Code Pipeline sometime we will split up the parts. Other times one person will do a quick design session, do the whole stack, do a post review along with design docs in MarkDown. If you have well rounded developers, they will often switch roles on the next feature just to have knowledge and a different perspective.

scarface74 8y ago

Most software development like everything else is a combination of inspiration and perspiration. How much time is spent in average day coming up with “ideas” versus just doing the work? Or putting it in production terms, the number of people coming up with ideas for the iPhone in Cupertino is dwarfed by the number of people building them in China.

jacques_chester 8y ago
I'm not sure what you're driving at here.
- scarface74 8y ago
  That you don’t need pair programming to do much of the grunt work that’s involved in development. Do you really need help making sure you write a for loop correctly?
  - jacques_chester 8y ago
    I do if I'm about to do it wrong, or if something other than a loop might be better, or to write the test that drives it out, or to show me a trick I didn't know, or to get me unstuck, or to tell me there's a library function that lets us skip a loop, or ... Is your argument that I don't know how pairing works? Because my estimate is that I have around 8,000 hours practicing it at this point, which I suspect may be 8,000 hours or so more than your own professional pairing experience. It's possible that I've been sleep-walking through the whole thing, but unlikely. One of the dozens of intelligent, helpful people I've worked with would've pointed it out.
    - scarface74 8y ago
      I’ve been writing code for over 30 years including two assembly language instruction sets (one before going to high school), and C on 4 platforms. I’ve been using my preferred language C# for a decade and JavaScript since it was introduced by Netscape in the 90s. I think I’m capable of writing decent performant code without pairing....
      - jacques_chester 8y ago
        In my anger I turned this into a measuring contest. I think what you're reading is me saying "it's impossible to write good code without a pair", which (a) isn't true and (b) isn't what I said. What I'm reading is that you say pairing is strictly less effective than soloing, which (a) isn't true and (b) isn't true. If we were talking about professionally programming in assembly language, I would take your views seriously because of your relevant experience in that matter. In doing so I might not agree and I would very likely be wrong, but I would acknowledge your expertise on that topic. What I ask is the same courtesy when it comes to pairing.
        scarface74 8y ago
        The opposite of “pair programming” isn’t “developing solo”. Like I said above, most problems that developers are working on everyday isn’t some complex algorithm it’s translating business requirements to code. Collaboration is often definitely better than developing solo but it isn’t “pair programming”. But developing solo can be faster. The more developers you add to a feature, the more communication and coordination overhead you have (The Mythical Man Month a book written in the 60s). Honestly, we’ve found that three people working on three separate features solo can get more done than three people working on the same feature over the same amount of time. Again we make it a point to switch up so we can see the whole picture. When the product owner comes in and realizes we didn’t consider something, it’s almost always faster to have that one person who knows how the change will affect the whole stack - UI/Back end/database/deployment, infrastructure requirements than to have five people trying to coordinate the change. Collobaration can mean “war rooming” or “swarming”. War rooming for example is getting your back end and front end developer together in a room along with your QA person, your Devops, and your product owner working on their piece of the feature, rapidly iterating. I work on a team where each developer can easily go back and forth between the three languages we use (JS/C#/Python), front end development in React, database design, Devops with CloudFormation, CodeBuild, Code Deploy and Code Pipeline sometime we will split up the parts. Other times one person will do a quick design session, do the whole stack, do a post review along with design docs in MarkDown. If you have well rounded developers, they will often switch roles on the next feature just to have knowledge and a different perspective.