Q:

Explaining a potential "paradox" in efficiency optimization between two systems

Let's imagine 3 workers:

Alice is extremely hard-working and effective at her job; she can finish a task in three (3) minutes.
Bob is fairly experienced, but Alice is just a 'smidge' faster; he can finish a task in five (5) minutes.
and Charlie — he's an intern, so he still needs to master the trade; he can finish a task in fifteen (15) minutes.

By simple analysis, you can see that in 15 minutes, these three workers can complete a total of nine (9) jobs if they work until completion and without help from any of the other two workers, since:

Charlie can finish only one job in that span of 15 minutes, while Bob can finish three jobs and Alice can finish five jobs.

However, let's say we implement a "round-robin" approach, rather than have each person work until completion; meaning, every two (2) minutes, we arbitrarily swap each worker around with his/her neighbor — even if they haven't finished. Unless, of course, they finish their job before the "swap" (in which case, they move to the next job until their 2 minutes are fully occupied), we assign a worker to the next incomplete/available job (prioritizing "incomplete" above "available") and continue this pattern indefinitely.

I argue that this round-robin approach can be more efficient than the original "work-until-completion" model, but in comparing the two systems, I have results that give some pause to its validity.
To make the comparison smoother, I allowed both systems to run for 16 minutes; that would mean in the original system, we would have 9 tasks completed, and roughly 60% pending completion which is shared between three others tasks — one-third completed by Alice, one-fifth completed by Bob, and one-fifteenth completed by Charlie.
In the second system, the "round-robin" schema looked like this:

After every two minutes, Bob would work on Alice's prior job (unless Alice completed it, which means he would take the next available job), Charlie would take Bob's job (with the same conditions), and – likewise – Alice would try to finish Charlie's job (again, under the same conditions).

Note: I consider the time in-between "swaps" (e.g., walking to a new station, preliminary checks, acquiring equipment, etc.) to be negligible; in practice, we would consider these delays, but in this case we'll consider them so small in comparison to their work speeds as to be practically non-existent.
From what I managed to work out, the results confound me: on one side, I could argue that the "round-robin" system is more efficient, since I can get a combined 10.47 jobs compared to 9.60 jobs in the "work-to-completion" system; however, if we read the finer print, we could argue the opposite because I only get 8 jobs completed, but I have three jobs pending that are near-completion — one at 93% completion, one at 87% completion, and another at 67% completion (note that these percentages are greater than those jobs pending completion in the "work-to-completion" system combined).
Edit: Where I got 10.47 jobs after 16 minutes for the "round-robin" system is as follows:

After the first two minutes, we can see that Alice's task is 67% complete, since 2 minutes ÷ 3 minutes/task = 67%; following this logic,  Bob's task is at two-fifths completion (or 40%) and Charlie's task is at 13% (or 2/15).By the swapping schema I defined, Alice begins working on Charlie's task, which is 13% complete. After two minutes, the combined completion of this task is now 13% + 67%, or 80%.In the meantime, Bob works on Alice's job, but he gets lucky — the job is already 67% done! So Bob only needs to spend one-&-two-thirds minutes (i.e., 1.67 minutes), since 1.67 minutes ÷ 5 minutes/task + 67% complete = 1 task, to finish Alice's job. But after 1.67 minutes, Bob starts a new task (since no "incomplete" task is available, since Alice and Charlie are working on them at this time) for the remaining 0.33 minutes (which allows him to complete 7% of this new task). Charlie, however, can't finish his task in two minutes despite it being 40% done (since 40% + 13% = 53%).Another swap (being mindful that the global time is now 4 minutes), and now Alice starts on Charlie's task at 53%, and gets it done after 1.4 minutes (since 1 - 53% = 47%, and 47% * 3 = 1.4). Then she uses the remaining 0.6 minutes to get another task 20% complete.Bob, meanwhile, gets Alice's job at 80% complete (once again, Bob lucks out!), and only requires 1 minute to finish up, then uses the extra minute to start another task to get 20% done. Charlie struggles to eek out 20% after working on Bob's 7%-complete job.As you may see, it gets rather confusing in this fashion, but if everything here matches my chickenscratch work it should end with 8 tasks done after 16 minutes, and three additional tasks at the mentioned percentages of completion, which add up to 10.47 tasks (8 + 13/15 + 14/15 + 10/15 = 10.47, with rounding)

So, this "paradox" (by "paradox," I do not mean it in the literal logical sense, but more unintuitive) is:

Which system is more efficient? The one with more jobs completed, or the one with more jobs closer to completion?

The confusion thereby lies in whether efficiency should only be considered on the number of jobs that leave the system (9-to-8), or should we also consider the combined percentage of jobs in either system when we compare the two (9.6-to-10.47).
This also raises some additional questions:

If this "round-robin" system is less efficient, is there a way to modify the system to be more efficient (i.e., by modifying the length of time between swaps, or by modifying how each incomplete job is assigned)?

Is there an optimum time or swapping schema that can produce the most efficient system (or, at least, more efficient than my schema) according to Alice, Bob, and Charlie's relative work speeds?

Edit: I double-checked my work and yes, I did make an error; when I wrote the problem out by hand, I mistakenly had Bob work on the job that Charlie did not finish in the third iteration (which cannot happen since Charlie is still working on the job), rather than work on a new job (as I explained in the edit above), which carried error through the rest of my calculations.
As a result, the end-total for the "round-robin" system should be 9.60 jobs – the same as the "work-until-completion" system, although with only 8 jobs complete and three pending jobs at 93%, 47%, and 20% complete – as @NeitherNor correctly pointed out. Both systems have the same efficiency, but the results still lend themselves to the "paradox" I offer above.

A:

If everybody works all the time, without a break, and everybody gets a fixed amount of work done per unit of time, then it doesn't matter how you split up the work, the total work done, i.e. the sum of finished and unfinished but started (weighted by progress) jobs is always the same.
The only thing which changes between systems is when the work packages get actually finished. Optimally, we would like that all work packages currently worked on were just started, which implies that the total work done (which is always the same) is mainly located in the finished jobs. In a nutshell: better have two jobs finished than three close to being finished.
But it's not clear if we can say that one system is always better in that than another. For example, the first system is optimal if the total working time is divisible by 15. This is because, then, everybody just has finished his or her job and started a new one. On the other hand, if you look at time 14:59, this system is quite terrible: there are three nearly finished jobs. There could be 2 finished ones and one slightly less finished one instead with a different system. This different system would however likely perform worse if you look on some other time.
Here is my thought: what you want to minimize is the time a job is nearly finished. Thus, what I would do is to let Charly start every new job. The job is then taken over by Bob as soon as he is free (Charly starts a new one), and finally the job is taken over and finished by Alice as soon as she gets free. With this algorithm, a job gets the faster done the closer it is to be done already. This system ensures that at least one job is not yet progressed far (Charly's), which is great, and also that Bob's job is at least not close to be finished, which is at least not terrible. With this system, we thus avoid the terrible situation where all jobs are just 99% finished. On the other hand, we also never get the benefit that, by chance, all three jobs are finished at the same time. But at least we flatten the curve (avoid extremes).

