If you haven’t read about it before, the term comes from the band Van Halen, who demanded that there were no brown M&M’s backstage. People thought it was just a crazy rock star thing, but David Lee Roth later explained that it had a purpose:
Van Halen was the first band to take huge productions into tertiary, third-level markets. We’d pull up with nine 18-wheeler trucks, full of gear, where the standard was three trucks, max. And there were many, many technical errors—whether it was the girders couldn’t support the weight, or the flooring would sink in, or the doors weren’t big enough to move the gear through.
… So just as a little test, in the technical aspect of the rider, it would say, “Article 148: There will be 15 amperage voltage sockets at 20-foot spaces, evenly, providing 19 amperes … ” This kind of thing. And article number 126, in the middle of nowhere, was, “There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation.”
So, when I would walk backstage, if I saw a brown M&M in that bowl … well, line-check the entire production. Guaranteed you’re going to arrive at a technical error. They didn’t read the contract. Guaranteed you’d run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening.
My Brown M&M atm is AI-generated comments like this (first comment is referencing something like df = ... that they removed from the code, but left the comment, second comment is super useless):
# Assuming df is your DataFrame
# Show the plot
plt.show()
That probably means whoever I got the code from just copy/pasted whatever the LLM spit out, and didn’t actually think about the code at all.
What is a small detail that you pay attention to because it means there’s bigger issues to watch out for?
I used to work in serious sim. Think using game engines for realistic combat stimulation and training by the army. Systems had to interact and had different jobs rts, fps, driving simulator, etc.
So they each needed a unit database that was unique to that system. They also usually had a two versions a classified database and a less accurate non classified database.
A quick way to test was there was a unit type that was always set to invulnerable in unclassified databases. So drop one in the sim and drop some artillery on it. If it wasn’t destroyed you were unclassified.
Seems like a really roundabout way to do this, surely a unit test (no pun intended) would’ve been a better solution?
We should have totally called it a unit test.
So the area for this was used for both training of soldiers and demos for people without security clearances. So it frequently had to be switched between the two. So you get everything setup and ready.
As a last test you drop the unit in and blam it. Then you go to each system and check the unit status. If it’s ok you are good to demo to civilians.
A unit test wouldn’t work because it’s a deployment situation and a lot the software wasn’t under our control. A lot of time it was just making sure the DIS HLA gateway was properly configured and entities remapped.
Why
Some people can see classified systems and some can’t.
Why do that using unkillable things