Jan 19
How many bugs should your product have?
I was one of those idiots that pre-ordered Cyberpunk 2077.
I did it because I’ve always wanted a protagonist that has what I can only assume is called an “electro-mohawk”. Upon starting my first session, I sent a screenshot to my brothers. I believe it was a portrait of a cyber-cigar smoking meta-human. One of my brothers, who is not a “core gamer” but has played through “Breath of the Wild” (for which I award partial credit), had an interesting reply:
The answer, or rather — one of probably many answers that definitely does not deserve a thousand-word essay — is widely applicable: Cyberpunk 2077 has so many bugs because Cyberpunk 2077 is much more ambitious than a stable version of itself.
You want a stable Cyberpunk 2077? That game already exists and it’s called Far Cry 12: The Just Cause.
How many bugs should your product have?
For us startuppy-types, this isn’t a pseudo-philosophical conversation we have over hot wings, this is a real question we need to ask about our products. When do we take our respective babies and show them to people? When do we show them to the world? When is a product really, truly, for-suresies… ready?
I think I have an empirical estimate.
“On a short enough timeline, ambition and stability are inversely correlated.”
I formatted it all cool-like because it sounds really smart.
This gives us a graph to work with and you just know I love graphs.
You can see that as we increase ambition, stability plummets. Even a minuscule amount of ambition sends us into a stability-nose-dive. This is the Deep Magic of the Universe, not just a product-development-thing. I think I’ve been over this before, a few times, but this effect is particularly pronounced in software, where a a missing { can break encryption on billions of devices.
A Strawman
Let’s pick on a game extremely similar to Cyberpunk: Bejeweled. Bejeweled is a fine game made by fine people (well, not Jared in accounting) — and quite stable at this point, I hear; but ambition is almost non-existent.
We imagine ourselves standing on the station platform, looking down the tracks. We see, in the distance, Bejeweled’s graffiti-covered caboose — but the train only made it a few feet before grinding to a stop. The ambition train has barely left the station.
The easiest code to bulletproof is the code that doesn’t exist. The easiest features to get right are those that aren’t around at all.
Cyberpunk, on the other hand…
You see, all ambitious games are somewhere far to the right on our stability v ambition curve.
The Trans-Siberian railway runs almost six thousand miles, connecting Moscow and Vladivostok — most of it straight as an arrow: through mountains, over lakes (needlessly through the middle of some lakes) and from the station platform you have no hope of spotting the Cyberpunk train. Stability drops like a stone in the Siberian wilderness, toward the asymptote of absolute chaos just past Vladivostok — if it keeps on like this, starting a new game in Cyberpunk may summon a hellish creature made entirely of fins and discarded toothpaste tubes. There’s really no telling.
So we are left along the tracks with no tools in hand but trade-offs and value judgements. Great tools these are.
Where along these tracks should we release products? When is it okay to ask people for money for something? If every product took the Cyberpunk approach, I imagine I would be more displeased, but as it stands, I’ve got a bug-infested ticket for the second largest city in the Far Eastern Federal District with my name on it. I’m starved for something more ambitious than a pay-to-win military battle royale.
What are you saying?
For starters, don’t confuse the Soviet-based mixed metaphor above with a green-light on releasing shoddy products. You didn’t hear it from me that your product can be garbage.
However, do keep in mind that “production ready” isn’t an absolute measure. Some products are not production ready because bugs make them unusable. I will concede that Cyberpunk on last gen consoles… is solidly in this bucket. Other, “bug-free” products aren’t production ready for an entirely different reason: because they have no ambition. They don’t do anything. They are the equivalent of a “glass of milk and a large bowl of mild farina.”
And if a product lacks ambition, why make it to begin with?
Releasing buggy code into the wild may absolutely mean you are a bad developer, but that is not a necessary condition — only sufficient. Other times, a buggy product is a statement of ambition, of artistry, of dreams too big to build.
Perhaps some of us should move a bit further along that curve: take on more ambition… and more bugs.
