Post Quality Control in Software Development

I've read some articles about the Balanced Scorecard (www.balancedscorecard.org) management concept. It is quite new management idea developed in the early 1990's by Drs. Robert Kaplan (Harvard Business School) and David Norton. It deals with the performance management concept and here are some thoughts on the software development process, which came to my mind... As it is appear to me more of the methodologies and disciplines intended to deal with the software development process, trust too much on the post quality control. A lot of organizations adopts particular software development methodology hoping to improve their product quality. Often the problem actually comes from the "adoption" process. The organizations rely and spent too much effort on performing post quality control activities. Words like "zero defect" and "defect convergence" became a labels for a software project success. However testing, inspecting and simply doing a defect fixing is just not quite effective. Defect fixing may be quite expensive process:

• it takes time and the user may not use the solution to do his job until the defect is fixed (if the solution is in production)it takes resources (managers, developers, time, money, etc.) and probably these resources will not be paid back by the customer.
• it is always a risk to make changes - the later during the life cycle, the bigger is the risk.

The post quality control in most of the organization has only one goal - defect fixing. This way the organization continuously spends constant resources on defect fixing but never tries to identify the reasons for the defect injection and decrease the quality control cost. Often people think like "We have this post quality control process, so we will design and implement it fast, cause we chasing deadlines and if we have defects we will fix 'em later"- this psychological trend may increase the cost of the post quality control. And as always the most practices and concepts share common basic ideas, which float around the culture space during a particular time frame. My point is that the reason for these trends in the current development methodologies and practices used is that they are inspired by some world-wide management practices used during the time, when the methodologies were published - Total Quality Management (TQM) for example. What we need is a quite new software development paradigm...