I follow Kent Beck in making a distinction between internal and external quality. The pleasantness and effectiveness of a user-interface is external quality as it’s something that can be perceived by the users of a system. That is something that can be sensibly involved in a trade off – do I want extra work on making feature A easier to use or should I add feature B?
The internal structure of the software, however, is not something that’s directly perceivable by the user. I can’t tell from using a program whether its internals are constructed well or not. Internal quality is thus a more hidden attribute. When someone says we should do things reduce the design quality of a system to build more features, that person is applying the tradable quality hypothesis to internal quality.
Hidden in this reasoning there is the equation that lowering quality you can go faster: as Martin says this is true only in a really really short time frame but this is not the worst effect:
But the tragedy is that as soon as you frame internal quality as tradable, you’ve lost. [...] Instead it’s vital to focus on the true value of internal quality – that it’s the enabler to speed. The purpose of internal quality is to go faster.
What’s your experience on this topic? How’s the “quality tradable hypothesis” is seen in your team? Under which circumstances high quality means going faster?