Noel Wurst

What Rules? The Great Hustle of Exploratory Testing

The tournament will span for about 1 hour with each registrant competing as an individual throughout 3 different games requiring varying levels of skill, speed, and accuracy.

The line above is the rules, in their entirety, for a darts tournament that was held earlier this year in Boston, during our Go-to-Market-Kickoff (GTMKO) here at SmartBear. This event brings in SmartBears from all over the world to learn, inspire, and in my case this year—to fight like hell to win an employee darts tournament against all odds.

Those odds, to me, were very low. I hadn’t actually played darts in nearly 20 years, and I’d be competing against a large number of my far younger colleagues visiting from our office in Galway, Ireland.

When I received the rules above in my inbox, they looked familiar. They reminded me of the vague sets of requirements that lack critical details that software testers are often tasked with using to “assure” the quality of a piece of software. (Note: “assure” is in quotes because that’s not actually what testers do or should even say they can do. It’s a long story.)

Requirements, by their very nature, will always be incomplete. Exactly how incomplete is a bit subjective. Some testers may receive a set of requirements to test against and excitedly say, “Got it! I know exactly where to start and where to stop.” Others may sigh and wish, again, that they’d been invited to be a part of the requirements gathering process.

And there are other testers who, to some degree, welcome brief, vague requirements, because it just gives them more room to go exploring. Knowing that what they’ll likely find outside of the straight and narrow rules of the road will be far more intriguing and thought-provoking than what they find by trying to stay on it.

The insufficiency of rules and requirements

On the afternoon of the tournament, I pulled up the rules one last time to make sure I didn’t miss anything that would disqualify me or would lessen my chance of winning by me failing to note. Then, my English major/major grammar nerd brain went to work:

“The tournament will span for about an hour”
I have no clue what time the tournament will start or end.

“Each registrant will compete as an individual”
Makes sense.

“…Throughout 3 different games”
I really wish I knew what the games will be, but that’s okay. They’ll tell us at some point. Right?

“…Requiring varying levels of skill, speed, and accuracy”
Hold on. What? How could the tournament require “varying levels” of those three things to win? Will “poor or “low” levels of skill, speed, and accuracy be rewarded equally as those that are “great” or “high?” Maybe there’s a prize for the worst score? But how could low “speed” even be measured? Will someone get a prize for the fewest darts thrown? I’m slow! Maybe I’ll win!

A quick—but brief—loss of faith

As someone who is often unreasonably competitive, even in competitions that I have little to no faith in being able to win, I grew restless, and almost a little nauseous as we got closer to leaving for the tournament. It was being held at an upscale darts establishment called Flight Club which was a little over a half-mile from the hotel where we were all staying during GTMKO. Given that it was in the single digits outside that evening, many of us opted for the complimentary shuttle to avoid dying of frostbite if we were to walk. Some did walk and did not die of frostbite, but I’m sure I would’ve.

I believe it was the third time that the shuttle returned to our hotel that I was able to squeeze on board. By the time our van arrived, Flight Club was packed. Nearly every dartboard had large numbers of people already playing on them. Many bullseyes were hit, high-fives and chest bumps were doled out, and pint glasses were emptied.

If the competition had already started, I was definitely behind. By the time I grabbed a pint glass of my own, ate a couple of hors d’oeuvres, and found a lonely, open dartboard in the corner of the room, an hour had passed.

“Oh, well,” I thought. The night would still be a blast, and it felt kind of nice to not have to worry about trying to adhere to the tournament rules I couldn’t make sense of anyway. Plus, maybe I’d get that award for “lowest accuracy,” or “slowest pace of play,” like I still believed at the time might be a thing.

Screw the rules

My Irish colleague, Frank, made his way over at some point and we decided to play a match against each other. Much to my surprise, this Irish individual was not humiliatingly better at darts than I was. That’s not to say he wasn’t good; he was! But, so was I! As an eternal down-player and excuse-provider of my own actual talents and skills, I was shocked that I wasn’t terrible.

At some point during the impossibly loud evening, a Flight Club employee grabbed a microphone, and, while he tried his best to shout over the noise of hundreds of dart-flinging SmartBear employees, not much of what he said was understood by anyone, other than that the tournament was now starting. I, for a moment, thought about running up to him and asking where to sign up, how would scores be tabulated, which three games were we playing, and was there any way I could find out which of those, “Varying levels of skill, speed, and accuracy” would qualify for an award. I had no problem being vain enough to throw the competition by playing far worse than I was actually capable of if a prize of any actual monetary amount or bragging rights were on the line.

I also remembered how much fun I was having by not caring about the rules. I thought about how poor or insufficient software requirements are not only “the norm” for many testers, they’re the last thing that would keep any tester who loves their job from the thing they love most—simply testing.

So, Frank and I continued to play each other exactly as we had before the start of the tournament. He would win, and then I would win. I’d occasionally manage to win two straight, and then he would do the same. This went on for dozens of games. Eventually, some friends dropped by to join us for some group competitions, and while Frank and I played for different teams, we each continued to finish around first, second, or third place in each game.

Reality check

The competition died down at some point over in our little corner, and some from our group left to chat with others at the party. I felt a tap on my shoulder. It was the employee from earlier who’d announced the start of the tournament. Even with him standing right next to me, it was almost impossible to hear him.

“Just so you know, I’m about to announce the current leaders of the competition!” he said, excitedly.
“Oh, OK. Sounds…good. This is a really cool spot. Thanks for having us.”
“I just wanted to make sure you’ll be listening when I announce who’s currently leading.”
“Um, I’ll try? I really couldn’t hear you at all the last time you were on the mic, but that’s okay, go for it.”
“I’ll just show you now in case you can’t hear me.”

I had no idea why he was so insistent on me knowing this information earlier than everyone else. He then held up a cocktail napkin that had the top 5 highest scores at that point in the competition.

Frank and I were not only tied for first place, but we were also absolutely destroying every…other…player.

“There’s NO way that’s right. How in the world do we have that many points?” I asked.
“It IS right. You get three points for every first-place finish, two for second place, and one point for third. I just looked at the numbers. They’re right. Anyway, I’m going to go announce it to everyone else; just wanted to let you know first! Great job! Keep it up and you’ll win this thing!”

You know that scene in the movies that’s done so often, where someone gets some sort of life-changing news, and everything taking place around them goes silent and the camera dramatically zooms in on the person’s dumbstruck face?

That’s exactly what happened at that moment.

The entire bar went silent, a truly miraculous feat for a place that loud. I could barely make out the muffled, unintelligible shouts of the Flight Club employee, but I did see him emphatically pointed in our direction, I think I heard my name, and then I instantly snapped back to reality. I rushed to Frank.

“We’re WINNING. By…A LOT,” I said to Frank, not in disbelief, but in a fully coherent understanding of how that had happened.
“How’s that even remotely possible? We’re doing…okay…I would say, but there MUST be others here doing better than us. Some of these guys can really play.” Frank replied.
“It doesn’t matter. It’s based on everyone’s total number of first, second, and third-place finishes. That’s IT. You and I are the only ones who’ve been playing with only two people to a game for almost the entire night. It’s not that we’ve played ‘better’ than everyone else; it’s that we’ve probably played 10 times as many GAMES as everyone else.”

Don’t fall for “acceptance”

It suddenly made perfect sense to both of us. And so, we did what anyone with that information at that time would’ve done. We played as many games as humanly possible in the remaining time of the competition, and we continued to volley first and second-place finishes because those were the only places either of us could’ve finished. Even “last,” it turns out, was still worth two points.

And, at the end of the night, we finished with the exact same number of points, miles ahead of every other competitor.

Exploratory testers find themselves in these sorts of situations all the time. It’s not that they won’t play by the rules, it’s that they know there are entire worlds of possibilities and invaluable learnings outside of the rules. As the most curious and most-comfortable-amongst-unfamiliar-territory testers on your team, they have to be given the time to explore what others either won’t or would never think to.

Rules are important. In sports, breaking them often comes with some sort of justifiable repercussion or punishment. But merely following the rules will hardly get an athlete or team rewarded for doing so. Likewise, in software, acceptance criteria is also important. Just remember that meeting acceptance criteria merely makes you “adequate.”

Lots of companies are willing to be adequate, so let them. Explore what will make you exceptional. There may be a medal in it for you.

There’s no shortage of answers; what we need are more questions

There’s a great meme I recently came across, where a wall clock is (insert your own adjective here: intriguingly, maddeningly, hilariously) situated directly behind some sort of pole or support beam that blocks a number of numbers from view. And so, rather than move the clock to another location (because moving the beam seems like far more work, and work which might damage the structural integrity of the building) you can see that someone has painted the blocked numbers 8, 9, and 10 directly onto the beam that’s blocking them.

The meme’s humorous caption reads, “Bug fixes in production.” A play on the fact that when software bugs slip past the developers and testers, and a quick “fix” is needed, that fix may come across as insufficient, hasty, or sloppy. When this is done, the bug might be gone, but the damage to your reputation or brand can often remain.

When I saw this meme, I quickly grabbed a screenshot and threw it into our “Corkboard” Slack channel, a catch-all for random water-cooler-type discussions. I then asked what I hoped people would mistake for a “simple” question.

Did this fix the bug?

I gave people options of “Yes,” “No,” and a shrugging emoji to connote “I don’t know.”

The final results?

Yes – 2
No – 6
IDK – 3

I told people not to worry, that there were no “wrong” answers, but I was definitely hoping for more than 3 shrugs. Okay, I was actually hoping for all shrugs. I’m an optimist.

Why was my hope for all shrugs? Because we don’t even know what “the” bug is; how can we confidently determine if it was fixed?

A variety of comments that some left in response provided a wealth of insight into the types of opinions around problems, and their presumed solutions, that are made in the software world all the time. I picked out a handful that I believe could provide valuable food for thought when brought to light during design, development, testing, and even production at any software organization.

A: “No. The glare prevents me from seeing when it’s ‘5 until the top of the hour.”

I love this answer. It was the first one that came in, and only seconds after I shared the meme with my colleagues. Remember when your teachers would hand you a graded assignment and an answer (or, in my case, many answers) would simply be marked with an “X?” Or, maybe you would ask your parents to review your homework before you turned it in, and they’d say, “You might want to look again at #5.”

How many times did you stare at that answer and wonder what the determiner of its quality had found so wrong about it? Furthermore, weren’t you so proud of yourself for quickly finding that “bug” within your answer, and then excitedly making what you just knew was the correction it required, and then spinning it back around to your parents, only to have them say, “I didn’t mean that. Look again.” Crushed.

This is exactly what’s happened in the clock meme, and what happens frequently between those who find software bugs—whether they be customers or employees—and a lack of information or clarity shared with those who are expected to fix bugs.

My colleague’s issue with this clock was not the 8, 9, and 10 covered up by the pole. His primary issue was the glare that covered up what should’ve been a perfectly visible, unobstructed 11. Someone went through the time, effort, and sunk cost of all that painting, but to the customer, the bug remains.

A: “The most upsetting part is how wonky the clock is.”

By measure of tacked-on emojis, this was our most popular complaint and bug distinction amongst my colleagues. One replied with a scathing, “I cannot unsee this.” To these focus group “customers,” again, the issue was not the obstructed 8, 9, and 10. The bug is simply the fact that the clock still needs to be turned slightly to the left so that the 12 and 6 are straight up and down.

How costly would that bug fix be in comparison to the time and money that would’ve potentially been spent on the paint job? We actually can’t say for certain! This picture doesn’t give us a lot of info. Maybe the clock couldn’t just be turned. Perhaps the screw hole on the back of the clock is in the wrong place, and this is as straight as it will hang without some serious modifications, none of which the team has the tools for. Perhaps the clock is not operated by battery and is wired to the building’s electricity (this is very common in schools) and the clock has been bolted to the wall so that the wiring stays undisturbed. On the other side, perhaps this is in an art classroom, the paint was already in plentiful supply, and it took the art teacher not even two minutes to complete the paint job.

From “the cost of applying this fix vs. that fix,” to “we can apply this fix now…but this fix is going to have to go into the backlog,” to “which fix might break something else entirely,” there are a million discussions to be had and decisions to be made when it comes to determining what actions will improve quality and what won’t.

A: “We should also make all the small numbers much bigger to improve accessibility.”

This answer…hits a little too close to home. Anyone else? I can’t tell you the number of press releases, blogs, speaking sessions, etc. that I’ve written countless drafts of, and sought so much feedback on during development…only to be told by someone after it was published, “You know what would’ve been awesome? If you’d said…”

And, they were exactly right.

Furthermore, even if I’m able to incorporate their feedback so that missing component is there the next time someone reads or hears a piece that I’ve authored, there’s no recreating the original experience for those who received v1.

When should we discuss, determine, and build quality, accessibility, security, etc. into our products? Before we release them? Or, only after we’ve built, pushed to production, sold, and distributed our products to our customers? That way, they can then tell us, “I wish I’d have known the numbers were going to be this small. The wall this clock has to go on is so far from the students that nobody’s going to be able to read them. How long will it take to get my refund?”

We hear all the time how the mean-time-to-repair (MTTR) in pre-prod is exponentially cheaper than once software is in production. That will always be true, whether we’re talking about baking in quality, performance, scalability, security, and accessibility from the start, and not only after our customers have pointed out their absence.

A: “It’s a ‘workaround,’ but an unnecessary and unwanted one. I could tell the time anyway and it’s just made it apparent that you are aware that there is a bug and couldn’t be bothered to fix it properly. As a user, I’m also very bothered that the clock wasn’t at least straightened in the course of making the bodgy workaround and I’m left wondering what other sloppy shortcuts have been taken on quality.”

This is my favorite response of the bunch. I’ve always loved getting into heated discussions around, “Who should ‘own’ quality?” but my favorite debate is around a far more important question, “Who gets to define, or determine quality?” For anyone who would like to begin preparing your retorts, I am staunchly in the “Your customers,” camp.

Not the business, not management, not your developers, not testers, not analysts, nor anyone else who looks at what you’ve built, and who then establishes a score, ranking, or even just a general level of satisfaction, or a lack thereof with your products.

It’s your customers whose voices and opinions matter most. As my colleague stated here, your customers may not view your repair as a “fix” at all. It’s merely a workaround in their eyes, and a “bodgy” one (used in Australia to mean “worthless or inferior”) at that. This customer is not only not impressed with what you’re telling them is a “fix,” they’re even further bothered by the fact that you didn’t straighten the clock while you were up there painting that “unwanted” addition.

Did you tell them you couldn’t straighten it because the clock is bolted into the wall? Did you ask them if the paint job would fix the problem before you went to the trouble of slapping it on there? As they said, “I could tell the time anyway,” so who was this fix even for?

How many times has a bug made it into production, where the immediate directive in an organization is, “Just get some (fix, workaround, edit, statement) out there ASAP.” Many of you may have experienced this painful reality firsthand. As my colleague so brilliantly points out, while we might think we’ll win the customer over with how quickly we responded, that customer may think to themselves just as quickly, “As a user…I’m left wondering what other sloppy shortcuts have been taken on quality.”

How often do your customers provide you with feedback? More importantly, how often, and when do you ask them for it? And, maybe most importantly, what do you do with that feedback when you receive it?

Let’s all start asking more questions.

Endings: An Origin Story

On Thanksgiving morning of 1989, my functional-yet-split childhood household was presumably like most others for kids my age living in similar arrangements. I recall being quite happy to be on Thanksgiving break, but also somewhat dreading the drive to my grandmother’s for a day in uncomfortable, ill-fitting church clothes, and faking tolerance of unfamiliar, supposedly beloved family recipes. But where others who are my age today (no need to get into specifics) might not be able to recall too many other details from a Thanksgiving that long ago, I, regretfully, can.

I remember looking angrily at the clothes on my bed, almost cursing at them, as if they themselves had campaigned to my mother that they were the best choice for that particular day. I remember the phone ringing, and then my stepfather telling me to go see my mom in the bedroom. I remember asking, “What for?” like a total brat, and him then uncharacteristically angrily demanding that I go see her immediately.

And, then I remember being told that my dad was dead.
_

My dad, Steven Robert Wurst, born on February 19th, 1952, had a heart attack in his sleep during the pre-dawn hours of November 23rd, 1989. Five days before my 12th birthday.

The period of time between Thanksgiving Day and the date of my dad’s visitation was a complete blur. But the visitation still stands out today in strikingly vivid detail. 11 to 12-year-olds, contrary to their own beliefs, don’t actually know all that many people. My dad, at the age of 37, apparently knew everyone. I remember the visitation room being absolutely packed all night, and when I had to use the bathroom, I found the hallway just as crowded with folks waiting their turn to pay their respects.

I was so confused by the size of the crowd and how it seemed more appropriate for someone of a much larger status in life than I associated with my father. He was a collections agent at what always felt, to me, like a decaying office building when I visited. He drove an equally decaying, unassuming, old, grey Buick. He owned a tiny two-bedroom condo in Tucker, GA, a small uninteresting Atlanta suburb. He swam and played tennis not at a country club, but at his tiny neighborhood facilities, and he was the only person I’ve ever known to drink milk on ice, which the thought of still grosses me out to this day.

On the 4-ish days a month that I spent with him, it was usually just the two of us, unless there was some sort of family gathering for us to attend at his mother’s, my grandmother’s house. It was there that I would witness a far more captivating presence within him. I was always captivated by him, but that’s because I didn’t see him much, and loved him dearly. But at my grandmother’s, ground zero for any and all family functions, he would almost float on air amidst the inappropriate, vulgar, and mesmerizing chaos of 1980’s-era raucous family parties. I, always the lone child in attendance, would sit back in awe of the hullaballoo of cigarettes, cocktails, playing cards, and poker chips all continuously rising from, and then striking, the massive dining room table for hours on end.

I can remember my father holding court at these parties, telling the most animated stories amidst great clouds of smoke and an endless chorus of rocks glasses being emptied and quickly refilled. Great guffaws of laughter from the men in the crowd, sheiks of delight from the women, and a concerning, but oh-so-familiar raspy laugh from his mother followed every masterful closing line. I rarely understood these stories, outside of a guaranteed scaffolding of foul language, nor why they were so funny. But the house’s uproarious responses, and an occasional wink thrown my way from my father, always made it clear to me that these were true performances, and that he knew the response that would come at each of their conclusions.

My father is the only person I can recall ever being asked to get up and tell stories at these gatherings, and I can also recall many of them being the same stories as he’d told in previous gatherings. It didn’t matter. The family wanted to hear them again, and wanted to feel the way those stories always left them feeling.
_

On the night of the visitation, I would occasionally lean to the side to see if and when the line of acquaintances would ever end. For hours, I shook what felt like a thousand men’s hands and hugged what felt like a thousand women’s chests. These strangers, with tears in their eyes, and before making me promise to let them know if I ever needed anything (How would I do that? Who are you people?), would say some variation of:

“Your father was an amazing storyteller.”

Those two things are really all I remember anyone saying that evening. An offer to help, that I knew I would never take them up on, and a reminder that the best storyteller that they’d ever known was no more. I grew weary of hearing this over and over, and I found myself struggling more and more as the night wore on to respond with any politeness whatsoever. I’d said, “Thank you, really,” so many times, until it dawned on me that I wasn’t thankful at all, for any of this. It was like a switch flipped, and I suddenly realized how unfair all of this was. The last thing that I wanted to hear was how much anyone else was going to miss him. It wouldn’t be anywhere near how much I would miss him, and the never-ending line of friends and admirers were, unbeknownst to them, only painfully driving that point home deeper.
_

The night after his funeral, shortly after I’d gone to bed, I laid there looking at the ceiling, still in complete disbelief that he was gone. And then, there was a quick knock at the door. It opened, someone quickly rushed in, and then shut the door behind them.

It was my father.

I shot up, frozen, and convulsing in fear.

“Hey, buddy. I know, I know. This has to be really hard. I only have a second, so I need to let you know, I’m being made a star, okay? You’re gonna – “

“Wait! What are you talking about? Why are you here? How are you – “

“You have to listen. I know it’s hard, and I’m so sorry, but I only have a second. I’m okay. Okay? I’m okay, and you’re going to be okay, too, alright? I have to go, but I’m going to be a star, and you’re ALWAYS going to be able to find me in the sky, anytime you need me, alright? Do you understand?”

“I don’t understand at all! A star? What do you mean? How do you know? What if I — “

“Buddy, I have to go. You’re going to be okay! I promise. I love you so much, you’re always going to be able to find me, okay?”

Then he was gone. And, as should be expected, I began to scream my head off. It was hopefully the loudest that I, or anyone else for their sake, will ever scream. My mom came rushing into the room, and I tried to explain through continued screaming what had just transpired.

Years would pass, and I’d thankfully manage to not scream myself to sleep every night after that fateful evening. I’m truly blessed to be able to look into the sky on any night that the stars are even remotely visible, and quickly find my father. He’s right there, just below the left-most star in Orion’s belt. There have been hundreds of nights spanning the decades he’s been gone that I’ve walked outside and immediately felt him looking at me, long before I can see him careening across the heavens above.
_

I eventually moved away from my birthplace of Decatur, GA. Once during a return trip, nearly 20 years after my father’s death, I stopped in Golden Buddha, an Atlanta institution, to pick up dinner for my family. As I waited, I was startled to hear a voice much older than my own, questioningly call my name from behind me.

“Oh, my goodness. Noel?”

(Turning around, hesitatingly) “Yes?”

“I’m Tom. I was a good friend of your d—“

“I know.”

“Wow. I can’t believe this. How have you been?”

“Umm…good? I’ve got kids, and, yeah, good, I guess. You?”

“I’ve been good! Sure miss your dad, though. We all do. We always have.”

(Seriously fighting back just bursting into a complete mess) “Yeah. Me, too.”

Tom then, thankfully, changed the subject and talked about his son, Jeff, who I’d known well at a younger age, but had completely lost touch with. At some point, I can’t remember what prompted it, I found myself telling a story about who knows what. But, as I told it, I could look at Tom, see him smiling sincerely, but also tell that he wasn’t entirely concentrated on whatever I was saying. The moment I finished this far from memorable story, Tom chuckled, shook his head, and said:

“It’s like I’m standing here listening to Steve.”

(Silence from me)

“Do you know that your dad was the greatest storyteller that any of us ever knew? Hell, that anyone ever knew?”

“Um…I think I remember you and some other friends of his telling me that.”

“Some? I doubt it. I bet everyone told you that.”

“Maybe. I, umm…I don’t really remem-“

“Your dad was so special. I know you know that. And that you don’t need me or anyone else to confirm that. But, if you were ever in the room with him, and he started telling a story, you listened. Do you know what I mean? You had to have been around for some of those.”

“Yeah, I mean. I think I probably saw him do that from time to time.”

“Nothing made him happier than just holding a room completely captivated. I’m not kidding! While you were just talking, it was like I was standing here right in front of him again. God, I miss him so much. He loved YOU so much, I hope you know th—”

“Yeah, I can’t really talk about it, and I kinda need to go.”

“Yeah, me, too. I’m so glad to hear that you’re doing so well. I know he’s so proud of you. I hope you know th—”

“I do. I’ll tell my mom I ran into you. Tell Jeff I said ‘Hi.’ I gotta run.”
_

I started this story on February 17th, 2022, two days before my father would’ve turned 70 years old. In my mind, I had what I believed was a pretty solid beginning, some accompanying backstory/prequel-like material to provide some context, and was searching for a knockout-punch closing for when it was time to wrap everything up into a nice, neat bow. Those closings have become a bit of a signature move for me in my own storytelling, and I often find it impossible to not end each of my stories with one. My father did the same.

I’ve spent years hating the way my father’s story ended and have come up with all sorts of ways to blame him for ending it when he did. I’ve wasted just as many years trying to guarantee a different ending for myself, a better ending, one that wouldn’t traumatize my children the way the ending to my father’s story has tormented me.

Last night, after growing so angry at being unable to weave in a fitting ending to this story, I was called outside, where God then drew my eyes toward that left side of Orion’s belt, and asked,

“How could you possibly believe that THIS was the ending to his?”

Thanking a Storyteller: It’s not easy

I recently had the pleasure of delivering a one-hour keynote speech at SmartBear’s 2022 Go-to-Market Kickoff, and…it went really well! That is, outside of the migraine and near panic attack I suffered through immediately after it was over. While I’ve given what feels like a million 30-minute presentations and co-presented one-hour talks, this was my first one flying solo. Just me, and my story, and slides. When it was all said and done, before I even got off the stage, and after 100+ hours of preparation spread across three months, there was a sudden, jarring adrenaline dump. My brain just went into safe mode and basically told my vision, emotions, and overall sanity, “Yeah, ya done,” sending me dashing up to my hotel room for some dark silence I was in much more need of than a catered lunch.

When I returned to the event about an hour and a half later, and in far better shape, I was thankful for, and ego-boosted by, a number of very generous “Great job!” and “That was excellent!” sentiments from my awesome coworkers. But then came two other types of praise. One was probably given a dozen times, and don’t get me wrong! I know, especially based on the quality of the people who were giving it, that it was fully intended on being a compliment! It just…well, it’s complicated.

The other was expressed to me by a single person and left me feeling far more proud, appreciated, and seen than all the others combined.

A completely fine thing to say

Any variation of “Great job,” “That was excellent,” or “I really enjoyed that.” These are very nice things to say to a storyteller! (Or presenter, host, moderator, panelist, interviewer, etc.) I think I can safely speak for most storytellers in that when we’re in the process of telling a story, sometimes we can gauge the audience’s reactions and level of enjoyment, but sometimes we can’t. Maybe the lights are in our eyes and the audience is darkly lit. Maybe it’s on Zoom and people’s cameras are off, or their camera is at a poor angle or mounted to another monitor aimed at the side of their face. Maybe we’re pacing a stage, looking down at our feet to make sure we don’t step off the stage or trip on a cord. Maybe it’s the first talk of the day and everyone is half-awake, or maybe it’s the last talk of the day, and the audience is, again, half-awake.

We, as storytellers, for the most part, tell stories because we love doing it, but knowing that you love when we do it, too, is often a great motivator for us to keep wanting to tell more. Letting us know after the fact that you enjoyed a story/presentation/webinar (psst, they’re ALL stories) is a very nice thing to do, even if you think a million other people might’ve already told us that, go ahead and let us know, too. For all you know, your opinion might be the one we’re going to be the most excited to receive. 🙂

A…not as fine thing to say

I’m not going to try to speak for all, or even a majority, of the storytellers in the world because I’ve done zero research to confirm who else feels this way. But, there’s one expression of presumed praise (I know these people mean well!) that I, personally, “literally cannot” with. The dreaded “You make it look so easy!”

Storytelling—and I’m talking about the really good, left you shook, opened your mind, changed your mind, blew your mind, stories that made you feel like personally thanking the storyteller for their time—is anything but easy. It is 0% less of an art form, craft, or lifelong pursuit than any other skill or talent on the planet. I promise you. The world’s best stories, whether authored by anyone from Toni Morrison to David Sedaris, or presented on stage at a tech conference or Broadway, or shown in dazzling HD colors from Activision to Disney (Encanto FTW!), all of them went through countless combinations of drafts, copyedits, rewrites, dry runs, rehearsals, test screenings, table reads, beta tests, chopping blocks, and cutting room floors.

On top of that, for some, and no matter how much they enjoy doing it, nor how many years they’ve been doing it, storytelling can be exhausting. Mentally and physically.

If, the next time you’re watching a story be told, and you truly are sitting there thinking, “They make this look so easy!” and you find yourself reeeaally wanting to say that to the person afterward, would you be willing to try out the suggestion below?

A wonderful thing to say

Whether you’re able to speak to a storyteller in person after their speech, or presentation, or performance, or you’re shooting them a quick note on Slack, or social media, at least think about being one of the few who will also say something like, “That had to have been a ton of work,” or, “You clearly spent a lot of time creating that.” I think you might even be able to get away with “You make it look so easy!” if you immediately follow it up with “…but I know that’s because of how much work you put into it.”

I’m in no way a student or scholar of human behavior or sociological wiring. But, doesn’t it feel like it’s almost second nature for us to, unintentionally, write off or discount other people’s impressive feats and accomplishments by attaching that “they make it look so easy,” label to them? We do this or hear this being done to athletes all the time. Describing Steph Curry’s jump shot as “effortless,” when we know that he’s been training his whole life to be as good as he is and that he continues to train to get even better! Or when an announcer says, “It’s like she’s just having fun out there!” about Chloe Kim as she dominates yet another snowboard run. She probably is having fun. How many globally recognized, generational athletes hate their sport(s)? But, to convey that they’re “just” having fun, and not, you know, also at work, work that includes things like “not dying in a horrific accident,” all while being watched and judged by millions across the world, is disingenuous and completely dismissive of the time and effort you know they’ve put in and which are worthy of recognition.

I love telling great stories, it’s in my blood (more on that in the next blog!), but I love the work that goes into them just as much. One truly doesn’t happen without the other, and that’s thanks to you, and every other audience I’ve ever had. The next time you watch and/or hear a great story and you get the chance to speak with or write to the presenter afterward, remember that they didn’t just give you the time they held the mic, faced the camera, or walked the stage. They felt like you were worth a lot more of their time than that one moment that the two of you and their story spent together.

Don’t ignore the happy path; know that it was never there

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I
I took the one less traveled by,
And that has made all the difference.

In “The Road Not Taken,” poet Robert Frost describes an interesting scenario. Frost’s poem paints a beautiful picture of someone who stood before “two roads diverged in a yellow wood,” and who felt “sorry I could not travel both.” And, as the closing stanza above tells us, they eventually “took the one less traveled by, And that has made all the difference.” We’re not told what that difference was, and if the traveler chose the “right” or “wrong” path. We only know that the decision was important enough that they see themselves still telling this story “ages and ages” into the future.

This is one of my favorite poems, for many reasons, and I recently came to realize how similar it is to the types of decisions we make every day in the software industry. We, as software testers, developers, architects, and UX designers, regularly find ourselves at metaphoric forks in the road, wandering through colorful aging woods of internal and external hierarchies, and, like the traveler in Frost’s poem, we have important decisions to make. Will we be drawn to the familiarity and presumed comfort of the paths that were chosen by the most before us? Or will we venture down the other? The one that looks like it has, perhaps, never, been chosen, and therefore has a far less predictable endpoint?

Many organizations feel forced to take, and then re-take, the popular, proven, recognizable paths that they, and the companies they’re competing with or aspire to be have taken so many times before. This obligation is often due to the sink or swim nature of our industry and that we can find ourselves constantly teetering between feast-or-famine. “The way we’ve always done it” comes with a natural boost of greater predictability, something every organization is looking for these days, and which individual contributors are often rewarded handsomely for providing.

And, thus, the “happy path” was born.

“A happy path? Sign me up!” you might say to yourself, and, at first glance, why wouldn’t you? Imagine yourself standing before two roads. One of them is well lit, maybe you’ve even taken it before. You know how long it will take to reach the end, maybe you can even see the end from where you’re standing, and you’re completely confident in what will be waiting for you when you get there. Let’s pretend there’s even a cute sign at the trailhead telling you that this is the happy path. The other road…is different in every conceivable way. It’s overgrown, poorly lit, and you can’t see anything past a sharp turn only a few steps in, leaving you with little confidence how long it will take you to walk it, if anyone has ever walked it before you, and if they, or you, will even reach the end.

It’s only natural that more people would choose the sign-described happy path in the scenario above, and in the real world of the software industry, as well. We can’t just go wandering off down shadowy paths in the woods with no estimated time we’ll return. After all, we have places to be and deadlines to make. We owe people things, like new features, bug reports, KPIs, and slide decks.

There’s just one problem. There is no happy path. Not in the woods, and not in your apps. It’s all in your head.

Wait…what?

(Scene from The Matrix, Warner Bros. Pictures)

In The Matrix, Keanu Reeves’ character, Neo, is perplexed when a young child sitting across from him is able to bend a metal spoon in his hand using only his mind. As Neo tries his hardest to bend the spoon in his hand, using only his mind, the child tells him:

“Do not try to bend the spoon — that’s impossible. Instead, only try to realize the truth: there is no spoon.”

This line was pretty deep stuff back in 1999. We all sat there, like Neo, pretty confused, and asking ourselves, “How is there not a spoon? It’s…right there in his hand.” The same can be said for your application. You certainly can design, build, and test a path that takes the user where you want them to end up, and you should! But there’s a very important reason that shouldn’t be your sole focus. There is no sole focus of your users. There is no single path that all users will take or will even want to take. No matter how clearly marked you try to make your path, you cannot guarantee they’ll see it. No matter how efficiently one path takes your users from Point A to Point B, you cannot guarantee your users will prefer it. And no matter how much effort you put into hiding the presence or potential appeal of other paths, you cannot prevent your users from finding something attractive about them, especially those who are looking for a completely different outcome (maybe even something nefarious) than the one you’re hoping they achieve or are able to provide.

It’s only once Neo accepts that there is no singular spoon in his hand—perhaps even that the concept of “a spoon that will only ever be used by its creators for its originally intended purposes is also a myth”—that he observes the object, and his reflection inside it, in an entirely different light.

Visibility ≠ Predictability

The trusty iceberg image above has made its way into roughly 9 million software industry slide decks and blogs over the years. In this story, the small percentage of ice above water represents a (not the) happy path of our application. It’s the part of our app that we’re most familiar with, most easily measured, what was thoroughly tested, and will almost certainly be the most trodden upon. The rest…not so much. It’s dark, it’s surrounded by freezing water, it’s much harder to access or traverse, and it’s far less likely to ever be seen, or measured, or tested. But, wait. Is it possible that those descriptions are simply your opinions, and not those of your users? You might find what lies below the surface “dark,” “freezing,” and “difficult to access,” but do they? And are we talking about the users you have today or your potential future users?

Unfortunately, using the famous image above as a metaphor for comparing software applications to icebergs is pretty disingenuous. Are we gifted this much visibility into our applications on Day One? Never. A much more accurate representation of what we know about our applications, and how we think about users are interacting with them is below.

When compared to the previous image, how much of this iceberg is visible? Much less, right? What a shame! But, how much of this iceberg is observable? Just as much as what’s shown in the last image. For the dose of “frigid waters reality,” how many software organizations ignore observability, and focus only on what’s more easily visible, and what they believe is more easily visible or sensibly desirable by their users? I believe it’s far too many.

You can see why visibility is so appealing. It’s inherently predictable, and it requires such little effort. It’s like the aforementioned fabled happy path. “I can see this happening, right now. It’s happening over and over, and therefore, I can predict, to a fairly certain degree, what will happen next.” But observability never goes away. It’s always right there, too. It requires much more effort, but it results in greater visibility, and then, you guessed it, predictability, the thing we know the rest of the business is looking for.

We have users/seals!
We designed this iceberg to facilitate and encourage the lounging that we know seals like to do, and they look pretty content. Go us!
One appears to be either having a drink of water or they might be about to leave. We should keep our eye on that one to see if/when they return, how long it takes them to return, and if others behave similarly.
We can see some smaller chunks of ice floating around ours, and they look a little small. I don’t think we have to worry about our uses/seals abandoning our app/iceberg for those others.

Far-too-early-prediction: Because we built an iceberg for seals to enjoy, and they’re currently enjoying it, we predict that seals will continue to enjoy our iceberg.

Based on this small amount of visibility, can we actually predict the above with any real confidence at all? We can’t, because we haven’t observed nearly enough. What isn’t currently visible, doesn’t mean it isn’t observable.

What is observable, and would lend to much greater predictability?

Are there other icebergs with far more seals lounging on them? Why is that? What features do they have?
Are seals easily accessing our iceberg from where we assumed they would, or are they experiencing any difficulties doing so?
What percentage of our iceberg lies below the surface of the water? Enough to keep our seals trusting that the portion they lay on will remain stable and intact?
What impact are the air and water temperature playing on the state of our iceberg?
Are fish, crustaceans, and other seal prey available in the waters surrounding our iceberg?
Are pollutants or seal predators in the area?
Should we be looking at icebergs for walruses? Penguins? Eco-tours? Research labs?

And, perhaps most importantly:

How often are we observing and measuring these things, and how quickly can we design, build, test, and deploy changes when warranted?

Happiness is Subjective…and in a constant state of flux

When we think about the definition of words, and why we have them, the actual definition of the word “definition” sums it up pretty nicely:

“the act of defining, or of making something definite, distinct, or clear”

Which is why I find the outcome of reading Wikipedia’s definition of “happy path testing” so humorous:

“Happy path testing is a well-defined test case using known input, which executes without exception and produces an expected output.”

Our users’ input is never always “known.”

There is no permanent state of executions “without exception.”

“Expected outputs” fail to be actual outputs all the time.

And any test cases written, requirements gathered, and UX feedback collected were all conducted at a single point in time—time that changes just as frequently as those test cases, requirements, feedback, and outcomes. And, what I, personally, find most “definite, distinct, or clear,” is that the mythical happy path, no matter how well-marked or defined it may be, will always offer less visibility than the entire woods that surround it.

In closing, the greatest level of predictability can be found not in what is immediately obvious, but by allowing yourself, and encouraging others, to explore an entire world of opportunities and potential dangers outside of what may be clearly visible today.

As the boy says to Neo once he begins to accept that perhaps there is no spoon:

“Then you’ll see that it is not the spoon that bends, it is only yourself.”

And that will make all the difference for you, traveler.