5 ms·

Like many things in programming, we adopt it like a cargo cult ( https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_p

by harryf 5y ago

Like many things in programming, we adopt it like a cargo cult ( https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming ) based on "some thought leader said" or "some company has amazing..." without actually doing any serious study. It's actually amazing for an industry that should be all about rational, reasoned analysis, that we're willing to perform such experiments on ourselves with so little evidence to show the value. There is this study here - https://www.researchgate.net/publication/222408325_The_effectiveness_of_pair_programming_A_meta-analysis https://www.researchgate.net/publication/222408325_The_effec... "A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high." There are links to a few more here - https://tuple.app/pair-programming-guide/scientific-research-into-pair-programming https://tuple.app/pair-programming-guide/scientific-research... - none of it looks particularly compelling. And I'm not "against" pair programming. It's just sad to see "cargo cult" adoption of practices.

hughrr 5y ago
I'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion. The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can't seem to see this at all and when asked for some sort of rational proof, something I do regularly, tend to switch to a personal or ideological attack instead. It's slightly tiring to be fighting the front of rationalism in an industry which appears to be driven partially by fashion. As for pair programming, 100% anecdotally I find that sometimes you need a second set of eyes on a problem when you can't see the forest for the trees. But mostly it's inefficient and unproductive and absolutely crippling for small teams.
- Agentlien 5y ago
  I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
  - harryf 5y ago
    ...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging )
    - Agentlien 5y ago
      I want very different things from my rubber ducks and my code reviews. Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic. Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices. Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.
    - hughrr 5y ago
      I do this. It works. I have a stuffed parrot though. And everyone thinks I’m nuts but I don’t care :)
  - MockObject 5y ago
    I despise code reviews, because the criticism is shallow, and offered too late, after the work has been done. I want the review in real time, and at a greater depth of insight. This is what pairing provides.
    - Agentlien 5y ago
      Shallow and too late criticism sounds like a problem with how the reviews are handled. At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved. I also found it a great way to catch subtle bugs or difficult to follow logic. But it does require actually having and taking the time to carefully review things, rather than giving them a passing glance.
throwaway894345 5y ago
Personally our industry needs to mature a lot with respect to its ability to critically understand studies before they’re going to be useful. Thus far it seems like the headline version of the first article which purports to analyze a topic is taken as gospel with respect to the topic in question. People still trot out that old article that “finds” that statically typed languages don’t reduce bugs (i.e., 90s era OOP creates enough bugs to offset those precluded by type checkers). If we’re going to depend on formal studies for these hugely multivariate issues we need a lot more rigor before they are more helpful than mere “collective industry experience”.
JohnWhigham 5y ago
It's because software is incredibly amorphous. It's incredibly hard to compile meaningful metrics about it, partly because every project is different and used differently. We all know this in the back of our heads, and how incredibly daunting it is to squeeze out quantifiable data from it, so we instead don't tackle it (which is normal behavior for humans) and instead go with stuff that sounds and feels good. Pairing increases your code output Well, two it better than one, so it must be better! TDD prevents bugs? Well, writing the tests first sounds good to me, so it must be better! Yeah, it's a dangerous mindset, and I don't really know how to get out of it, especially since we're all hypocrites to some degree.

by harryf 5y ago

hughrr 5y ago

I'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion. The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can't seem to see this at all and when asked for some sort of rational proof, something I do regularly, tend to switch to a personal or ideological attack instead. It's slightly tiring to be fighting the front of rationalism in an industry which appears to be driven partially by fashion. As for pair programming, 100% anecdotally I find that sometimes you need a second set of eyes on a problem when you can't see the forest for the trees. But mostly it's inefficient and unproductive and absolutely crippling for small teams.

Agentlien 5y ago
I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
- harryf 5y ago
  ...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging )
  - Agentlien 5y ago
    I want very different things from my rubber ducks and my code reviews. Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic. Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices. Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.
  - hughrr 5y ago
    I do this. It works. I have a stuffed parrot though. And everyone thinks I’m nuts but I don’t care :)
- MockObject 5y ago
  I despise code reviews, because the criticism is shallow, and offered too late, after the work has been done. I want the review in real time, and at a greater depth of insight. This is what pairing provides.
  - Agentlien 5y ago
    Shallow and too late criticism sounds like a problem with how the reviews are handled. At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved. I also found it a great way to catch subtle bugs or difficult to follow logic. But it does require actually having and taking the time to carefully review things, rather than giving them a passing glance.

throwaway894345 5y ago

Personally our industry needs to mature a lot with respect to its ability to critically understand studies before they’re going to be useful. Thus far it seems like the headline version of the first article which purports to analyze a topic is taken as gospel with respect to the topic in question. People still trot out that old article that “finds” that statically typed languages don’t reduce bugs (i.e., 90s era OOP creates enough bugs to offset those precluded by type checkers). If we’re going to depend on formal studies for these hugely multivariate issues we need a lot more rigor before they are more helpful than mere “collective industry experience”.

JohnWhigham 5y ago

It's because software is incredibly amorphous. It's incredibly hard to compile meaningful metrics about it, partly because every project is different and used differently. We all know this in the back of our heads, and how incredibly daunting it is to squeeze out quantifiable data from it, so we instead don't tackle it (which is normal behavior for humans) and instead go with stuff that sounds and feels good. Pairing increases your code output Well, two it better than one, so it must be better! TDD prevents bugs? Well, writing the tests first sounds good to me, so it must be better! Yeah, it's a dangerous mindset, and I don't really know how to get out of it, especially since we're all hypocrites to some degree.