No, the customers only care about working software, not maintainable, perfect software.

Technical Debt is about taking shortcuts to have something working now, in exchange for more work maintaining and evolving it in the future. If the software doesn't work, it's not debt, it's a bug.

If you are not changing the software, it doesn't matter that a list is hardcoded instead of parameterizable, that the modules are tightly coupled and can't be reused, or that the build must be done following a particular set of incantations in a specific machine. If you are, these are all examples of debt that will come back charging interest.

Properly planned and managed, technical debt is a tool much like actual debt (a loan) that can accelerate your growth and your time to market. Thing is, most teams don't know that they are taking on a debt and don't realize how much interest they are paying each day.

I think the path toward optimizing software for (a) maintainability (b) completeness and (c) bug-free are not necessarily mutually exclusive. I think in general software is fighting all of these battles simultaneously. And so by definition software that is incomplete (ie. without all the features) has the possibility (probability?) of being buggy. Otherwise if it's complete why add features?

Given what you knew at the time you created a definition, and per that definition you could have written 100% maintainable 100% bug-free 100% complete code. It's in uncovering your lack of/ incomplete understanding of your problem that you may need to go back in to that code. Even though at the time it was considered 100% bug-free, complete, and maintainable.

100% maintainable software is NEVER a goal. A hard coded list that will never change is better than a configuration file that needs to be installed someplace and loaded as runtime. If you are right that the list will never change you have made the software more maintainable as you never have to deal all the code to load the configuration from whatever path the user has installed it to. If you are wrong though you will have a lot of work tracking all the releases and what is hard coded in each until you retrofit a loader.

This is the type of choice you need to make upfront often when designing software. If you get it right your system is more maintainable. If you get it wrong your system is less maintainable. Sometimes you don't know in advance which is right.

Technical debt doesn't make the software worse, it makes the codebase worse which degrades the ability to maintain and add features in the future (which is paying interest on the debt, so to speak).

So, in the context of oldschool console video games that ship and then end development permanently, it's absolutely a reasonable decision to add some technical debt if it means fitting one more nice-to-have feature in before launch. Because you don't pay interest or pay down that debt ever. The code is shipped and then it retires, presumably.

The days of fully offline games are long gone though. It doesn't mean that game studios take on less ambitious projects though. Most games are superglued together to get over the finish line and shipped with a massive day-1 patch.

Agreed, the parent mentioned GoldenEye for N64 but it definitely isn't true for modern games

Probably wasn't even true for GoldenEye. They used the same engine for Perfect Dark; sure the assets and game scripts would be changed but the multiplayer code had to be ported and cleaned up I'm sure.

The key defining characteristic of technical debt though is our inability to accurately estimate its true cost. If we could frame the question like you present it the battle would be won