What do you mean by "bad" software?

Photo of 3 brown eggs in a carton with faces drawn on. One sad, one disapproving, one in the back laughing.
Photo by Nik / Unsplash

(Before I get started, a moment to appreciate this header image and whatever was the genesis of it.)

Engineers will often describe software as "bad"—often with words like "terrible" or "shitty." This invective is hurled at languages like PHP and JavaScript, at frameworks and libraries like React or Rails, at operating systems like Windows, and most often at whatever "legacy" code we have to work with.

But what does it mean?

I'm not talking about "bad" in the sense of morality. There are a few cases where "bad" can be taken to be synonymous with "evil," but it's rare and, as the challenges with open source licenses and ethics have discovered, a moving target. I'd consider things like facial recognition software for police departments and surveillance states, machine learning (ML) models that are thinly veiled phrenology, deepfakes in general "bad" in this sense.

Calling software "bad" obscures the meaning: what is it bad at? Or good at, for that matter?

When I dig into "bad," there are a few things that I usually mean:

  • It's a bad choice for this particular problem because of x, y, or z.
  • It's hard to operate effectively, e.g. needing a lot of attention or not providing much insight into how it's working.
  • It's hard to extend, either from lack of tests or confidence, too many responsibilities, or design choices like composing too many behaviors too deep in the stack or confusing abstractions.
  • Or, there's something subjective about it that I just don't like.

As I've gotten older, I've tried very hard to be clear about which thing I mean. Partly this is because I've gained a lot of sympathy for (most of) the people who came before and created this under whatever constraints existed at the time.

And partly it's because being specific goes a lot further when I'm trying to persuade people. Saying Ruby (I've been working in it a lot the past few years, so I'm picking on it) is a "bad" language is a good way to get into an endless argument on the internet. Saying that it's a bad choice for a data pipeline because there are far fewer data tools than Python is addressable and verifiable. And so even is saying that I personally prefer parentheses on method calls—it's a subjective preference that's clearly not held by everyone, and likely only worth taking into account in an "all else being equal" situation, where we might vote.

Recently I've seen lots of fights in social media comments about "AI" tools, some saying it's bad, some saying it's good or that it will get better. When I make the mistake of getting involved, I usually ask "good at what?" (There are absolutely answers to that! Whether or not they're worth the external costs is an important question.)

Of course I am still guilty of this as well. There's a time and a place for kvetching, and sometimes we all need to feel and express frustration.

But next time you hear someone call some software a piece of shit, consider asking what they mean. And the next time you're tempted, ask yourself what you mean.

(And all of this also applies to using the word "sexy" to describe projects. It's meaningless and weird.)