Hacker News Reader

Comment by ryandrake | Hacker News Reader

I've never really understood developers' apparent need to add cutesy stuff into their work product's test data, variable names, easter eggs and so on. Adding this stuff is all downside risk with no technical benefit that you can explain in a written postmortem that will be read by your boss's boss's boss.

I mean, I get the motivation: You're working on a boring, dry, SeriousBusiness project, and have a creative itch that needs to be scratched. We all have a nonzero desire for a little joy and irreverence at work. But, man, scratch that itch with hobby projects, not stuff that's going out into the public! Or start a "wear a funny shirt day" at work or something like that. I know this is unpopular and makes me look like Debbie Downer, but our projects already have enough technical risks without deliberately adding more.

View on HN

There's a saying: "Don't post anything online you wouldn't want grandma to see." The developer equivalent is "Don't use test data you wouldn't want the client [or boss] to see." This also applies to variable names, function names, and comments in code.

For a project that involved creating fake companies and user records, I purposely choose to use characters from Star Trek, Star Wars, and the Simpsons for each of the different companies. They're whimsical, non-offensive, and as an added bonus, if I see Homer Simpson listed alongside James T. Kirk, I instantly know there's a data integrity problem.

That last bit is the main reason why I use odd or otherwise out of place test data[0]. Test data should never leak into production. Ideally there should be no means of that happening.

[0] Recent example: tissue sample, species: dog, tissue type: bone. Valid combination, just not present anywhere in prod.

> not stuff that's going out into the public!

Well, the problem is, in almost all the examples here so far, said stuff was not meant to go out into the public. If your customers end up seeing your product's test data and---heavens above!---variable names, there is an organizational issue that needs to be addressed, cutesy stuff or no cutesy stuff.

Also, isn't the point of QA testing just to throw all and any data to your system? Would you rather have a system that's tested against the eventuality that someone abuses UTF-8 in a textbox or a full SeriousBusiness system with zero whimsy and cutesy stuff? Someone's whimsy cutesy stuff is someone else's street address.

I think you just put a finger on why I absolutely loathe SeriousBusiness Banking Software: they were designed, implemented, and tested in a vacuum that even normal users end up putting a toe out of line that just breaks the assumptions of the spec. You have to be extremely average down to your name to peacefully coexist with them.

If dummy data ever proposes a "technical risk" to your projects, I might argue you're using the term wrong.

Variable names are different, and I'll give you that, but creating humorous dummy data in lower environments shouldn't ever be an issue. Injecting a little fun legitimately helps overcome despair, and the harder and more difficult your project/company is, the more it needs a dose of lightheartedness.

No matter what the scrum boards that reduce us to story points say, we're all human beings. When everything is very high stakes, you're in a perpetual state of fight or flight. It's literally physiologically bad for you. Blowing off steam helps.

As a test of our new Sev1 alerting system, I created a phony alert "The hordes of Mordor are descending upon our data center".

It was well received by the team.

I read the comment to mean that we have enough technical risk that we don't need more general risk. This stuff adds risk. As I have heard: "do you want to read your joke in a courtroom for a non technical audience?" - in some fields more so than others, but there is always a risk that something will go horribly wrong, your system will be involved and your code shows up either directly or as a side effect of discovery.

Reply on news.ycombinator.com