Skip to content

Feature: experiment.EnsureControlRunsFirst() - #166

Closed
JoshHiles wants to merge 7 commits into
scientistproject:masterfrom
JoshHiles:feature/run-control-first
Closed

JoshHiles wants to merge 7 commits into
scientistproject:masterfrom
JoshHiles:feature/run-control-first

Conversation

@JoshHiles

Copy link
Copy Markdown
Contributor

resolves #159

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

@JoshHiles

JoshHiles commented Nov 14, 2025 •

Copy link
Copy Markdown
Contributor Author

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 😅

@M-Zuber M-Zuber left a comment

Copy link
Copy Markdown
Contributor

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

JoshHiles commented Nov 14, 2025 •

Copy link
Copy Markdown
Contributor Author

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

M-Zuber commented Nov 16, 2025

Copy link
Copy Markdown
Contributor

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
Copy Markdown
Contributor Author

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

@M-Zuber

M-Zuber commented Nov 19, 2025

Copy link
Copy Markdown
Contributor

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

@JoshHiles

Copy link
Copy Markdown
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