8 ms·

Objections are goals

67 points by KentBeck 8y ago

mlthoughts2018 8y ago
I love this post, even though it gives even more evidence that the original TCR proposal is unworkable in practice. Namely, because all the bullet points at the bottom define different conditions that all have to be satisfied for TCR to be workable (and many more are omitted), you end up needing your unit test situation to be the intersection of a huge number of special cases that are almost never true in practice. You need (TCR doesn’t fragment commit history && tests are fast && confidence of test accuracy is high && ....). As you AND more things in there (and there are many more things to AND into the list of conditions necessary for TCR), the probability that it all applies to your working situation is going to drop rapidly except for some extremely isolated cases, and then one might question if it’s a good idea to adopt an extreme practice like TCR even when the heroic assumptions are satisfied, because it will mean mixed development practices in cases when the assumptions are / are not satisfied, and that inconsistency itself costs you, especially in a team setting. But the idea of reversing objections into statements of conditions is brilliant and I plan to practice thinking this way for sure!
- iainmerrick 8y ago
  I have the opposite reaction, I’m skeptical that the abstract “objections are goals” rule has significant value. But the concrete points about TCR are interesting. To address the objections about fast and trustworthy tests, you could limit its use to code that already has good tests. To address the version history objection, you could use “git commit --amend” to limit it to a single commit. So in some situations TCR may actually be usable (and in fact it’s not too far away from the process I often use! Frequent small commits with --amend)
  - mlthoughts2018 8y ago
    I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections of code where this could be tractable, except maybe for the process of using —amend in some rare cases where we wouldn’t want this history of those commits to be well separated for later purposes of bisecting to find regressions and bugs.
    - iainmerrick 8y ago
      This is not something I’d do on master, of course -- just on my own branch while working on stuff that will eventually become a single PR. I like to curate my commit(s) as I go, so that the final PR is easy to understand.
      - mlthoughts2018 8y ago
        Oh, I see. Yes, that is a very standard workflow. I also commonly address PR change requests in isolated commits as well, and then link back in the PR review page with something like “fixed in <commit hash>”, so that reviewers can see isolated commit changes fixing itemized requests, and also so that no review comments ever go without some explicit reply, either demonstrating the fix or explain why to not do it or table it for later. I guess in this sense, these items don’t have much to do with whether the big conjunction of conditions necessary for TCR are satisfied or not.
myWindoonn 8y ago
As the author admits, this isn't how logic works. Next time, use the Law of Contrapositives, which at least works when the Law of Excluded Middle is assumed. Suppose, for example, I object to cats; I might say, "If cats are in the house, then they will bring me mice as tribute." The contrapositive is, "If I am not being brought mice as tribute, then there are not cats in the house." Plural logic aside, this is pretty close! And now we can turn it into a goal: "If I want mice to exist in my house in non-dead states, then I should avoid cats." Now we've managed to refactor this into a goal: "I should get cats if I want fewer mice." I'm not sure if anything was gained from this exercise.
- deleted 8y ago
  [deleted]
iainmerrick 8y ago
Huh, I was bullish on “log-driven programming” (https://news.ycombinator.com/item?id=18165472 https://news.ycombinator.com/item?id=18165472) but this one strikes me as fairly obvious common sense. Is it any more than “try to respond to objections in a positive way”? If someone objects “I can’t use this TCR process because it will mess up version control history” it seems pretty clear that either TCR or version history will have to change.
slavik81 8y ago
The stated goals are not tied to any business value. This is putting the cart before the horse. TCR is a means to an end, not an end itself. Dale's essay on "Resistance as a Resource" is very good, but this is not how I would apply it.
- AstralStorm 8y ago
  Indeed, specifying alternatives and business impact is important. Sample comparable (not exclusive) technique would be design by contract with automatic verification. Likewise just not testing or limiting scope of tests or prioritizing tests differently for different modules. If you say that writing tests first is superior, you have to show why and how much. And preferably with not anecdotal evidence.
- asplake 8y ago
  Right. I designed a workshop/coaching game 15-minute FOTO (from obstacles to outcomes) [1] which does a similar “flip” from the negative to the positive; however by construction the input obstacles are with respect to some kind of objective. 4-Oh if you like - objective, obstacle, outcome, more outcomes. See also the classic coaching model GROW (Whitmore) [1] https://www.agendashift.com/15-minute-foto https://www.agendashift.com/15-minute-foto
pjc50 8y ago
Another way of looking at this is: all advice is conditional. It only works for people in certain setups and environments. People rarely specify their conditions, and may not even be aware of the other possibilities. So when offering advice or suggestions for process improvement, always try to add at least a couple of sentences describing the context at the front. It'll reduce the amount of objections you get.
- default-kramer 8y ago
  I think it goes a little deeper. Kent's original post (test && commit || revert) describes the strategy as just a curiosity. "I’m not arguing for “test && commit || revert” nor even describing its trade-offs. I’m saying it seems like it shouldn’t work at all, it does, and I hope you try it (if you’re the sort of person who just tries new programming workflows)." But the problem is Kent has probably never been on the wrong side of a CxO's dictum: "This company is using agile, starting now. Thank you." Programmers who have felt that pain want to make sure that a random musing from Kent Beck doesn't turn into a "movement" that ruins their work, so they try to shut down his idea hard. I don't blame them.
gfs78 8y ago
Then we complain about the sad state of the industry. What about empirically proving that something works instead? Like in serious professions. Imagine going to a doctor and the doctor saying: "The cure to your illness is eating a big warm turd every morning. I know you will object but turn it into a goal and you'll see its value". Better to use guru status and force people to use an objectionable idea (turn objections into goals) until they are invested in it and hence start to find value in it. This is Machiavellism 101. Once you get invested you get emotional and you will defend it, no matter if its shit. As another example go find the original scrum papers by Sutherland. Every claim is pulled from his rear end. No serious studies, metrics, none, whatsoever. Luckily this people does not promote brain surgery procedures and techniques.
- beat 8y ago
  I have empirically proven that empirically proving that things work is not sufficient to get past people's objections. I'm serious. The idea that you can logic your way around feelings simply doesn't work in practice.
  - gfs78 8y ago
    >I have empirically proven that empirically proving that things work is not sufficient to get past people's objections So? Proving that empirically proving something is not sufficient to get past people's objections does not prove that TCR or whatever is right. You first have to prove (but in a respected way) that say TCR works, and then you can discuss the objections.
    - beat 8y ago
      You absolutely do not need to prove anything in order to get past people's objections to whatever it is you're trying to talk them into doing. Not only do you not need to prove that your plan is right or that it works, you can get people to agree to things that provably will not work! Humans are incredibly irrational. If you want to talk them into stuff, it's a lot more effective to appeal to their irrational feelings than to appeal to reason - even if you're trying to convince them to do the rational thing. Believing that reason trumps emotion in human decision-making is itself demonstrably irrational. (And yes, this means the people who think they're being reasonable are probably wrong.)
beat 8y ago
This is a terrific article. I've used some similar techniques to reduce negativity and reflexive opposition to change (mostly borrowed from sales techniques), but this logical formulation is very clear and easy to use.
- edw 8y ago
  And how do the people you do this to feel about it? The idea of enthusiastically applying sales techniques to interactions with one’s coworkers feels appalling. A group of colleagues is ideally a marketplace of ideas and, yes, one needs to sell ideas from time to time, but who wants to be sold to? People often oppose something but raise (being uncharitable here) spurious objections, either because they don’t want to share their true feelings — or don’t even know what their true feelings are. It’s worth getting to the bottom of these issues, and worth doing with a great deal of respect for other people’s feelings. If you’re dealing with an issue that is not emotionally contentious, if you’re trying together with a group to achieve a common goal, using this “objections are goals” approach can help bring a team together and encourage positivity in the face of obstacles. When applied where there is disagreement about the goal, people will feel bulldozed.
  - beat 8y ago
    Who wants to be sold to? Everyone. Everyone wants to be sold something. Because when someone sells you something, it means they have listened to your problem (and maybe helped you discover/understand it), and offered you a solution using resources you already have. Sales, done right, is one of the best parts of human social behavior. It's mutually beneficial, a win-win. Sales has a bad reputation due to bad actors, not due to sales itself. Smarmy behavior, dishonesty, and taking advantage of others is not inherently part of sales, and it's definitely not part of good sales. "Objections are goals" is a sales technique. Overcoming objections is Sales 101, and a big part of that is turning negatives into positives.
    - cirgue 8y ago
      No one wants to be sold to. Not a single person in the world. There's a reason used car salespeople are the universal object of derision: no one wants to interact with someone that wants something from them and is willing to obfuscate, misdirect, and even lie to get it. That is a fundamental to sales: the sales person is trying to maximize their returns, and in most cases there is zero structural incentive for them to take the interests of the other party into account. This isn't something that you can imagine away any more than you can imagine away incentives in other areas of human interaction. People recognize that immediately, even if they can't put their finger on why.
md224 8y ago
Paradigm: Death Based Development (DBD). If the tests fail, the software engineer who wrote the code is executed. Step 1: I can't do DBD because I don't want to die. Step 2: I can do DBD if I'm willing to die. Step 3: When I'm willing to accept death as a natural part of the software development cycle, I can do DBD. Nice, I like this.
- jsight 8y ago
  I'm very confident my tests would be very simple under this system.
  - antognini 8y ago
    I'm confident the Volkswagen unit test system would become very popular: https://github.com/auchenberg/volkswagen https://github.com/auchenberg/volkswagen
- seanhunter 8y ago
  Step 4: Since I'm going to die at some point anyway....
- coldtea 8y ago
  Stretched-a-proposal-to-absurdity-driven-refutation

67 points by KentBeck 8y ago

mlthoughts2018 8y ago

I love this post, even though it gives even more evidence that the original TCR proposal is unworkable in practice. Namely, because all the bullet points at the bottom define different conditions that all have to be satisfied for TCR to be workable (and many more are omitted), you end up needing your unit test situation to be the intersection of a huge number of special cases that are almost never true in practice. You need (TCR doesn’t fragment commit history && tests are fast && confidence of test accuracy is high && ....). As you AND more things in there (and there are many more things to AND into the list of conditions necessary for TCR), the probability that it all applies to your working situation is going to drop rapidly except for some extremely isolated cases, and then one might question if it’s a good idea to adopt an extreme practice like TCR even when the heroic assumptions are satisfied, because it will mean mixed development practices in cases when the assumptions are / are not satisfied, and that inconsistency itself costs you, especially in a team setting. But the idea of reversing objections into statements of conditions is brilliant and I plan to practice thinking this way for sure!

iainmerrick 8y ago
I have the opposite reaction, I’m skeptical that the abstract “objections are goals” rule has significant value. But the concrete points about TCR are interesting. To address the objections about fast and trustworthy tests, you could limit its use to code that already has good tests. To address the version history objection, you could use “git commit --amend” to limit it to a single commit. So in some situations TCR may actually be usable (and in fact it’s not too far away from the process I often use! Frequent small commits with --amend)
- mlthoughts2018 8y ago
  I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections of code where this could be tractable, except maybe for the process of using —amend in some rare cases where we wouldn’t want this history of those commits to be well separated for later purposes of bisecting to find regressions and bugs.
  - iainmerrick 8y ago
    This is not something I’d do on master, of course -- just on my own branch while working on stuff that will eventually become a single PR. I like to curate my commit(s) as I go, so that the final PR is easy to understand.
    - mlthoughts2018 8y ago
      Oh, I see. Yes, that is a very standard workflow. I also commonly address PR change requests in isolated commits as well, and then link back in the PR review page with something like “fixed in <commit hash>”, so that reviewers can see isolated commit changes fixing itemized requests, and also so that no review comments ever go without some explicit reply, either demonstrating the fix or explain why to not do it or table it for later. I guess in this sense, these items don’t have much to do with whether the big conjunction of conditions necessary for TCR are satisfied or not.

myWindoonn 8y ago

As the author admits, this isn't how logic works. Next time, use the Law of Contrapositives, which at least works when the Law of Excluded Middle is assumed. Suppose, for example, I object to cats; I might say, "If cats are in the house, then they will bring me mice as tribute." The contrapositive is, "If I am not being brought mice as tribute, then there are not cats in the house." Plural logic aside, this is pretty close! And now we can turn it into a goal: "If I want mice to exist in my house in non-dead states, then I should avoid cats." Now we've managed to refactor this into a goal: "I should get cats if I want fewer mice." I'm not sure if anything was gained from this exercise.

deleted 8y ago
[deleted]

iainmerrick 8y ago

Huh, I was bullish on “log-driven programming” (https://news.ycombinator.com/item?id=18165472 https://news.ycombinator.com/item?id=18165472) but this one strikes me as fairly obvious common sense. Is it any more than “try to respond to objections in a positive way”? If someone objects “I can’t use this TCR process because it will mess up version control history” it seems pretty clear that either TCR or version history will have to change.

slavik81 8y ago

The stated goals are not tied to any business value. This is putting the cart before the horse. TCR is a means to an end, not an end itself. Dale's essay on "Resistance as a Resource" is very good, but this is not how I would apply it.

AstralStorm 8y ago
Indeed, specifying alternatives and business impact is important. Sample comparable (not exclusive) technique would be design by contract with automatic verification. Likewise just not testing or limiting scope of tests or prioritizing tests differently for different modules. If you say that writing tests first is superior, you have to show why and how much. And preferably with not anecdotal evidence.
asplake 8y ago
Right. I designed a workshop/coaching game 15-minute FOTO (from obstacles to outcomes) [1] which does a similar “flip” from the negative to the positive; however by construction the input obstacles are with respect to some kind of objective. 4-Oh if you like - objective, obstacle, outcome, more outcomes. See also the classic coaching model GROW (Whitmore) [1] https://www.agendashift.com/15-minute-foto https://www.agendashift.com/15-minute-foto

pjc50 8y ago

Another way of looking at this is: all advice is conditional. It only works for people in certain setups and environments. People rarely specify their conditions, and may not even be aware of the other possibilities. So when offering advice or suggestions for process improvement, always try to add at least a couple of sentences describing the context at the front. It'll reduce the amount of objections you get.

default-kramer 8y ago
I think it goes a little deeper. Kent's original post (test && commit || revert) describes the strategy as just a curiosity. "I’m not arguing for “test && commit || revert” nor even describing its trade-offs. I’m saying it seems like it shouldn’t work at all, it does, and I hope you try it (if you’re the sort of person who just tries new programming workflows)." But the problem is Kent has probably never been on the wrong side of a CxO's dictum: "This company is using agile, starting now. Thank you." Programmers who have felt that pain want to make sure that a random musing from Kent Beck doesn't turn into a "movement" that ruins their work, so they try to shut down his idea hard. I don't blame them.

gfs78 8y ago

Then we complain about the sad state of the industry. What about empirically proving that something works instead? Like in serious professions. Imagine going to a doctor and the doctor saying: "The cure to your illness is eating a big warm turd every morning. I know you will object but turn it into a goal and you'll see its value". Better to use guru status and force people to use an objectionable idea (turn objections into goals) until they are invested in it and hence start to find value in it. This is Machiavellism 101. Once you get invested you get emotional and you will defend it, no matter if its shit. As another example go find the original scrum papers by Sutherland. Every claim is pulled from his rear end. No serious studies, metrics, none, whatsoever. Luckily this people does not promote brain surgery procedures and techniques.

beat 8y ago
I have empirically proven that empirically proving that things work is not sufficient to get past people's objections. I'm serious. The idea that you can logic your way around feelings simply doesn't work in practice.
- gfs78 8y ago
  >I have empirically proven that empirically proving that things work is not sufficient to get past people's objections So? Proving that empirically proving something is not sufficient to get past people's objections does not prove that TCR or whatever is right. You first have to prove (but in a respected way) that say TCR works, and then you can discuss the objections.
  - beat 8y ago
    You absolutely do not need to prove anything in order to get past people's objections to whatever it is you're trying to talk them into doing. Not only do you not need to prove that your plan is right or that it works, you can get people to agree to things that provably will not work! Humans are incredibly irrational. If you want to talk them into stuff, it's a lot more effective to appeal to their irrational feelings than to appeal to reason - even if you're trying to convince them to do the rational thing. Believing that reason trumps emotion in human decision-making is itself demonstrably irrational. (And yes, this means the people who think they're being reasonable are probably wrong.)

beat 8y ago

This is a terrific article. I've used some similar techniques to reduce negativity and reflexive opposition to change (mostly borrowed from sales techniques), but this logical formulation is very clear and easy to use.

edw 8y ago
And how do the people you do this to feel about it? The idea of enthusiastically applying sales techniques to interactions with one’s coworkers feels appalling. A group of colleagues is ideally a marketplace of ideas and, yes, one needs to sell ideas from time to time, but who wants to be sold to? People often oppose something but raise (being uncharitable here) spurious objections, either because they don’t want to share their true feelings — or don’t even know what their true feelings are. It’s worth getting to the bottom of these issues, and worth doing with a great deal of respect for other people’s feelings. If you’re dealing with an issue that is not emotionally contentious, if you’re trying together with a group to achieve a common goal, using this “objections are goals” approach can help bring a team together and encourage positivity in the face of obstacles. When applied where there is disagreement about the goal, people will feel bulldozed.
- beat 8y ago
  Who wants to be sold to? Everyone. Everyone wants to be sold something. Because when someone sells you something, it means they have listened to your problem (and maybe helped you discover/understand it), and offered you a solution using resources you already have. Sales, done right, is one of the best parts of human social behavior. It's mutually beneficial, a win-win. Sales has a bad reputation due to bad actors, not due to sales itself. Smarmy behavior, dishonesty, and taking advantage of others is not inherently part of sales, and it's definitely not part of good sales. "Objections are goals" is a sales technique. Overcoming objections is Sales 101, and a big part of that is turning negatives into positives.
  - cirgue 8y ago
    No one wants to be sold to. Not a single person in the world. There's a reason used car salespeople are the universal object of derision: no one wants to interact with someone that wants something from them and is willing to obfuscate, misdirect, and even lie to get it. That is a fundamental to sales: the sales person is trying to maximize their returns, and in most cases there is zero structural incentive for them to take the interests of the other party into account. This isn't something that you can imagine away any more than you can imagine away incentives in other areas of human interaction. People recognize that immediately, even if they can't put their finger on why.

md224 8y ago

Paradigm: Death Based Development (DBD). If the tests fail, the software engineer who wrote the code is executed. Step 1: I can't do DBD because I don't want to die. Step 2: I can do DBD if I'm willing to die. Step 3: When I'm willing to accept death as a natural part of the software development cycle, I can do DBD. Nice, I like this.

jsight 8y ago
I'm very confident my tests would be very simple under this system.
- antognini 8y ago
  I'm confident the Volkswagen unit test system would become very popular: https://github.com/auchenberg/volkswagen https://github.com/auchenberg/volkswagen
seanhunter 8y ago
Step 4: Since I'm going to die at some point anyway....
coldtea 8y ago
Stretched-a-proposal-to-absurdity-driven-refutation