This means the numbers are meaningless and don't provide a good representation. Needs better data.
Call me inhumane, but a single story doesn't mean anything. It's just some random point in the set. Drawing any conclusions from such a single point is dangerous (the larger the set, the more), as we humans just love to extrapolate single points and even tend have quite strong emotional defenses about their importance.
To remove the emotional part, just think of something from IT, like response times or test coverages. See, a story of an obscenely long API response (out of thousands) doesn't make much sense anymore. Debugging individual cases may even lead you on a completely wrong track. Unless you want to merely resolve that particular single request.
I'm sorry about the tone. Stories about others make humans relate (which is good), but they also have such undesirable effects (hype over facts, extrapolating, etc).
I'll call you inhumane then. Despite record employment levels and rising average net worth in the USA, millions of people are still starving and struggling with drug addictions and so on.
Averages and generalizations only tell a portion of the story. Anecdotes can shed light on "noise".
That's also a single aggregated number. Until the data doesn't cover those millions dire situation, it's a bad data. Emotionless analogy: like a green status page when some percentile of requests is failing.
See, you've mentioned "millions" rather than some "that person.". That's exactly what I mean.
There was a time (or at least so I'm told) when having a job meant you could build a living, own a house, support a family. So we the started looking at employment percentages as a measure for the quality of the economy.
This incentivizes increasing employment percentage. An easy way to do that is by decreasing the value of a job. Suddenly it doesn't ensure you can build a living, own a home, support a family anymore. But it is still used as a primary measure of the wellbeing of the economy.
This is why you need individual stories to interrogate the quality of your data. Afterwards, you obviously need to come up with new measures that more accurately reflect how well the economy is working for the people in it. But the interrogation will have to work on the basis of anecdotes.
You'd think so, but a little googling shows me that an optimistic estimate is that 1-2% of US Americans that go hungry once in a while because they cannot afford food. Some sources, such as those cited by wikipedia [0], put the number as high as 5-6%.
(Now we could have a debate on the meaning of 'starving', but let's just say there is a broad area between skipping a few meals and dying from lack of food that is all covered by how people use the word.)
I'm not talking about "drawing conclusions from a single point of data". I'm talking about using single points of data to interrogate the completeness and correctness of your data.
You’re correct that the approach can be misused. However, it’s also worth thinking of it like a “persona” in product design. When used correctly the journalist has the data, the data tell a story, the journalist chooses a subject that personifies the story so people care to read about it.
The problem I see is that a lot (I believe) of people still do this, even if you and I don't.
I guess I'll contradict myself with the anecdote (I recognize this is totally not representative). I've heard a lot of stories about how "they do this and that, somewhere" based on a news about some single case. Some make sense, but also lots of variants of vaccines and autism stories (mostly, regarding modern politics, so I don't want to describe anything in particular).
Call me inhumane, but a single story doesn't mean anything. It's just some random point in the set. Drawing any conclusions from such a single point is dangerous (the larger the set, the more), as we humans just love to extrapolate single points and even tend have quite strong emotional defenses about their importance.
To remove the emotional part, just think of something from IT, like response times or test coverages. See, a story of an obscenely long API response (out of thousands) doesn't make much sense anymore. Debugging individual cases may even lead you on a completely wrong track. Unless you want to merely resolve that particular single request.
I'm sorry about the tone. Stories about others make humans relate (which is good), but they also have such undesirable effects (hype over facts, extrapolating, etc).