The Importance of Words

"Vision from Marvel requesting elaboration"

Communication is always a challenge. Things can always get lost in interpretation, and sometimes I find it helpful to look at where the words and phrases came from, and how we use them to provide clarity. Sometimes, though, I find people are just a bit careless with the language they use, and all sorts of problems can arise from that.

In the software industry, though, I find we are particularly careless with our language in general. There’s certain words and phrases that we’re pretty used to hearing thrown around in this industry, but our understanding of them can vary from person to person, and often times aren’t quite helpful. The ambiguity this creates seems to confirm biases for some and furthers agendas that also aren’t so helpful.

You might read that and say:

“Yes I see that all the time. But I’m always careful with the language I use.”

But I’d like to challenge that. Because I too thought of myself as exceptionally careful with the words I used. But I’ve learned that I’ve been just as guilty as most.

“Guilty” here is a good example. It implies I’ve done something wrong, and am responsible for it. But it also implies I should feel bad about having done it, and possibly should be punished.

Should I be punished for that carelessness? Maybe. Maybe not. I’d argue, though, that I already have.

Do I feel guilty? To some degree, yes.

Is this feeling diminished because other people are doing it as well? Again, yes, to an extent.

But does the carelessness of others give me license to continue being careless I myself? Absolutely not. It means I have to be extra careful.

Much of the language in our industry has taken on a life of its own, as language tends to do. I don’t believe we can do anything to stop this, but I also don’t believe we shouldn’t do anything about it.

These words and phrases came about to help us talk about important things, but have since drifted so far away from their original intent that they don’t offer us much value anymore. In fact, the way much of that language is used now, I would argue is quite harmful, often because much of it is used to hide what it originally meant to reveal. Even with a common understanding of these sometimes backwards definitions, it just allows us to collectively be blind to those problems.

To address this, I’m starting a series of posts to help expose these words and phrases, and hopefully help us regain the understanding of the intent behind them, and for some, provide what I feel are more helpful definitions. Hopefully in doing so, we can start focusing on the real problems we need to see.

First up will be an easy target:


TL; DR: We like to think that we’re careful with the language we use. But I don’t believe we are. The common vernacular of our trade has been corrupted, and I believe is leading us down the wrong path. More posts will be coming soon, each one tackling related words and phrases we commonly use in this industry, exposing what they really mean, and the harm that comes from the way many of us use them.


The Importance of Words: Waterfall vs Agile

17 minute read

Waterfall methodologies are often seen as the antithesis of Agile, and therefore ‘bad’. But what does it really mean for something to be ‘waterfall’? Are you...

The Importance of Words: Quality

5 minute read

We care a lot about the word ‘quality’ in the software industry. But what actually is quality? How do we use the word in our day to day life?

The Importance of Words

2 minute read

It’s natural (and inevitable) for words and phrases to change in meaning over time. But what if they were chosen for a purpose, but their meaning changes eno...

Back to Top ↑


“What would QA do all day?”

26 minute read

If the developer wrote the tests for their tickets, what would QA do all day? More importantly, what are the implications of that question being asked in the...

The Harmful Obsession With DRY

7 minute read

The intent of DRY is to help us find potential opportunities for abstraction. Many take it to mean we should never repeat a block of code. However, this inte...

Grey Box Testing: Less Is More

8 minute read

What is grey box testing? How can it benefit us? How is it different from white or black box testing? Are they all required? Do they dictate how we design ou...

1 Assert Per Test

12 minute read

You’ve heard it before, and probably many times. But why exactly is it the rule that should only have 1 assert per test?

Let’s Talk About Cypress

20 minute read

There’s some fundamental issues with the claims that Cypress makes of themselves that need to be acknowledged. Let’s take a look at their claims and see if t...

Is Selenium Actually Flaky?

12 minute read

We’ve all gotten frustrated dealing with flakiness once we start involving Selenium in our tests. But is Selenium really the problem? What can we do to solve...

Scientific Testing Part 2: Validity

21 minute read

The validity of tests helps build our confidence in them and determines the value they add to our test suites. But what does it mean for a test to be ‘valid’?

Back to Top ↑


Building Good Tests

22 minute read

A collection of testing maxims, tips, and gotchas, with a few pytest-specific notes. Things to do and not to do when it comes to writing automated tests.

Back to Top ↑