636.692.1426
fritz@archdevops.com

Why Do We Avoid Pain?

DEVOPS IS MORE THAN JUST DELIVERING SOFTWARE.

Why Do We Avoid Pain?

Owie 🙁

I’ve been thinking a lot about pain lately.

The other day our four year old came in and had a sore finger.

“Daddy!” she yelled as she burst into the office. “Karisa (the two year old) slammed my finger in the door it’s really owie!” I inspected it while she danced around. It was a little scuffed but it was fine. I’m sure it DID hurt. I’ve slammed my fingers in doors before.

After she calmed down a little, I said: your finger’s fine and you’re going to be ok. But did you know that pain is a good thing?

*sniffle* “No,” she said.

I said, “It’s true. Pain is a gift that God gives us. It lets us know that there’s a problem and also where the problem is.”

“Can you imagine,” I continued, “what it would be like if we couldn’t feel any pain? We’d still get cuts and bruises but we wouldn’t be able to feel them. We would be hurting our bodies all the time and not even realize that. That would be bad wouldn’t it?”

She nodded.

“I’m glad your finger isn’t hurt too bad but you’ll be fine. I love you a whole bunch.” Then I gave her a hug and sent her out to play.

When I was a kid, society only taught that it’s not “grown up” to cry about physical pain. “Quit acting like a baby,” was the theme.

But I’ve realized that that concept–don’t cry about pain–is really an oversimplification. I think we convince ourselves that pain of any kind is bad, and so we react emotionally to it.

I think too that human nature is such that we tend to avoid pain. Or turn it off with painkillers.

That’s a pretty big problem. And it started by us thinking that pain is bad when it’s not.

Pain isn’t bad. It’s actually good. But deeper than that, it’s just information.

Let me explain a bit how that pivots to talk about business, software testing and metrics.

Hey you made it this far! Must be something you like 🙂 Click below to subscribe to updates.

Subscribe to Updates

Business Owies 🙁

There’s such a thing as Business Pain. There’s such a thing as being numb to that pain. And there’s such a thing as not having pain receptors.

The disease of leprosy is often thought of as solely a skin disease. It’s actually a lot deeper than that. The nerve endings themselves are affected so that infected people can’t really feel any pain.

The result is, they end up losing fingers and toes because they can’t feel the damage they’re causing in everyday life. They can’t feel that something nicked them, or that a cut got infected, or can’t sense that throbbing saying something needs to be looked at, fast.

There’s no pain.

A lot of businesses operate the same way. They have “business leprosy”.

In particular, software companies, testing teams, can be affected by a type of “leprosy” that that prevents them from feeling the pain that they need to feel. They’re lacking the data (pain) to know what they should or shouldn’t do next.

And isn’t that terrible? When it’s worded that way, and when we put pain in the light of just being information, it removes the scariness from it.

Pain, business pain, is so valuable to us.

And yet so many companies work to deaden (not remove) the pain.

Sure, if you address what’s causing the pain, and actually fix the problem, the pain goes away. But masking it with painkillers only addresses the symptom, not the cause.

There are some particular places in test automation where I see pain being mismanaged.

Test Automation Owies 🙁

There are so many places where automation gets big and unwieldy, or hard to use by a large number of people. Most don’t realize, these are types of pain. It’s pain that we often overlook or don’t feel, and so we stick clunky workarounds in there to keep going.

(I know because I’ve done it too. So I’m not sitting up here on an ivory tower casting judgment.)

But the way we handle it doesn’t fix the problem, because we don’t know about the problem.

We lack the pain receptors to feel what’s wrong.

So that’s why we’ve started building them into our automation. Automation that feels pain. Fancy that. 

See, there are a million ways to get off track in the test automation craft. A lot of them have to do with not keeping the solution easy to use, maintain or extend. And complexity has a lot to with why solutions get rickety.

So here’s some of what we do:

  • Count the number of tests you have, by type: UI tests are a great use case for this pain receptor. These are long running, often complicated tests. If we have hundreds? That’s a problem. There’s a good chance that this high number of tests is trying to make up for a lack of integration or unit testing. So I have the automation go through and count the number of tests and throw a warning if it’s above some threshold.
  • Test complexity: Another pain receptor is to go through each test method and measure how long they are. This is a great indicator of complexity. Even if a test is really granular, if it has dozens (or God help us: hundreds?) of steps, it indicates it’s trying to do way too much. It’s likely that people are extending a test to do a little more each time. Better to break the one test, which can fail only once, into multiple tests which can each find different bugs.
  • Code concentration: If most/all of the supporting code is in a handful of files (or worse, just one) then that can harm maintainability. It also hurts with usability since people are more likely to have to hunt around for something. Much better to throw a warning if more than a certain percentage of code is concentrated in one place.
  • Fail on too many warnings: And this is where things are enforced. It’s pretty easy to ignore warnings even when they’re shining in your face. Fail the test run immediately if more than N warnings were encountered.

These are just a few examples. There are more specific ones that we employ based on what stack we’re using. But these are some powerful ways to feel the pain we need to feel, to keep ourselves on the right path. 

Putting in “pain receptors” is one of the services we provide at Arch DevOps. We come in, do an assessment of your solution, identify ways to improve, and then either make the improvements ourselves (good option) or show your people how to do it (best option). 

Even if things are great with your automation, if you’ve got 15 minutes to talk, we’d love to get to know more about you and your goals for test automation. Grab a slot on our calendar here and let’s set something up.