4 ms·

Here are some examples of trust-but-verify relationships at work: - You are allowed to expense things while traveling, but someone will look at what you put on

Here are some examples of trust-but-verify relationships at work: - You are allowed to expense things while traveling, but someone will look at what you put on the company card afterwards. - They don't wait on your background check before moving ahead with interviews. - Someone really should look at your code, at some point, before it is released.

Cthulhu_ 4y ago
And to extend the last point: before it is merged, to keep the mainline in a releasable state: 1. Continuous deployment means your mainline is sacred and always in a releasable state. 2. Unit tests and automated verifications only tell part of the story 3. Churn should be avoided (e.g. fixing code style issues); if fixes are made before it enters the mainline, it is avoided. 4. Code reviews should be asynchronous, because pulling someone out of their flow to switch to doing a code review is rude and unproductive.
- pyrale 4y ago
  > Churn should be avoided One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much than too few.
  - ilyt 4y ago
    Disagree. Mixing random style fixes in-between actual code just makes reading changelog more annoying. Sure, if you are refactoring some function put format changes with it but that's the most you should do. If you want to make those: * make it in separate bunch of commits * make sure team uses tooling that will not allow new style problems to happen, like mandating certain formatter with certain settings before each commit. Most editors have hooks to do it automatically, and if they don't, Git have them too It also makes git blame less useful althought it now have options to ignore moved code or whitespace changes so it isn't as much of a deal now.
    - pyrale 4y ago
      It seems like your definition of "churn" is "all those petty and annoying things I shouldn't be concerned with or can be easily automated away". By that definition, of course, churn should be avoided when possible. However, plenty of useful changes also qualify as churn, for instance: * renaming stuff * extracting a function to split a block that may have been fine for the author, but that you found hard to read. And yes, sometimes, reviews don't catch all those. * Add a comment to provide context to an algorithm after you talked with business All of these things (and others) are pretty valuable, and the cumulative effect of reducing friction against these changes add up to much better codebases, with less places where no one wants to work because of abandonment. This kind of light touches should take a couple minutes while reading your codebase, not half-a-day because you need to fill a PR and wait for someone to be available.
- mrits 4y ago
  "Continuous deployment means your mainline is sacred and always in a releasable state." Well if that is true why not just stop there?
serial_dev 4y ago
This is how I see the pull request example with credit cards and traveling. You are on your way to a conference. You are at the airport and want to buy a coffee and a donut. You make a request... You've been waiting for almost an hour now. Nobody takes a look at and you still need multiple approvals, so you ping Barbara in charge of approvals to get the ball rolling, she says she will take a look after a meeting she is currently attending because she wants to be careful with what she approves. Oh, Tom, her colleague asks you why don't you eat salad and orange juice, it's cheaper and faster. You have a quick call with Tom to explain why you want a coffee and donut. Awesome, you convinced Tom to approve in just under 20 minutes. Barbara is back, but she doesn't respond... She is MIA, she went for breakfast... Your plane is leaving, so you skip breakfast. You arrive, by the time you land Barbara approved your breakfast, but now you are in a new country and circumstances changed, so you update your request. The earlier approvals are now invalid. You go through the whole charade again... Pull requests assume you cannot trust your colleagues to make reasonable choices and you also don't trust your automated tests to catch anything insane (buying a 100k car for breakfast in the above example), so you have to gatekeep and slow down your team to make sure (?) that the code they commit is good.
- wizofaus 4y ago
  I don't assume my colleagues will always make "reasonable" choices and furthermore correctly express those choices into code any more than I will myself! In fact perhaps most of the issues I find in PRs are after reviewing my own ones (often it's silly things like accidentally including files/commits I shouldn't've have). Plus knowing someone else must've approved my PR stops me feeling quite so silly if it does end up breaking something :) The breakfast order analogy to me falls down because not being able to merge a PR into the mainline branch immediately is exceedingly rarely something that holds me up - there's always plenty of other stuff to do. And the time I spend reviewing PRs is valuable in its own right, even if I find nothing wrong (understanding the codebase better etc.). Sure the odd PR or two for a truly trivial change slows up the works a little but they're pretty rare and a it's a small price to pay. Having said all that, I'm genuinely interested in what studies might have been done to genuinely guage the effectiveness of the PR/review process. I've certainly worked on some (open source) projects where it clearly was a major drag on productivity, as very few people had approval rights (wherever I've worked professionally all devs have the same rights - single approval from any other dev is always sufficient).
SkyBelow 4y ago
Are those relationships really trusting then? Or is it an optimized way that catches fraud before it is too bad while reducing the increased expense of avoiding fraud? If you have to get all expenses approved before they are charged to the card, then it adds much more overhead and planning which decreases efficiency. The amount of fraud that happens by letting someone charge things and verifying it later ends up being a smaller expense than the amount of preplanning. Similar with interviews. The amount of time wasted by interviews of someone who doesn't pass a background check is a small cost than the cost of doing interviews of everyone before doing a background check (not just the cost of the background check, but having a longer interview process leading to missing out on candidates and more candidates getting part the way through the process and dropping out because another place gave them an offer). Imagine a father trying to "trust but verify" the paternity of their child. If there has to be verification, it will be taken as a lack of trust.

Cthulhu_ 4y ago

And to extend the last point: before it is merged, to keep the mainline in a releasable state: 1. Continuous deployment means your mainline is sacred and always in a releasable state. 2. Unit tests and automated verifications only tell part of the story 3. Churn should be avoided (e.g. fixing code style issues); if fixes are made before it enters the mainline, it is avoided. 4. Code reviews should be asynchronous, because pulling someone out of their flow to switch to doing a code review is rude and unproductive.

pyrale 4y ago
> Churn should be avoided One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much than too few.
- ilyt 4y ago
  Disagree. Mixing random style fixes in-between actual code just makes reading changelog more annoying. Sure, if you are refactoring some function put format changes with it but that's the most you should do. If you want to make those: * make it in separate bunch of commits * make sure team uses tooling that will not allow new style problems to happen, like mandating certain formatter with certain settings before each commit. Most editors have hooks to do it automatically, and if they don't, Git have them too It also makes git blame less useful althought it now have options to ignore moved code or whitespace changes so it isn't as much of a deal now.
  - pyrale 4y ago
    It seems like your definition of "churn" is "all those petty and annoying things I shouldn't be concerned with or can be easily automated away". By that definition, of course, churn should be avoided when possible. However, plenty of useful changes also qualify as churn, for instance: * renaming stuff * extracting a function to split a block that may have been fine for the author, but that you found hard to read. And yes, sometimes, reviews don't catch all those. * Add a comment to provide context to an algorithm after you talked with business All of these things (and others) are pretty valuable, and the cumulative effect of reducing friction against these changes add up to much better codebases, with less places where no one wants to work because of abandonment. This kind of light touches should take a couple minutes while reading your codebase, not half-a-day because you need to fill a PR and wait for someone to be available.
mrits 4y ago
"Continuous deployment means your mainline is sacred and always in a releasable state." Well if that is true why not just stop there?

serial_dev 4y ago

This is how I see the pull request example with credit cards and traveling. You are on your way to a conference. You are at the airport and want to buy a coffee and a donut. You make a request... You've been waiting for almost an hour now. Nobody takes a look at and you still need multiple approvals, so you ping Barbara in charge of approvals to get the ball rolling, she says she will take a look after a meeting she is currently attending because she wants to be careful with what she approves. Oh, Tom, her colleague asks you why don't you eat salad and orange juice, it's cheaper and faster. You have a quick call with Tom to explain why you want a coffee and donut. Awesome, you convinced Tom to approve in just under 20 minutes. Barbara is back, but she doesn't respond... She is MIA, she went for breakfast... Your plane is leaving, so you skip breakfast. You arrive, by the time you land Barbara approved your breakfast, but now you are in a new country and circumstances changed, so you update your request. The earlier approvals are now invalid. You go through the whole charade again... Pull requests assume you cannot trust your colleagues to make reasonable choices and you also don't trust your automated tests to catch anything insane (buying a 100k car for breakfast in the above example), so you have to gatekeep and slow down your team to make sure (?) that the code they commit is good.

wizofaus 4y ago
I don't assume my colleagues will always make "reasonable" choices and furthermore correctly express those choices into code any more than I will myself! In fact perhaps most of the issues I find in PRs are after reviewing my own ones (often it's silly things like accidentally including files/commits I shouldn't've have). Plus knowing someone else must've approved my PR stops me feeling quite so silly if it does end up breaking something :) The breakfast order analogy to me falls down because not being able to merge a PR into the mainline branch immediately is exceedingly rarely something that holds me up - there's always plenty of other stuff to do. And the time I spend reviewing PRs is valuable in its own right, even if I find nothing wrong (understanding the codebase better etc.). Sure the odd PR or two for a truly trivial change slows up the works a little but they're pretty rare and a it's a small price to pay. Having said all that, I'm genuinely interested in what studies might have been done to genuinely guage the effectiveness of the PR/review process. I've certainly worked on some (open source) projects where it clearly was a major drag on productivity, as very few people had approval rights (wherever I've worked professionally all devs have the same rights - single approval from any other dev is always sufficient).

SkyBelow 4y ago

Are those relationships really trusting then? Or is it an optimized way that catches fraud before it is too bad while reducing the increased expense of avoiding fraud? If you have to get all expenses approved before they are charged to the card, then it adds much more overhead and planning which decreases efficiency. The amount of fraud that happens by letting someone charge things and verifying it later ends up being a smaller expense than the amount of preplanning. Similar with interviews. The amount of time wasted by interviews of someone who doesn't pass a background check is a small cost than the cost of doing interviews of everyone before doing a background check (not just the cost of the background check, but having a longer interview process leading to missing out on candidates and more candidates getting part the way through the process and dropping out because another place gave them an offer). Imagine a father trying to "trust but verify" the paternity of their child. If there has to be verification, it will be taken as a lack of trust.