Skip to content

Conversation

@JoshHiles
Copy link
Contributor

resolves #159

A new method experiment.EnsureControlRunsFirst() which if enabled will randomise the candidates first then add the control to start.

@JoshHiles
Copy link
Contributor Author

JoshHiles commented Nov 14, 2025

Not sure why its got all the commits since b2ef4a3 i suspect its something to do squashing commits, the joys, will sort after this PR so i don't mess up more 😅

Copy link
Contributor

@M-Zuber M-Zuber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation is clean, and could go in as is

I am wondering though if this actually solves the issue raised. Since sometimes I can want the experiments to run, and only then run the control. For example, if each experimental behaviour does clean up and just reports on results, then I want the control to run last, without doing any cleanup.
Which then leads us to the bikeshedding of allowing the user to optionally pass in an ordering with each behaviour, or a set number of use cases controlled by settings.

@github-project-automation github-project-automation bot moved this from In progress to Reviewer approved in Scientist.net Nov 14, 2025
@JoshHiles
Copy link
Contributor Author

JoshHiles commented Nov 14, 2025

Legend, very nice catch, i have been very narrow focused on just the issued raised!
Damn yeh a few options then i guess

Pass order to Try & Catch

experiment.Use(ControlMethod, order: 0);
experiment.Try(CandidateMethod, order: 1);

Pros

  • Full flexibility

Cons

  • I think its a bit of UX nightmare
  • Have to deal with order clashes
  • If you set the order on one what about the order of the rest? Lots of edge cases

Enum defined order method

experiment.WithExecutionOrder(OrderExecution.ControlFirst)

Pros

  • Clearly defined API
  • Easy to add new orders

Cons

  • Less flexible

User defined ordering

experiment.UseCustomOrder(behaviours  => CustomMethod(behaviours))

Pros

  • Most flexible in that user gets complete control
  • We can expose some methods to use
  • We don't have to catch edge cases and custom logic

Cons

  • ?

Each way has its own trade offs and advantages, i hesitate to implement them all but perhaps that might be the way?

@M-Zuber
Copy link
Contributor

M-Zuber commented Nov 16, 2025

User defined ordering sounds like it is the best option
as it allows the user full control
we can potentially consider supporting a set number of known algorithms as a bonus (like Ordering.ControlFirst, Ordering.ControlLast)

@JoshHiles
Copy link
Contributor Author

See #167 and if we are happy we can close this PR?

@M-Zuber
Copy link
Contributor

M-Zuber commented Nov 19, 2025

#167 has a rename that snuck in, but otherwise I vote in favor of closing this in favor of #167

@JoshHiles
Copy link
Contributor Author

Closing in favour of #167

@JoshHiles JoshHiles closed this Nov 19, 2025
@github-project-automation github-project-automation bot moved this from Reviewer approved to Done in Scientist.net Nov 19, 2025
@JoshHiles JoshHiles deleted the feature/run-control-first branch November 26, 2025 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

[Feature] Support a non-randomized execution order

2 participants