What Lurks in the Shadows? What Hides in the Light?

(continued from a story that starts here).

No Expectations

Having no expectations is better than having low expectations.

Low expectations are a way of setting yourself up to lose but rationalize that loss as a win: Either you were wrong, which sucks, or you were right, which also sucks.

No expectations, on the other hand, comes with a decided benefit: It's easier to react to unexpected outcomes because all outcomes are unexpected.

It may seem counterintuitive but turns out there's a lot to be gained from not creating an emotional investment in some prediction which, for all intents and purposes, was selected at random.

Does It Matter if You Mock?

Part of me thinks this is a continuation of this post.

I love mocking and experience none of the problems purported by people who seem to hate it. I also recently tried an experiment of writing tests with minimal (so far, no) mocking.

Guess what. I'm experiencing none of the problems purported by people (such as myself) who prefer to writing code with mocking.

What gives?

I've known that whether or not you use a mocking tool, like Moq, doesn't matter. Hand-rolling a mock or writing a test-double with widely-understood behavior works just as well as using a dynamic mocking tool.

Now, I'm beginning to think that whether or not you mock at all isn't really that impactful at all. I think that, when we measure an impact, what we are really measuring is a correlation with something else; something that does matter.

I think what we are measuring is the degree to which a test specifies a single behavior and is insulated from implementation details. I don't know why, but I'm guessing we blame our tools for the success we've experienced.

More on this as I continue to experiment.

Which Is Better: Big Tests or Little Tests?

As an organization starts to get more healthy, a focus is placed on building a meaningful test suite for their product or products. Should you write big tests that cover large swaths of your system or should you write little tests that give you precise, reliable feedback on individual parts?

Levels of Done

Previously, I pointed out that an engineer's definition of done should extend at least as far as their software being immediately deployable. That's a step in the right direction.

I think another step is to adopt this simple threshold of done:

Customers are deriving value from this behavior/story/feature.

You can't know you're done without attending to everything that needs to be done:

• Working software.
• Deployed in production.
• Released to customers.
• Validated with feedback.

Making the standard of done customers actually getting value measures all the things that matter without any risk of measuring something that doesn't.

If it's not self-evident, that's because customers actually getting value is the whole point of what we do...

Connectivity

Connecting with people is one of the hardest parts of helping people change how they do things. At least, it is for me.

I've identified three major reasons why you might be having trouble making a connection.

• They don't understand something.
• They fear something.
• They don't feel like they have power over something.

I'm sure there are more but these easily cover the majority of the resistance I meet. All three cases demand, for me, the same approach. Try to turn it around and make yourself the person who can help the person you are trying to help the way that they perceive help.

If they don't understand something, explore it with them. If they are afraid of something, face it with them. If they feel powerless over something, help them reconcile that feeling either by creating power or banishing responsibility.

Helping someone with the problem that they can see makes you their friend. Do it a few times and some of them will start to come to you to help them find the problems you can't see.

Magic++