James Carse has a theory[0] about this: “There are at least two kinds of games. One could be called finite, the other infinite. A finite game is played for the purpose of winning, an infinite game for the purpose of continuing the play.”
While I appreciate the “middle” metaphor, I think it’s unwise to generalize business (and real life situations, more broadly) as a chess game — life doesn’t often come with symmetric information and zero-sum stakes.
Annie Duke says it better than I can, in her book[0]:
> “Chess is not a game [in a game theory sense]. Chess is a well-defined form of computation. You may not be able to work out the answers, but in theory there must be a solution, a right procedure in any position […] If you lose at a game of chess, it must be because there were better moves that you didn’t make or didn’t see.”
> “The decisions we make in our lives—in business, saving and spending, health and lifestyle choices, raising our children, and relationships—easily fit von Neumann’s definition of ‘real games.’ They involve uncertainty, risk, and occasional deception […] Trouble follows when we treat life decisions as if they were chess decisions.”
To split this hair a bit, I think “code quality” has two definitions:
1. the degree to which the code can be trusted to operate correctly and in a fault-tolerant way (i.e. “yeah that API endpoint will give you a 5xx about 2% of the time, sorry about that, just retry!”)
2. the degree to which the code optimally models the problem it’s solving, as well as how flexible it is as priors/needs change in the future and whether optimal languages/frameworks/patterns are used to solve the problem expressively.
The former has obvious customer implications — if your webapp craps out every ~20min of usage, or your API silently drops data when it can’t persist something to a data store, that’s bad, you will lose customers (and you deserve to!). Conversely, lacking in the latter could slow you down as you iterate, but you’re just as likely to not need to touch that code for a while if you’re off building new views/features/what-have-you.
I think the “don’t worry about code quality” folks are generally trying to beat it into technical founders/builders’ heads that the thing they’re building is ultimately being judged as a product, not as an engineering project... but that doesn’t mean that reliability and performance aren’t part of what may make your product valuable.