Summary

LinkedIn is full of strong opinions, weakly articulated. You don’t have to succumb to the temptation of yelling back about how wrong people are. You can break the cycle. Here is an example of how to do exactly that.

[I]f an application meets expectations and passes all external tests (functional and quality), should one care what’s inside? Development would consist of coming up with those tests: TDD

— Ken Pugh, in a comment on LinkedIn

I love comments such as these, because even though they are short, they act as a rich source of practice in various aspects of what I affectionately call “Playing Well With Others”. Analyzing comments such as these along with my immediate response to them helps me both understand and more-effectively use the various principles that form the basis of how I Play Well (at least Better) With Others.

TL;DR

Let me list the ideas, principles, guidelines, and practices I used to think about this comment:

The Law of Generous Interpretation
The powerful question template “What would have to be true for me to…?”
The Satir Interaction Model, also known as The Ingredients of An Interaction, notably the Interpretation part
Betteridge’s Law of Headlines
The risks of Best Practices thinking
The risks associated with the word “should”
Transforming Survival Rules Into Guides
Bringing assumptions to the surface in order to challenge them

That’s a lot! It’s a lot to do, to remember, to learn. I didn’t learn it all at once and I needed years to practise it all confidently and effectively. Would you like help learning and practising? because I know a guy.

Back To the Comment

Let me analyze the comment for a moment:

It seems like a rhetorical question, so I can interpret it as a statement, and using Betteridge’s Law, the answer is probably “no”.
It tries to identify a simple rule to govern complex behavior. Some folks would interpret this as a firm rule that one must always follow; others would interpret this as a guideline that one ought to keep in mind, but freely break.
It seems to promote a Best Practice, which always makes me nervous.
The word “should” raises many alarms.
The indirect statement “One should never care…” almost always stands in for the much more personal statement “I would rather never care…”.

That’s a lot for just a short comment!

Based on my analysis, the statement seems more like this:

“If an application meets expectations and passes all external tests, both functional and quality, then I would rather never care about what’s inside. I would focus instead on coming up with those tests, which I do when I practise TDD.”

This starts to sound more like a statement I could easily agree with, rather than a statement that I would quickly and easily tear apart. That sounds like progress to me towards Playing Well With Others.

The Statement Itself

When someone proposes an absolute rule, I tend to ask about the situations in which I would break the rule. When someone proposes an absolute rule with assumptions, I tend to challenge the assumptions or, at least, ask what would make those assumptions false. Let me try that here.

“An application meets expectations and passes all external tests, both functional and quality.”

I mean… it could happen. I guess it sometimes happens. Whose expectations? The “people who matter”, I suppose, whoever they are in the organization where we might apply this rule.

I get nervous when folks present these as binary assumptions/outcomes, but I can usually safely interpret that as shorthand for something closer to reality:

“An application meets the expectations of the people who matter well enough for their purposes and passes all external tests, both functional and quality.”

I note that the second part of this assumption contains evidence of the first part: I imagine that those tests include tests that encode some of the expectations of the people who matter. I feel confident that there are some Programmer Tests in there, too. Let me tweak the comment to make this relationship clearer.

“An application meets the expectations of the people who matter well enough for their purposes, as evidenced by passing all external tests, both functional and quality.”

I like that. Now: when faced with such an application, when would I care about what’s inside?

A Magic Question

What would have to be true for me to care about what’s inside an application that meets the expectations of the people who matter well enough for their purposes, as evidenced by passing all external tests, both functional and quality?

I don’t understand the tests well enough.
Even if I understand individual tests well enough, I don’t understand well enough how the tests work together to describe the system so that I can build a workable mental model of it.
I don’t have enough confidence in the tests being exhaustive enough to specify a system that does what we (the entire project community, customer base, and user base) need it to do.
I’m curious about what’s inside.
I want to build a similar application.
I want to extract reusable/recombinable components from it.
It’s often easier to build the system than to specify it with examples.
It is theoretically impossible to specify everything I care about a system from a combination of example-based tests and property-based tests.

I don’t consider this list complete, but I only thought about it for a few minutes. This provides enough to continue.

I judge some of these reasons as arbitrary and personal, such as my curiosity. I judge some of them as perhaps begging the question. For example, wanting to build a similar application: if I can regenerate this application from its tests, then presumably I also have the tools to generate a new application from similar tests. I judge some of these reasons as true, but useless. For example, it’s theoretically impossible to specify a system completely through tests, but we can usually get close enough to drive the risk down far enough for our purposes. None of this makes these reasons bad or pointless, but it merely reminds us that these reasons are not enough on their own to answer a clear “yes” or “no” to Ken’s opinion.

The question “What would have to be true (for me to behave (like that))?” engages my creativity to look for unspoken assumptions about the context, so that I can speak them, pay attention to them, and not become blindsided by being wrong about them. I find this question particularly powerful as a result.

For example: sometimes I’m just curious about what’s inside. I feel better when I retain the option to look and the skill to at least try to understand. Why not? I mean… you could pay me not to ask, but you don’t have enough money to make me not wonder.

The Claim Behind the Claim

Roughly speaking, I think Ken is claiming something like this:

“If you practise TDD, then you have the option to stop caring about what’s inside the application, as long as it passes all its tests and you have written tests that specify everything that the project community cares about.”

I’m taking liberties now, so I might have missed something important. Let me know. I tried to paraphrase and infer faithfully, interpreting generously.

Even in this form, I can’t quite agree, and for one key reason: it’s not theoretically possible to specify everything that the project community cares about through tests. We have been thinking about this for decades now: if we have tests, can we simply throw the production code away and rewrite it from scratch? Is this possible even in principle?

No.

We could get arbitrarily close, but then we would have another problem: eventually it would become “too expensive” to write those tests, even when we knew exactly what to write. I see two possibilities:

It would not be worth the effort, even if we did it perfectly correctly, or

It would become at least as difficult as writing the code. Getting the tests wrong would become as likely getting the production code wrong.

We would then need something like TDD to help us write the tests. The tests would become a new kind of production code, and we would end up back where we are now.

And all that ignores the fact that (some, many!) programmers (still) like to program (even though the industry seems to be trying very hard to stamp that out of them). Many of them would want to look inside; they would be curious.

Why Go Through All This?!

…over a LinkedIn comment? Rly?

Rly.

This feels so much better than merely telling Ken that he’s wrong in public. For twelve reasons, maybe fifteen.

I mean, what he wrote is wrong on its face, but there is true and helpful content in there. I prefer to focus on that part. Doing this makes me feel a lot better and makes me a lot more enjoyable to work with and to be around.

That’s my gift to you.