The Longer You Use It, The More You’re Allowed to Complain
A game developer recently floated an idea that I have been thinking about ever since.
David Goldfarb (The Outsider’s creative director, since you ask) says that players who have logged hundreds of hours in a game should not be allowed to leave a negative review.
The logic, as best I can reconstruct it, is that if you stuck around for that long, you must have been getting something out of it. Leaving a negative review after five hundred hours is therefore hypocritical. You clearly didn’t hate it that much.
It is a theory, and is appealing in the way that a lot of bad ideas are appealing. They sound almost reasonable until you think about them for longer than about thirty seconds.
Production of a Long Exposure
I have spent years working inside software systems. Codebases, internal tools, third-party platforms, enterprise dashboards that nobody in the company fully understands but everyone depends on (and nobody outside cares about). I have worked in places where the architecture was described in an interview as “a little messy but fundamentally solid”.
I now know that that’s simply developer-speak for
“we have made a series of decisions we now regret but cannot admit to”
Which tracks, because the longer you spend on a system the clearer its flaws. Expertise isn’t cynicism.
This might be a different position to the game player who has logged five hundred hours but I don’t think so. They have seen the game at its best and at its worst. They know which mechanics are satisfying in the first ten hours and which ones stop making sense by hour fifty. They have encountered the bugs that only appear in edge cases. They have felt the drop-off where the design runs out of ideas. I know what David Goldfarb means though, he thinks the obsessive “fan” of a series needs to take a step back before reviewing a game.
Yet in software development we are all obsessives.
The Real Argument
When someone says “you shouldn’t be allowed to criticize something you’ve used for five hundred hours” they are not actually making a point about review validity.
I think many software developers (particularly those in the creative industries) are saying “I would prefer not to hear this”.
“And haven’t we all been there already”
Because feedback can be hard to hear, whether you’re working on a banking App or the latest AAA game. How do I know?
Well I’ve been that senior engineer who raises architectural concerns and gets told they’re being obstructionist. I’ve seen honest Glassdoor reviews (from inside a company) that get dismissed as “disgruntled”.
Those internal tools that get criticized yet everyone has been using them for years (I mean how?) is the same pattern. The person with the most experience of the system is the one whose criticism is least welcome.
Why Do We Do This?
There is a reasonable psychological explanation for it, even if the behavior itself is unreasonable.
Criticism from a newcomer is easy to handle. They don’t understand the context. They haven’t seen the constraints. They’ll come around once they’ve been here long enough. You can nod, explain, and move on.
Criticism from someone who has been inside the system for years is much harder to absorb, because it cannot be deflected with context. They have the context. They have more context than you would like them to have. When a developer who has spent three years in a codebase tells you the data layer is a structural problem, they are not speaking from ignorance. They are speaking from a position of detailed, hard-won, painful knowledge.
The only way to dismiss that criticism is to attack the critic rather than the criticism. They’re bitter. They’re negative. They’ve lost perspective. They’ve been here too long and they can’t see the forest for the trees.
This last one is my favorite. The idea that someone can have too much knowledge of a system to evaluate it clearly. That if you just didn’t know so much about how it actually worked, you’d feel a lot better about it.
What Good Looks Like
I once worked with a product team that did something I hadn’t seen done before. The product team actually cared about the product. Product managers jumped on calls with real customers and got walkthroughs on their experiences.
They get actionable improvements. They improve the stuff. They get better.
The instinct to dismiss longtime users as too invested, too negative, too difficult to please is exactly backwards. Long-term users are not a nuisance. They are a free pool of expert knowledge about your product under real-world conditions. The fact that some of their feedback is critical does not make it less valuable. It usually makes it more valuable.
The Industry Version
Software companies are not especially good at this.
The developers who have worked longest in a codebase are often the ones most likely to be overruled when they raise concerns. There is a well-documented tendency to treat sustained criticism as a cultural fit problem rather than a signal (and fire the person who “doesn’t fit” and causes issues on those quarterly forms).
Essentially we don’t want changes. We just want to get told that everything is okay and all right, even when it isn’t. It’s such a shame when you think about it.
Conclusion
Negative feedback from a longtime user is not a paradox. It is not evidence of irrationality or ingratitude. It is what happens when someone knows a system well enough to articulate specifically what is wrong with it.
The game developer who wants to silence five-hundred-hour reviews has it exactly backwards. Those are the reviewers worth reading. Those are the ones who have earned the right to an opinion that isn’t softened by novelty or goodwill.
Long exposure does not breed tolerance for problems. It reveals them. That is not a bug in the feedback process.
It is the whole point.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles through Medium.com.
The Secret Developer likes to complain. You knew that, didn’t you?