What sacrificing quality gets you according to Kent Beck ...

Here are two passages from Extreme Programming Explained by Kent Beck that figuratively made me shout "AMEN!" at the top of my voice:

Temporarily sacrificing internal quality to reduce time to market in hopes that external quality won't suffer too much is a tempting short-term play. And you can often get away with making a mess for a matter of weeks or months. Eventually, though, internal quality problems will catch up with you and make your software prohibitively expensive to maintain, or unable to reach a competitive level of external quality.

and

There is a human effect from quality. Everybody wants to do a good job, and they work much better if they feel they are doing good work. If you deliberately downgrade quality, your team might go faster at first, but soon the demoralization of producing crap [emphasis mine] will overwhelm any gains you temporarily made from not testing, or not reviewing, or not sticking to standards.

These two passages appear in his discussion of the three familiar control variables in software development - quality, time, and cost - and a less widely known one, scope. In the extreme programming methodology (XP), management gets to pick the values of three of the variables and the development team picks the value of the fourth - without exception.

Beck's position is that quality is a horrible variable to mess around with - either by explicitly demanding low quality or by picking the values of the other three variables such that the implied quality is low. He instead advocates that the fourth variable, scope, is the best one to fiddle with. By reducing scope, you can give quality room to breathe, reduce cost, and deliver on time. Assuming that quality is fixed reasonably high, by increasing scope you imply either an increase in time, cost, or both. And so on.

The book is really good (so far, I haven't finished) and I especially encourage all management types to read it.