
Objections are goals - KentBeck
https://medium.com/@kentbeck_7670/objections-are-goals-9c9c2f27069
======
gfs78
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.

~~~
sanderjd
I have a new baby. There is a metric ton of guesswork involved in figuring out
what's going on with her health and well-being at any moment. The
pediatricians have better more targeted hypotheses and ideas for things to try
than us or our books or the internet, but I would _not_ call what they're
doing empirical in the sense you're using it. I honestly don't find it very
dissimilar to the type of iterative hypothesis testing informed by past
experience we do when building software. I think a similar thing is true for
most (but perhaps not all) of the "serious professions" you're thinking of.

~~~
gfs78
But this is a problem of magnitude. What would you think of your baby's
pediatrician if he/she starting pushing his/her unproven ideas as good
practices that should be followed by the medical community and writing about
pushing against the objections when someone objects them?

~~~
sanderjd
This is totally how it works! There are also people trying to apply more
empirical rigor, and presumably (or hopefully), once that's available, people
switch to it. What I'm saying is that we aren't the only field that uses
experience-based best practices as a way to get things done without making
perfect the enemy of good.

~~~
gfs78
Can you point me to a blog where a well know surgeon pushes the medical
community to use some novel techniques he devised and supposedly uses but that
have not been peer reviewed at least once?

------
md224
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
I'm very confident my tests would be very simple under this system.

~~~
antognini
I'm confident the Volkswagen unit test system would become very popular:
[https://github.com/auchenberg/volkswagen](https://github.com/auchenberg/volkswagen)

------
mlthoughts2018
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
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
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
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
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.

------
pjc50
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
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.

------
slavik81
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.

~~~
asplake
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)

------
iainmerrick
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.

------
beat
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
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
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
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.

~~~
beat
No one wants to be cheated. _Everyone_ wants to be sold to. That's because
everyone has problems they can't solve on their own.

"I don't want to be sold to, because I think I'm being cheated" becomes "If
I'm not being cheated, then selling to me is okay". Or to put it more
abstractly, "Selling bad because yuck" becomes "If yum, then selling good".

It comes back to the win-win, to mutually beneficial relationships. I disagree
that there is "zero structural incentive" to consider the needs of the
customer. In most cases, there's plenty of structural incentive. If your
business depends on repeat customers, not considering their needs costs you
their business. If your business depends on references and reputation, then
not considering your customer's needs costs both the current customer and
future customers.

------
myWindoonn
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.

