why are the sensitivity graphs at the end using a batch size of 1? earlier you stated "using the smallest batch size is a bad idea" so why would our optimization strategy be guided by "a bad idea"
The sensitivity graphs are showing a different analysis than the earlier Monte Carlo simulation. When I said "using the smallest batch size is a bad idea," that was in the context of the initial parameters (where tests take 5 units of time with 99% reliability). In that specific scenario, a batch size of 22 was optimal.
However, the sensitivity graphs at the end are exploring a different question: "If we're already committed to a batch size of 1 (single-piece flow), should we focus on improving reliability or speed?" This represents the ideal state many teams want to reach - continuous delivery with single-piece flow.
I'm having trouble understanding what a "batch" is supposed to mean in this context. What does it mean to run a batch of size `b` through the tests? I feel like this is probably an intentionally abstract term since what different disciplines test and how they test varies but having a concrete example would I think help me make sense of this better.
this probably extends generally to a lot of the abstraction throughout the article. I'm finding myself struggling to make sense of abstract units of work. There's also this separate concept of a "task" and I'm not sure how that relates to units of work. Is a task composed of units of work? or are the units of work the units of work to test the task?
A batch in this context refers to a group of changes that are bundled together before testing. For coding, a batch might be several code changes that are submitted in one go for testing.
So when I say a batch size of b, I mean testing b chunks of work at once rather than testing each unit individually.
To try and make it a bit more concrete, imagine you're developing a web app.
- A single unit of work might be add a button to a page
- A batch of 5 might mean adding a button, updating a form, fixing a menu (and so on).
- A batch size of 1 would be testing each change individually (and validating they work with the tests passing).
- A batch size of 5 would be testing all changes at once, and then having to redo all that work if they fail.
> Let’s pretend I’ve got 100 units of work to do (each unit takes a unit of time too!). It takes 5 units to test my work, and if the tests fail, I start again.
When you say "test my work", do you mean write the tests, running them, or running the whole test suite?
You are right, there were a lot of assumptions that I didn't state. I was imagining 5 units of time to run the tests (and assume the tests are written as part of the work).
why are the sensitivity graphs at the end using a batch size of 1? earlier you stated "using the smallest batch size is a bad idea" so why would our optimization strategy be guided by "a bad idea"
The sensitivity graphs are showing a different analysis than the earlier Monte Carlo simulation. When I said "using the smallest batch size is a bad idea," that was in the context of the initial parameters (where tests take 5 units of time with 99% reliability). In that specific scenario, a batch size of 22 was optimal.
However, the sensitivity graphs at the end are exploring a different question: "If we're already committed to a batch size of 1 (single-piece flow), should we focus on improving reliability or speed?" This represents the ideal state many teams want to reach - continuous delivery with single-piece flow.
I'm having trouble understanding what a "batch" is supposed to mean in this context. What does it mean to run a batch of size `b` through the tests? I feel like this is probably an intentionally abstract term since what different disciplines test and how they test varies but having a concrete example would I think help me make sense of this better.
this probably extends generally to a lot of the abstraction throughout the article. I'm finding myself struggling to make sense of abstract units of work. There's also this separate concept of a "task" and I'm not sure how that relates to units of work. Is a task composed of units of work? or are the units of work the units of work to test the task?
A batch in this context refers to a group of changes that are bundled together before testing. For coding, a batch might be several code changes that are submitted in one go for testing.
So when I say a batch size of b, I mean testing b chunks of work at once rather than testing each unit individually.
To try and make it a bit more concrete, imagine you're developing a web app.
- A single unit of work might be add a button to a page
- A batch of 5 might mean adding a button, updating a form, fixing a menu (and so on).
- A batch size of 1 would be testing each change individually (and validating they work with the tests passing).
- A batch size of 5 would be testing all changes at once, and then having to redo all that work if they fail.
Does that help?
> Let’s pretend I’ve got 100 units of work to do (each unit takes a unit of time too!). It takes 5 units to test my work, and if the tests fail, I start again.
When you say "test my work", do you mean write the tests, running them, or running the whole test suite?
Wow, a comment! Thank you :)
You are right, there were a lot of assumptions that I didn't state. I was imagining 5 units of time to run the tests (and assume the tests are written as part of the work).