> The user doesn't know how the codebase looks Technically true. But the user knows when code is in a poor state. A poor C codebase in a security critical area

> The user doesn't know how the codebase looks Technically true. But the user knows when code is in a poor state. A poor C codebase in a security critical area users will find out about. It will crash, need critically patching all the time etc. If a game engine has a messy code base (Say, they have two slightly different renderering subsystems which makes things clumsy) then people will notice because the games will be late, buggy, cancelled whatever. For most users though it's that the software is slow, costly, buggy, doesn't get new features quickly and so on. And you can't really tell the reason why. But users DO notice it. Managers certainly notice it. Any manager should recognize a situation where you spend 80% of your time on bugs/regressions, while new features get less time, and take much longer than aticipated to implement. And any manager should instantly recognize that this is invariably due to a poor-looking codebase. Not poor communication, not (other than indirectly) because of bad developers, not poor tools, not anything else. Just messy code.