I often hear from engineers in the game industry that code quality doesn't matter (or doesn't matter much) because the user doesn't care how the game is made.

But while the users don't care, the developers do (and should) as they have to live in the messes they make, often for years. The people who care most of all should be the producers who are accountable for the overall budget of the product. Further, there is a connection between code maintainability and polishability of the end product. Not to mention bugs that creep out to the user because they were obscured by bad, bloated code.

So it is a fallacy to say that code quality doesn't matter just because the user doesn't care how the end-product was put together. That the end-user doesn't see the connection between the code quality and the resulting game experience doesn't mean there isn't a connection and that it didn't affect the product's development cost and time to market.

--BryanEdds

----

Not game specific, but the user does begin to care when they decide that they want one more little feature, and you tell them that it will require a massive rewrite.  They really care if the structure makes it too hard to use and there's no easy way to change that.  Or if they buy out the codebase, (or after you stop maintaining it, you hand it off to volunteers to continue modding it) but they can't do anything with it.  They care if the product is delayed for weeks or months while tracking numerous bugs through the spaghetti.  Or worse yet, launched with critical ones that no one was able to test for because the structure was too sloppy for proper testing.  

Of course, they don't blame it on code quality, they blame it on incompetent developers.  Six of one, half-dozen of the other.  (To them - we know that competent developers can produce low-quality code, for example, during deadline rushes, budget cuts, etc., but that's not what they're thinking of.)

----
Related: ItIsBrokenBecauseYouThoughtItWasFine