> One thing thats occured to me however... if we have code depending on seeded randomisation in before/after all hooks. How to we cope with that? As the seed will be reset before each example (to be predictable) but it means the first spec's sequence will either be identical to that of the all block, or be tainted by that all block.

Exactly! This is one reason I'm advocating a single call to `srand` before any of this happens. That way everything will be using the same seed and the only way it won't is if the developer calls `srand` directly themselves.

But this is only the tip of the iceberg, in my opinion. I'm a firm believer in the principle of least surprise, it's one of the things I love about ruby (and the ruby community).

At the end of the day, this code should work as expected for developers:

```ruby
# spec/spec_helper.rb
srand 123
```

As soon as `srand` is called after this point, the call in `spec_helper.rb` is meaningless and the developer is left wondering why `srand`, a ruby function, is not working as intended. This holds true for any code the developer writes that can be executed after `spec_helper.rb`, as well.

If you are concerned about allowing the seed for sorting to be set at a later point, that could be handled by introducing a seed specifically for ordering, but RSpec should call `srand` exactly one time. And as soon as it's called after `spec_helper.rb`, a basic ruby construct is broken for developers and the only option they're left with is to dig around in source code to figure out why. I can tell you from experience that having a ruby function appear broken is quite disconcerting.