I believe that software has two types of quality: internal and external. External quality is understood by your clients: it’s the number of features, the ease-of-use of the software the slickness of the UI, amongst other things. Internal quality is understood by your developers, it’s about the code and includes measures such as code coverage, cyclomatic complexity, coupling and cohesion as well as elegance and simplicity of solutions.
There is a very interesting difference between these two types of quality. If you reduce external quality, you get to market quicker. If you reduce internal quality, you get to market later.
For external quality: if there are fewer features, the system is ready sooner. If you don’t need to spend time analysing user interactions or polishing the UI to pixel perfection, the system is ready sooner.
For internal quality: if the code is elegant and well designed, then it is easily understood, changed and repurposed to new uses; the system is ready faster. If code is covered by tests, then you know that changes haven’t broken it and you can be more confident and agressive with refactoring and other changes; the system is ready faster. If code is reviewed or pair-programmed, then it has far fewer defects; defects found in UAT or, even worse, production are far more time-consuming to fix than if they are found at the moment the code is written; the system is ready sooner.
So my advice is, if you are in a situation where there is real business value in getting a system to production fast, then do not sacrifice internal quality (increase it if you can) and only sacrifice external quality.
And bear in mind, clients understand external quality. You can work with them to make the appropriate trade-offs for the project. If time-to-market really is key, and external quality matters, but not as much, then the clients will allocate time to address that quality in the future - something they will rarely do for internal quality.