Blog
Why Your Shuffled Playlist Repeats Itself
A true shuffle clusters. Every music app quietly stopped using one, and told nobody.
A software company shipped a feature, users complained it was broken, engineers verified it was working exactly as specified, and the company changed it anyway. That is an unusual sequence of events and it is worth sitting with.
The mechanics of why a uniform shuffle clusters have their own reference page. This is about the decision.
The bug report that was not a bug
The complaints were specific and they were wrong on the merits. Listeners reported that the feature favoured certain albums, that it was biased toward recently added music, that it had stopped being random. None of that was true of the implementations being complained about.
What was true is that people were noticing something real and explaining it incorrectly. The effect they heard was genuinely present; the cause they inferred was not.
That distinction is the whole episode in miniature. A report that is factually wrong about the cause can be entirely correct about the experience, and a team that evaluates only the stated cause will close it as invalid — which is what happened first, for some time.
Choosing the worse implementation on purpose
The eventual response was to replace a correct implementation with an incorrect one. Not a bug fix and not an optimisation: a deliberate substitution of an algorithm that provably fails the stated property for one that does not.
It is hard to name many other features where that would be tolerated. A search engine returning wrong results because people preferred them, a calculator rounding because the exact figure felt off — both would be scandals. Here it was the right call, and it was the right call because nobody actually wanted the stated property. They wanted the experience they had wrongly attributed to it.
So the specification was the thing that was wrong, not the code. That is the diagnosis engineering processes are worst at reaching, because the specification is normally what arbitrates whether the code is correct at all.
What it cost, and who paid
The change was not free. Constrained reordering cannot produce every possible sequence, so what listeners are offered is not quite what the word promises — and almost nobody found out, because it was never announced as a change.
There is a small real category of person who ended up worse off: anyone who wanted the unconstrained version and no longer had a way to get it. Somebody testing a set, somebody randomising the order of stimuli for a study, somebody who genuinely enjoyed the possibility of a cluster. That option disappeared quietly.
The defensible version of the same decision keeps an accurate description. Making the change was good; continuing to describe the result with a word that names the property you gave up is where it slips into a claim that is not true, and saying so would have cost nothing.
The general shape of the problem
This recurs anywhere a mathematical property and a user expectation point in different directions: feeds that would otherwise show the same source repeatedly, alert batching, near-duplicate suppression in search results.
In each case there is a defensible implementation that people experience as broken, and the resolution is nearly always to constrain the output and then stop describing it by the property that was abandoned.
The failure is never choosing the constrained version. It is choosing it and keeping the old description, which converts a good design decision into a small untruth that nobody quite notices and nobody can quite correct.
How you would detect it from outside
None of this is documented in a way you can check, so the interesting question is whether an ordinary listener could establish it empirically. They can, and it takes about an afternoon.
Build a playlist with a known composition — say four artists, five tracks each — and record the order across many shuffles. A uniform shuffle produces same-artist adjacencies at a rate that is straightforward to compute in advance; a spacing algorithm produces markedly fewer, and the gap is large enough to see in a few dozen trials rather than a few thousand.
The result is not a secret anybody is guarding, and the reason nobody does it is that the answer does not change anything. But it is a good illustration of a general point: a claim about a system you cannot read the source of is usually still testable from its outputs, and a distribution is a far better instrument than an impression.
Frequently asked questions
Were the original complaints correct?
About the experience, yes. About the cause, no — listeners blamed a bias toward particular albums, which was not happening.
Why does that distinction matter?
Because a report that is wrong about the cause is often right about the experience, and a team evaluating only the stated cause closes it as invalid.
Was replacing a correct algorithm the right call?
Yes, because the specification was what was wrong. Nobody wanted the stated property; they wanted the experience they had attributed to it.
Did the change cost anything?
It removed the unconstrained option for the small group who wanted it, and it did so without announcing the change.
What would the honest version look like?
The same implementation with an accurate description. Keeping a word that names the property you gave up is where a good decision becomes a small untruth.
Where else does this pattern appear?
Recommendation feeds, alert batching, near-duplicate suppression in search — anywhere a formal property and a user expectation diverge.