Two economists are walking down the street. One of them notices what appears to be a $100 bill just lying on the sidewalk, and points it out to the other. “Nonsense,” declares his friend. “If that were a real $100 bill, someone would have picked it up already.”

It’s a joke, but it has a widely applicable point: When you see something that looks like a simple solution that could have been done anytime (such as tearing down Chesterton’s Fence), you should be reflexively skeptical. If it were really that easy, wouldn’t someone have done it already? There must be a reason it hasn’t already been done!

(See also: “Why isn’t every psychic a millionaire?”)

Of course this assumes that we’re working on a group project, where important historical rationales are frequently undocumented. On a solo project, this mantra doesn’t apply at all — if you’re Will Smith in I Am Legend and you see a $100 bill on the sidewalk, you probably should believe your eyes. (On the other hand, if you’re Will Smith in I Am Legend, what would you need $100 for?)

A corollary to this principle — or at least I think of it as a corollary — is, “If this works, why isn’t everyone doing it?” This is especially applicable in code reviews. It explains why consistency is a virtue: inconsistency between A and B almost always means that one of them has fixed a bug that still exists in the other (or vice versa, one has introduced a bug that the other was intentionally avoiding).

For example, suppose we have just noticed that a GitHub Actions automation is breaking because it can’t deal with spaces in the user’s first name. We’ve got a YAML file somewhere in our codebase that looks like

- name: Hypothetical example
  run: |
    ./hypothetical.py \
      --name ${{ event.user.firstname }} \
      --surname ${{ event.user.lastname }}

and it all works fine for our first hundred users like Tom and Mary-Sue, but then we get a user named Billy Bob and our job starts throwing errors like

> Hypothetical example
    ./hypothetical.py \
      --name Billy Bob \
      --surname Thornton
  shell: /usr/bin/bash -e {0}
usage: hypothetical.py [-h] --name FIRST --surname LAST
hypothetical.py: error: unrecognized arguments: Bob

Someone suggests a fix:

 - name: Hypothetical example
   run: |
     ./hypothetical.py \
-      --name ${{ event.user.firstname }} \
+      --name '${{ event.user.firstname }}' \
       --surname ${{ event.user.lastname }}

This patch immediately has a code smell, because it applies the (hypothetical) fix only to the --name argument, instead of consistently to all arguments. Even if this fixed the bug for Billy Bob, we would just hit the exact same bug later on for a surname like Lo Truglio. When I see a patch like this, I think:

If this really works, why isn’t everyone doing it?

The patch should apply its fix to both arguments — and to all other arguments in this YAML file, and to all other YAML files in the repository — or maybe it’s just not the $100 bill it looks like.

In this particular case, the patch is probably wrong anyway, because it can’t deal with first names like T'Challa or last names like… well, one will come to me eventually. Remember Little Bobby Tables — and remember that roll-your-own shell escaping works about as well as roll-your-own crypto.

But what is GitHub Actions’ shell-escaping story? As of this writing, nobody seems to know.