that. So what he's saying, essentially, is that nobody ever does it right the first time. But what he goes on to say is the result of that is that everyone who's involved in developing software, specifying, developing, implementing software, should spend their time looking for defects and trying to remove them from the process. The earlier the better, of course, but at any point, removing defects from the process. And this is a real change in mindset, a real change in attitude. If you take sort of the old-fashioned approach, if you found a defect in your code, whether you found it before it was implemented and the user started using it, or whether you found it afterwards, that was a bad thing. That was something wrong with you, because there was a defect in your code. There was something you did wrong. Well, what Mr. Canuth is saying, or Dr. Canuth is saying, is every defect you find should be a good thing, it should be a cause for rejoicing. Because that's one more defect that won't get out to the users.
Carol: Right. And I know, having been in software development, that oftentimes there's a sense of blame, that nobody wants to be responsible for a defect. Rather than celebrating that a defect was found before it went out in the code, before it went out to the users, people would lament and say, oh, you know, it's not my fault because of ……., rather than saying, hey look, I found something and detected it early!
Carol: And that is a cultural change. That's being able to work as a team and saying, you know what, something got in here that wasn't right. Let's make it right. And even if we look at the building construction industry, which is thousands of years old, having built a house, I know that even the master electricians who had 30 plus years of experience, sometimes put the outlet in the wrong place. And that's, you know, master plumbers, master electricians, they don't always get it right. So I guess it's kind of unrealistic for us to have expected software to be perfect.
Frank: Right. And I guess there's a natural analogy here. If you look at the total quality management movement, and where we've come with total quality management over the years, there used to be in the '50s and '60s, in this country probably even into the '70s as well, this concept that quality is the responsibility of the quality assurance department. We just produce stuff, whether it's manufacturing, or whether it's a house, or whatever you talk about. And then there's this QA group down at the end of the line that's going to inspect the quality end. And that was a very disastrous approach for many industries. I was in the steel industry for awhile in that time frame. It was a disastrous approach for us when other companies, Japanese most notably in that time frame, were building the quality into the process. And that's really the change in mindset. It's not that… If you take the analogy back to software, quality isn't the responsibility of the testing department, who's going to test the software after it's all written. Quality's everybody's job.
Carol: And on that note, we're going to go into a few messages. And we'll come back and talk to Frank Mazzucco of COMPASS America about exactly what quality means and where we can go with process improvement.
Welcome back to Quality Plus e-Talk! We've been talking to Frank Mazzucco of COMPASS America,