grass roots efforts--find software practices or developing practices or quality practices that make sense at your level and your own little world rather than doing it because the quality police tell you that you have to.
Carol: And sometimes what I have found is that management kind of has this motherhood idea that they will decree that quality will improve and then middle management has no clue as to what that means.
Ed: Well, middle management is caught literally in the middle because on the one hand they are being told by senior management to make things better but on the other hand they are judged and punished and rewarded according to very short-term criteria of getting projects finished on time and generating revenue in line with quarterly Wall Street expectations which really makes it tough for them. Then they pass the pressure on down to the people that they supervise. It is a very tough sort of thing. You know, it is interesting that in the software industry we have been coping with this for about the last 10 years with a very elaborate and a very highly respected approach developed by the Software Engineering Institute, the so-called SEI CMM approach.
Carol: I think that the process improvement is something that we will talk about as soon as we get back with Ed Yourdon and Carol Dekkers with Quality Plus E-Talk...Welcome back to Quality Plus E-Talk. If you are just joining us, I am Carol Dekkers. I run a company that helps software companies to build better software. Software that actually runs and meets the user requirements. My guest this week is the famous Ed Yourdon of Yourdon Structured Analysis Approach, in case anybody is listening who has a mainframe Computer Science background. He has also been involved in just about every field to do with software. I am not going to ask you about your alligator trainer or your sword swallowing or rather if those are really real or fake, but I would not doubt that you probably have attempted to climb at least one Himalayan Mountain.
Ed: No, I have to admit that was a bit of an exaggeration.
Carol: Well, we have had other guests who have incredible backgrounds, so I would not put it past you. Before we went into the break, we were starting to talk a little bit about the Software Engineering Institute's Capability Maturity Model. We have talked about that on the show before that it is really an assessment of how mature a software development organization is. You were going to mention a little bit about where that kind of leads people, I think.
Ed: Yes. It is an idea that has been around since, roughly, 1989, so it is 10 or 11 years old. It is interesting that, at this point, after a full decade that only 15% of American IT organizations have even bothered going through an assessment to find out where they are on that scale. When it happens, it is usually done on a top-down basis, that is a senior vice president or a CIO says we better do it and it is very important for the long-term good of the company to achieve a level 3, 4 or 5 on this scale. The problem that I was describing just before the break, is that while this may be very beneficial for the company as a whole, it often has short-term negative consequences for the practitioners and the computer professionals and the engineers down at the bottom because they end up having to work harder and longer