Comment On More or Less Random

He should have just replaced with the button with a pop up that says "Who is the best Admiral? You are! Yes you are! Yes you are!"

I think that would have gone over better.

Certainly a weird request, but at least it was incredibly easy to fix.

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

Yes. That's what I was about to suggest... But that probably would have required a spec change. You'd have managers arguing for weeks over that.

This comment is as random as the last one.

I don't really see any WTF here. Any test scenario *has* to be reproducible, otherwise what good is it? It is useless if it can't be accurately reproduced to try different strategies.

The only WTF I see is on the developers side for not realizing this and taking the word random a bit too literally.

Wait a minute, so the button was set up to use the same seed every time it was pressed, but since the admirals were the ones pressing the button and the state of the simulation at the time they pressed the button depended on exactly when they pressed the button, wouldn't the scenario play out differently if the pressed the button say 1 minute later the second time they ran it and therefore still be practically unreproducible?
Guess it depends on the time resolution of the simulation.

I've totally seen the source code for this somewhere, I know it....oh yeah...

Oh no - it's our country (US), I'm sure =/

So, where is the WTF here? They needed random actions that could be repeted (they had good reasons for that), the devs implemented random actions that could be repeted the most obvious and simple way it could be done (I'm even afraid of imagining any alternative).

Where is the problem?

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

This is definitely a good idea - ever played FreeCell solitaire? same idea with the game number selection. Though, as others have noted, it would take weeks/months/meters of paperwork to get it approved and added to the spec.

Why have I never heard of our plans to protect against enemy rickshaws?

What is our new president's stance on this issue?

I wish to be an informed citizen and need this information!

Makes perfect sense to me:

Instructor sets up a scenario with x tanks and y planes and z rickshaws. To stop things being predictable, the random button suddenly means the rickshaws can do 70mph and have rocket launchers.

Then he needs to test the next guy with the same situation, so that they can see who is good and who is not so good at dealing with this sort of unexpected behaviour. It is vital to have the same scenario.

The real WTF is that the people in charge of this didn't know what they were designing and so didn't spec it properly.

The lesson here is that when the admiral said "random" he meant "alternate".

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

Agreed, it's not that hard: Random ran = new Random(2);. You could even make it a passed in variable like above the button have "Enter the random series number" and seed it with that so they could get as many random sequences as they wanted, AND they could reproduce any of them at any time.

Assuming Java of course, but I'm sure other languages have similar libraries.

Steve:

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

Yes. That's what I was about to suggest... But that probably would have required a spec change. You'd have managers arguing for weeks over that.

Assuming that the RNG was self-seeding, you could just hit the button a second time for the "next random scenario".

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

Yes, that's definitely what they REALLY wanted.
I always make sure that all my users have some meaningless 32 bit number they have to write down somewhere and enter every time they want to use my application.
I keep it on the same screen with the mandatory "field1" "field2" "field3" that must be set to specific hidden values or the application will crash and erase all their data.

And remember our design moto - Good UI makes you cry.


-----------------------------------------------------------
When good men do nothing, The RIAA Moths win!

The lesson here is that when the admiral said "random" he meant "alternate".

The lesson here is that when Americans say "alternate" they mean "alternative".

Why don't they just play the same video game and see who gets the highest score?

Jon:

The lesson here is that when the admiral said "random" he meant "alternate".

The lesson here is that when Americans say "alternate" they mean "alternative".

Hey Sherlock, how exactly did you deduce that Strilanc is American?

Random actions ... that could be repeated = different scenarios, not 'random'.

The WTF here is a simple communication mixup. The military wanted branching but repeatable scenarios, the developers heard random, and gave them random.

snoofle:

Why have I never heard of our plans to protect against enemy rickshaws?

What is our new president's stance on this issue?

I wish to be an informed citizen and need this information!

Yeah, I wish to need that information too. But it just isn't happening.

And here I was expecting some exploding sharks deriving from torpedoes or something.

http://www.snopes.com/humor/nonsense/kangaroo.asp

Yeah this really isn't a WTF. In simulations like this it's important for scenarios to be repeatable. Because of this you have to be very careful how random numbers are used.

The whole point of software like this is to be able to train groups of people using a fairly predictable scenario. This will allow you to compare performance across two different groups of trainees and assess the effectiveness of the actions they took. This also let's a group of people who failed the first time be able to repeat the scenario and see the outcome of different actions.

It may seem silly that someone would ask for "repeatable randomness" but that's actually a beauty of pseudo-randomness that you can do it :)

kastein:

Jon:

The lesson here is that when the admiral said "random" he meant "alternate".

The lesson here is that when Americans say "alternate" they mean "alternative".

Hey Sherlock, how exactly did you deduce that Strilanc is American?

Hey Sherlock, how exactly did you deduce that kastein was claiming that Strilanc was American?

The WTF, as has been mentioned, is that the system wasn't spec'd well. The act of dragging what a user really needs out of them is an art that only few know well.

snoofle:

Why have I never heard of our plans to protect against enemy rickshaws?

What is our new president's stance on this issue?

I wish to be an informed citizen and need this information!

Now you finally know what all the duct tape and plastic sheeting was for!

Dr Evil:

Random actions ... that could be repeated = different scenarios, not 'random'.

The WTF here is a simple communication mixup. The military wanted branching but repeatable scenarios, the developers heard random, and gave them random.

No they wanted the movements to be random and the scenario, which was based off of random events, to be repeatable. Hence the creation of the random seed.

So they implement a system that produces repeatable data. The customer states that they don't want it to always be the same.

Then, they implement a system that does NOT produce repeatable data. The customer states that they don't want it to always be different.

These "paradoxical" requirements are, in fact, not paradoxical at all. They're not even mutually exclusive. "not always" is not the same as "never". They want it to be /sometimes/ repeatable, and /sometimes/ different. In other words, they want randomised but repeatable scenarios. The WTF here appears to be in the attitude of the submitter, not the customer, and possibly (seeing as we only have one point of view to go by) not even the developers.

Drew:

The WTF, as has been mentioned, is that the system wasn't spec'd well. The act of dragging what a user really needs out of them is an art that only few know well.

Unfortunately, quite a few people seem to have figured out the actual requirement just from this submission and a knowledge of the context. It's not hard to understand the customer if you remember to not take everything they say at face value.

codemanque:

So they implement a system that produces repeatable data. The customer states that they don't want it to always be the same.

Then, they implement a system that does NOT produce repeatable data. The customer states that they don't want it to always be different.

These "paradoxical" requirements are, in fact, not paradoxical at all. They're not even mutually exclusive. "not always" is not the same as "never". They want it to be /sometimes/ repeatable, and /sometimes/ different. In other words, they want randomised but repeatable scenarios. The WTF here appears to be in the attitude of the submitter, not the customer, and possibly (seeing as we only have one point of view to go by) not even the developers.

In fact, TRWTF in this article is clearly how the developers were so blinded by their own wit and cleverness in coming up with the "Entropy Button" name, that they then went and implemented their own idea instead of what the customer's requirement actually asked for. They totally had their heads up their asses.

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

(Darn. You beat me to it.)

And you get to impress the Admirals with "we have programmed over 2 billion different scenarios into this new version, and yet you can always replay the same scenario if you want".

Unless, that is, you're concerned about "wasting taxpayer money" by doing so many scenarios. In that case, the first release does "1 million scenarios", and you can then add 1 million more at a time, any time they want to pay for it.

Jon:

The lesson here is that when the admiral said "random" he meant "alternate".

The lesson here is that when Americans say "alternate" they mean "alternative".

The lesson here is that Jon says "alternative" when he means "alternate", because the first is bigger, so it shows how smart he is.

And that Jon is big on hasty generalizations.

Even given the same random seed, since this is presumably an interactive simulation, there is still no guarantee that you'll get anything approaching reproducibility. For example, let's say an hour into the simulation the admiral hits the random button and one of those rickshaws does something unexpected. Now let's say next time through after 45 minutes the player decides to order up an air strike on that rickshaw, obviously the randomness that was coming after 1 hour won't have the same effect, since the rickshaw doesn't exist anymore.
So all you can really do is set up the starting conditions, set up the rules that the enemies will follow (including some randomness if desired) and then let the cards fall where they will.

codemanque:

These "paradoxical" requirements are, in fact, not paradoxical at all. They're not even mutually exclusive. "not always" is not the same as "never". They want it to be /sometimes/ repeatable, and /sometimes/ different. In other words, they want randomised but repeatable scenarios.

It was always repeatable if they didn't use the Randomize Me button. They didn't want random. They only wanted repeatable, just two different repeats and a way to switch between them.

All Admirals not at WoW level 70 get dinged on their FitRep.

Alternate really does mean something different in US and British English.

In BritEng it can either be a verb (emphasis on the last syllable) meaning to switch back and forth between one of two options, eg when you play tennis you alternate who serves, or it can be an adjective (emphasis on the middle syllable) meaning "every other", eg on alternate days I cycle to work, other days I drive.

If you just wanted another option for something, you want an alternative in BritEng.

I am in the simulation business and my customers demand repeatable randomness all the time. Yes, the seed is the place where this is accomplished.

A failure of the contractor to anticipate this - that is the WTF, here, in my opinion.

The real WTF is that the image for this article was saved at a color depth insufficient even to depict Atari 2600 graphics, resulting in terrible dithering.

Really, it's not even a paradox. When they said "unexpected", they meant unexpected by the trainee. Not unexpected by the operator.

NightDweller:

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

Yes, that's definitely what they REALLY wanted.
I always make sure that all my users have some meaningless 32 bit number they have to write down somewhere and enter every time they want to use my application.
RIAA Moths win!

... or you could be a bit smart about it. Just off the top of my head:

* limit the seed to, say, 4-digit numbers -- 10000 scenarios should be plenty, and who can't remember a 4-digit number?

* Translate the seed to alpha instead, and you can get 17576 scenarios from 3 characters

* Put the "scenario number" under an admin / options screen somewhere in the background so you can at least change it later without a recompile, or load it from a config file / registry setting


And I came up with those in 30 seconds. Defense contractors with months to work on stuff should be able to do even better.

James:

NightDweller:

Timothy:

Wouldn't it have been a better idea to generate a random seed and display this number?

Given this number and the ability to enter the same number later to essentially "select the scenario", they could recall the same situation.

Hmm...

Yes, that's definitely what they REALLY wanted.
I always make sure that all my users have some meaningless 32 bit number they have to write down somewhere and enter every time they want to use my application.
RIAA Moths win!

... or you could be a bit smart about it. Just off the top of my head:

* limit the seed to, say, 4-digit numbers -- 10000 scenarios should be plenty, and who can't remember a 4-digit number?

* Translate the seed to alpha instead, and you can get 17576 scenarios from 3 characters

* Put the "scenario number" under an admin / options screen somewhere in the background so you can at least change it later without a recompile, or load it from a config file / registry setting


And I came up with those in 30 seconds. Defense contractors with months to work on stuff should be able to do even better.

* Presumably there's a file with the simulation setup (number of enemies, type of enemies, location of scenario), but the seed in there.

codemanque:

Drew:

The WTF, as has been mentioned, is that the system wasn't spec'd well. The act of dragging what a user really needs out of them is an art that only few know well.

Unfortunately, quite a few people seem to have figured out the actual requirement just from this submission and a knowledge of the context. It's not hard to understand the customer if you remember to not take everything they say at face value.

Then allow me to modify Drew's quote:

Drew:

The act of dragging what a user really needs out of them early is an art that only few know well.

And I agree.

diaphanein:

And here I was expecting some exploding sharks deriving from torpedoes or something.

http://www.snopes.com/humor/nonsense/kangaroo.asp

yeah i was waiting for the kangaroos too!

Of course the customers were expecting pseudo-randomness, which *surprise* is actually used in software testing.

The real WTF is having a bunch of developers chattering about big red entropy buttons without realizing this!

Anon:

Wait a minute, so the button was set up to use the same seed every time it was pressed, but since the admirals were the ones pressing the button and the state of the simulation at the time they pressed the button depended on exactly when they pressed the button, wouldn't the scenario play out differently if the pressed the button say 1 minute later the second time they ran it and therefore still be practically unreproducible?
Guess it depends on the time resolution of the simulation.

Exactly, kind of like how a die with all sixes on its faces is completely dependent on when you roll it.

Anon:

Even given the same random seed, since this is presumably an interactive simulation, there is still no guarantee that you'll get anything approaching reproducibility. For example, let's say an hour into the simulation the admiral hits the random button and one of those rickshaws does something unexpected. Now let's say next time through after 45 minutes the player decides to order up an air strike on that rickshaw, obviously the randomness that was coming after 1 hour won't have the same effect, since the rickshaw doesn't exist anymore.
So all you can really do is set up the starting conditions, set up the rules that the enemies will follow (including some randomness if desired) and then let the cards fall where they will.

Very good point.

All-Beef Patty:

Exactly, kind of like how a die with all sixes on its faces is completely dependent on when you roll it.

The die isn't dependent on time, but the actions are. If you roll double-sixes at the beginning of a Monopoly game, you'll end up on Chance. If you do it later, you may end up in Jail.

Level^3

Yes, the universe has a clock-based RNG.

DaveK:

codemanque:

So they implement a system that produces repeatable data. The customer states that they don't want it to always be the same.

Then, they implement a system that does NOT produce repeatable data. The customer states that they don't want it to always be different.

These "paradoxical" requirements are, in fact, not paradoxical at all. They're not even mutually exclusive. "not always" is not the same as "never". They want it to be /sometimes/ repeatable, and /sometimes/ different. In other words, they want randomised but repeatable scenarios. The WTF here appears to be in the attitude of the submitter, not the customer, and possibly (seeing as we only have one point of view to go by) not even the developers.

In fact, TRWTF in this article is clearly how the developers were so blinded by their own wit and cleverness in coming up with the "Entropy Button" name, that they then went and implemented their own idea instead of what the customer's requirement actually asked for. They totally had their heads up their asses.

Yes! The developers have their head up their asses because they made something according to documented requirements and the customer didn't like it because they didn't get what they expected. It's true the developers could've asked for more clarification for what they meant by "random" which is a common fault for many developers no matter how much experience they have. However, the Admirals are displaying common customer behavior when they say they want one thing done one way, see it, and don't like it because that's not what they had in mind. So they scold the developers for being lazy and not following directions.

And the Entropy Button is actually an appropriate title for the control because that's EXACTLY what it is... a button to increase disorder (randomness) in a scenario.