TEXT TRANSCRIPT: 21 November 2000
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

Good evening and welcome to Quality Plus E-talk. I am Carol Dekkers, and I run a company in Tampa, Florida, called Quality Plus Technologies where we specialize in helping companies to build better software. Over the past several weeks, we have spent a fair amount of time talking about things ranging anywhere from software quality requirements, software requirements and user involvement. We have talked to Paul Hopkins from Honeywell and talked to Roger Pressman last week about the Florida Election and how software has been involved in some of the things that would help or hinder some of the things going on, particularly here in Florida.

The guest this evening that we are waiting for to call in is Ed Yourdon. While we are just waiting for him to call in, I will just tell you a little about Ed Yourdon. He is really a renowned figure in the software world. On his Web site, he actually has a very interesting introduction. He says that he is a daredevil parachutist, an alligator trainer, a sword swallower, a Himalayan Mountain climber, an raconteur, advisor to Hollywood stars, concierge of McDonald's Big Mac hamburgers, and the author and co-author of more than two dozen books including one called Death March which is the tale of a very unfortunate software project, and The Rise and Resurrection of The American Programmer but prior to that, The Decline and Fall of The American Programmer. He has been to absolutely everything. I have seen him speak time and time again, and he has been excellent. He was part of the structure in Neilson's Method.

I would just like to give you an opportunity this evening if you have ever wanted to talk Ed Yourdon, or if you are already in the software industry and you would like to be able to speak live with him, who is really one of the pinnacles of our software industry, then I would invite you to phone in. Our toll free number is 866-277-5369.

Without further ado, Ed Yourdon.

Carol: I guess this is what I would call the best of just in time arrival. I would like to welcome you. I read off the very illustrious introduction that you have on your Web site. I did not know that you like Big Macs ?

Ed: Oh, absolutely, absolutely.

Carol: Well, this is great. I would like to welcome you to the show. We are broadcasting live from Phoenix. I have invited people to call if they would like to talk with you who as I previously mentioned is really one of the pinnacles and one of the gurus of the software industry, that they are invited to phone us.

Ed: Well, thank you very much.

Carol: It was great to find out that Roger Pressman actually resided in Palm Beach County. I had no idea that he did. He talks a little bit about some of the things that were going on in the election, particularly, nonpartisan and just to do with the software and lack of software and what could help us to go forward. One of the things that I thought was very interesting is that Roger said that this is kind of a 100-year storm. It is like the snowfall that comes once in 100 years. He says that the election, when you take a look at the accuracy of the results, was still within about 0.1%. And with the election being so close, it is like a 100-year storm. What is your take on that?

Ed: Well, I think that is probably true; although, I heard reports, I have not been able to confirm them, that the accuracy rate on some of these voting machines, the electromechanical ones where you flip the switch, is sometimes as high as 8% to 10%. I do not know what the average is, but I do not think any of us quite realize how error-prone and vulnerable all of this existing technology really was, because in the past, it did not really matter. Whoever won the election did so by a large enough margin that even if there was some error introduced into it, we did not really notice it. I think that is probably what has shocked everybody. The whole political back and forth accusations is kind of to be expected because, clearly, both sides do want to win. But, I think that most of us expected that if we walked into a voting booth that had even a 40-year-old machine, but one where you flipped the switch to indicate that you were voting for this person or that person, that it would be registered properly. And now we are learning that quite possibly this is not true.

Carol: Do you think that with the errors that we have ever found in error that somebody we thought got in, the past, actually had not?

Ed: That I do not know. I was just watching something on the news this evening that apparently in the state of Texas there have been at least 50 recounts over the last 20 years, I think probably at the county level. Then there was another issue on the news this evening that this famous concession speech that President Nixon made in the 1960s election, which was also rather close, about how he was not going to challenge anything and so forth. This turns out to be a myth and notwithstanding what he himself said, the Republicans in several different states did challenge the vote and asked for a recount, which obviously did not change the outcome, Kennedy still got in. I think this is part of the process and occasionally it bubbles up to the point where we all take a look at it if there is an extremely close vote or some extreme allegations of fraud. But as I have said, I think most of us have just assumed that we were using reasonably reliable technology, even if it was punch cards. This whole vocabulary that we have now become aware of, dimpled chads, pregnant chads, hanging chads and God knows what else, this is a revelation, I think, for most of us. It may be something that the voting officials have dealt with quietly in the background for all these years. I think this is a perfect example of what a normal computer project team would be faced with in a business environment with all of a sudden the business user saying, "Oh, my gosh, this system that we have been using for payroll or order entry or whatever that we have suddenly discovered that it is inadequate." We just lost a 3 million dollar account or that we just underpaid or overpaid our employees by 3 zillion dollars and we have to do something. We have to get the latest technology. That is part of what is going on these days. I have heard various reporters saying that everybody should have an ATM card and that way you could vote down at your local shopping mall or at your local bank. The assumption is that if we all had an ATM card or access to the Internet or some other razzle-dazzle technology that it would make all these problems go away, which is probably not the case.

Carol: Right.

Ed: I hope that if there is enough concern or unhappiness or frustration or whatever about how this election ended up in terms of the process of manually recounting the votes, I hope that we go about looking for an improved approach in a more measured and reasonable fashion than some of the half-baked ideas that I have been hearing over the last couple of days.

Carol: I was flying back a few nights ago and somebody on the plane behind me, that cannot be in the software industry, they were talking about the Internet and the way it is that all we have to do is have these touch screens and that somehow magically all the software behind this will just appear.

Ed: Maybe to some extent this new technology would be an improvement. It is a classic case of a solution looking for a problem to solve. All of us in the computer field have access to some really wonderful technology. We do not really stop to think very often about how often it breaks down or how hard it is to use or things of that sort. The first thing that a computer project team does is a feasibility study where they can see exactly what is wrong with the existing system and exactly what kind of improvements might we possibly expect to make if we were to bring in the "perfect technology." And that normally gets you into discussions about how a new system, using some kind of new technology, would be cheaper, faster, and better in some fashion. But given the nature of this whole voting process, it is not clear that this would actually work out. The existing system is already cheap and indeed that is part of its problem. A lot of the counties and states all across the country are using voting machines that date back 40 or 50 years. At least here in New York City, where I am calling in from, they are not really maintained very well which means that they continue falling apart. Meanwhile, the whole manual part of the process including the counting that is going on down in Florida is done largely by volunteers who, you know, are paid nothing. So, yes there is a cost associated with it and maybe if we could get rid of the punch cards and all the people that have to carry the punch cards back and forth and so on, we might achieve some savings, but I suspect that the high-tech solution would be more expensive and while it might be faster it is not clear that this is all that is necessary.

Carol: Right.

Ed: The politicians are jumping up and down saying that if we do not get this recounting thing finished up instantaneously that the whole country is going to fall apart. It has given us all something in common to talk about. Dave Letterman can make jokes about it every night. The country is clearly not in a state of crisis yet.

Carol: Right.

Ed: It might be by mid-December. The idea of new technology that would let the entire country know the outcome of the election within 3 microseconds after the polls close, you know, that is not something that most of us would be willing to spend a lot of money for.

Carol: Would you say that this is similar to some of the other systems we have in place, which would be on a county or a municipal level, things like even the criminal justice system and/or the police system that are clearly a patchwork quilt, very much similar to an election process but they are much more relied on. You have really a patchwork quilt of interfaces between unlike systems with different requirements, different builders, different ages and those types of things. How can you ever hope to have one seamless system unless you start it all from scratch?

Ed: Well, that has been one of the proposals, that there is nothing in the Constitution that gives Congress the ability to impose nationwide standards on the voting of the President and Vice President. Apparently, it is always delegated down to the state and county level. Apparently, there is a little clause in the section describing the legislative branch of our government that does give Congress the right to impose nationwide standards on voting for the Senate and Congress but not for President and Vice President. So, we would need an amendment even to do that. You know, that is of course, the kind of utopia that we computer people love to think about, wouldn't it be nice if we would just throw out all of our technology from the old mainframe computers and jump straight into the 21st century and avoid all of these really messy problems of patching things together. It could be done if the country was sufficiently disgusted by this whole thing. It really would be wonderful if you could be sure that you were going to be using the same kind of equipment and the same procedures no matter where you voted in the country. Every time you pick up a telephone at least you know where the digits on the telephone are, and how to dial a long distance number, these are fairly well standard. Actually, working through the details of this, I think we would discover that it is a lot more difficult than people expected it to be.

Carol: We will be back shortly with more of Ed Yourdon and a discussion about this election and the future of technology...Welcome back to Quality Plus E-Talk. Our guest this week is Ed Yourdon and we have been talking a little bit about the Florida Election and what we could do in terms of investing in technology that might solve the problem. Approximately a month ago, I was at a conference with Ed Yourdon and he did something quite unique. As you could tell from the introduction, Ed is a unique individual. His career spans several decades. I remember when he first came up with the Yourdon Structured Analysis Methodology, and I had to take the courses in that. I never at that time realized that I would have you as a guest on my show, I am very pleased with that. One of the things that Ed did at the 10th International Conference in Software Quality that the American Society for Quality does, is that he talks about a new notion called "Pay it Forward." Ed, if you want to explain a little bit about what you did and what you meant by that before we get into the topic.

Ed: Sure. Well, I want to point out a thought that is something that I picked up elsewhere; I did not invent it at all. It is the title of a book and actually a movie that unfortunately was not done very well but opened about a month ago with Kevin Spacey and Helen Hunt and the child that was in the Sixth Sense. It is a very simple idea that if someone does you a favor rather than paying it back or ignoring it altogether, that you might reciprocate by paying it forward. You know, passing it on but in kind of an expanding chain. If somebody does you one favor, you pass on the favor forward to three other people and each of those three passes it on to three others and so on. The reason that I was suggesting it, particularly in the context of quality assurance in the computer field, that is a bottom-up grass roots approach to making things better as opposed to the top-down approach that you see in most business organizations, and frankly in many government and social movements as well. The idea that the president, or the boss, or the CEO is going to figure out how to make things better and then the issue of edicts and orders that will ripple downward through the hierarchy to cause things to be done in a different fashion. Sometimes, that is important, particularly if you have a charismatic leader who can help break some kind of stalemate or paralysis in an organization. But I think in a lot of cases, it is going to have to come from the bottom upwards, and that was what I was trying to suggest in that conference and to help reinforce it. I made sure that everybody in the conference had a copy of the book. I also told them that I was prepared to follow my own advice by offering a "Pay It Forward" favor to two or three people in the conference.

Carol: That was a very powerful way, I think, of getting that message across that quality really starts at home, that quality starts with every piece of software that anybody really touches. We have spent a few shows talking about what constitutes quality and do we have a misalignment in expectations on the part of the users with what the developers produce and that type of thing. There are really no slick and easy answers. But one of the things that I think is really powerful is that it does start at home. That quality does start at the bottom with everybody in the organization.

Ed: Well, it is also easier to sell the idea if you can demonstrate the personal benefits to yourself and to the people that you have immediate interactions with. Again, what you normally see in most organizations, and not just in the computer field but in all different aspects of quality, is this top-down directive that says for the good of the company and to improve corporate earnings and to make the shareholders happier we hereby direct all of you bottom level peons to do X, Y and Z which often makes their life worse. It means that they have to spend a longer time in the office trying to do a good job, which of course, they would like to do. But they do not get any immediate personal gratification out of it. Nor do they necessarily see that their immediate peers, the people surrounding them, are necessarily any better off. It may turn out that a year later corporate earnings will go up by a penny a share but that does not necessarily translate into things being better for yourself.

Carol: Right.

Ed: It has been interesting to see a variety of movements that are bottom-up grass roots things. Some of the so-called best practice movements are 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 in order to achieve these worthy goals. One of the interesting things that was done four or five years ago by the same organization, the SEI, was to develop a bottom-up approach. This is something that could be practiced at the grass roots level by individual computer engineers. As you were mentioning during the break, even the users and customers and the people who actually have to interact with these computer systems to achieve higher levels of quality, which indirectly and secondarily, will make things better for the company as a whole. But firstly, and foremost, achieve some personal benefits for themselves and therefore will be a lot more interesting and desirable to put into effect.

Carol: The message that you are talking about is something called PSP or the Personal Software Process.

Ed: Yes. This is an idea that was created and then written up in a book called, I think it is called The Discipline of Software Engineering by Watts Humphrey who was the father and creator of this whole thing. He merely pointed out that many of the concepts and key practices that are recommended by the SEI CMM to be accomplished in a top-down/company-wide fashion could also be done in a grass roots fashion. Things like inspections and reviews, or things like improved requirements specification techniques. There is no reason why one individual business user might not be able to make some improvements in the way he documents or describes his requirements for a new system, just to make his own life better even if the rest of the company does not do it, and even if it does not achieve instantaneous corporate earnings improvements.

Carol: Really, the personal software process is the way of applying a discipline to things that individuals do, to actually become more repeatable, to build on the things that are best practices. I think Watts Humphrey in the creation of it even worked on balancing his checkbook as an example on how to apply better discipline and get better productivity and better quality out of balancing even a checkbook.

Ed: Yes. As I recall, a lot of what he talks about in that area, including even such mundane things as balancing your checkbook, is keeping measurements of what you are doing and how many mistakes you make and how often you have to redo the work so you can see where you need to make the most improvements. One of the key things about this kind of approach is the notion that the recommended procedures, whether it is new procedures for balancing your checkbook or anything else, should be presented to people on a voluntary basis rather than rammed down their throat in the form of do this because we have decided it is good for you. There might be 10 different ways of accomplishing a better job of balancing your checkbook or writing computer programs or documenting user requirements in a way that is best for you under your circumstances but might not be the best thing for me in my circumstances. The assumption is that you and I are intelligent people and want to make our own lives better. We can be trusted to choose the best practice for ourselves.

Carol: One of the things that I can just kind of hear in our audience, if they have been in software or they have been a user or a customer, they are pretty much saying that is not today's society. Today we are in Internet speed, we are in lightyear speeds, we need things faster, better and cheaper. All of these traditional methods just are not going to work. We need something that is going to help us build Internet systems faster. Like the person on the plane, who said, "You know the election process, all you need to do is build a touch screen indicator, there is nothing to it." I have heard that especially amongst the Silicon Valley type of companies, the dot-coms. If you go through a structured process and you take two months or three months or whatever, gosh, business will not even be there. What are some of the approaches that have started emerging for some of those people, for some of that type of business environment?

Ed: Well, the buzz word that all the computer people talk about in this area that you have just mentioned is called XP which is an abbreviation for eXtreme Programming. The more general term that people use is so-called light methods or processes or methodologies versus heavy processes. If you are building a nuclear reactor or a guided missile system, you want very rigorous detailed formal rules and processes to carry out because lives are at stake. On the other hand, if you are building something that really has to get down and be finished within a couple of weeks, then whether you want to or not, you just do not have the time to carry out and follow all the very rigorous formal policies and practices. Again, it is something that needs to be chosen on a case-by-case basis rather than trying to come up with a set of universal rules. For example, if you were building a dot-com system in a situation where the customer really does not have any idea at all of what he wants to do, he really does not have any good idea of his requirements, then you are wasting your time to try and do a very formal job in that area. On the other hand, if in that same project you are constantly changing the code and recompiling and putting up a new version every other day, you had better have very formal, very detailed processes and rules for so-called configuration management or version control. Because if everybody is changing the code simultaneously and you do not have a very rock-solid process for keeping track of whose version of which component is being incorporated into the current build of today, then everything is going to collapse in a state of chaos. So the decision about which processes and methodologies are going to be carried out rigorously in detail and which ones are going to be done in a more ad hoc fashion needs to be adjusted based on the circumstances and the size of the project, you know, what is at risk and so forth.

Carol: Right. Now, one of the things that is conjured up when I hear the word "extreme" and with X-games and ESPN and that type of thing, is that I would assume that eXtreme Programming is just the latest excuse to abandon good method.

Ed: No, actually not, there is sometimes the concern on the part of managers. What it means is abandoning the things that (a) you don't have time to do properly anyway and (b) the things for which the consequences of a failure are relatively low. Also the things that you probably would not be able to do perfectly even if you had all the time in the world.

Carol: Right.

Ed: Again, the very formal classical way of carrying out a software project that my friends and I first began talking about 30 years ago, is to get very detailed formal requirements for what the system is supposed to do. Now, you could probably do that for a payroll system or even the voting system that we were talking about a moment ago. But when Jeff Bezos sat down to conjure up the whole idea of Amazon.com five years ago, he had no road map. No idea of exactly what it was that he wanted to do. There is just no point spending a lot of time trying to carry out that part of the task.

Carol: We will be back shortly with more of eXtreme Programming, Ed Yourdon, and Quality Plus E-Talk with Carol Dekkers... Welcome back to Quality Plus E-Talk. My guest this week is Ed Yourdon who is a renowned expert in the area of software engineering and has written quite a number of books. We started out talking about the election, the American election, which is still undecided at this point. We have moved into kind of a discussion on eXtreme Programming which is one the latest buzz words in the software industry which is really a light methodology where we take anything that is nonproductive or wouldn't necessarily be worthwhile doing, like very, very detailed requirements analysis and poring over them infinitely when you do not even have good requirements. Ed, let me just ask you this, it seems like every five years there is a new methodology, the latest and greatest thing next to sliced bread. We had rapid application development or RAD five years ago, what is new and exciting and not just a regurgitation in eXtreme Programming?

Ed: Well, I think eXtreme Programming incorporates a lot of the best ideas from RAD. In fact, the originators and proponents of XP actually came out of the small talk community, which even predates RAD. So the whole idea of iterative evolutionary adaptive development, you know, that is something that people have recognized and described with various buzz words for most of the time that I have been in the computer field. I will give the XP people credit for throwing in additional ideas or emphasizing some additional ideas as well. The idea of insisting that you write test cases before you write code is an idea that people have talked about but not usually with the same degree of passion that you hear now. In fact, you could carry that back to our business users and say to them before you even write a specification, write down the test case that you would be willing to accept as a demonstration that the requirements have been meet. That eliminates these fuzzy requirements like "the system shall be user-friendly." Well, that sounds great but what kind of test would you impose or be willing to accept.

Carol: And what does "user-friendly" mean?

Ed: Precisely. It sounds good. It is one of those evocative terms. So the XP people are saying before you write requirements or before you write any code, the first thing that you better do is describe the test that will determine whether it has been satisfied or not. That's a good idea. The idea of team programming, pair-wise programming, which as you were saying during the break, we used to practice 20 or 30 years ago out of necessity because of limited hardware is being advocated again. There are half-dozen ideas that the XP people have incorporated into kind of a whole way of thinking and working on projects to help accomplish what everybody is so desperate to do and then we're speeding things up so that we actually get good results, quality results, that we can all be proud of but in a lot faster time than before.

Carol: It is not going to work for everything. I have done some research and I am doing a presentation in February in San Diego on Extreme Programming Meets Measurement and some of the things that you first looked at are not things that you necessarily want to embrace. I know that other things such as the pair programming which as you said was a case of necessity when we had punch cards. I spent my first year of engineering actually having to do punch cards. But you certainly did not want to wait a full day for your run to go through and then have it bomb again because you had a decimal point out of place.

Ed: Or even in the early days of time-sharing when a terminal cost $3,000 you could not afford to buy one for every programmer. So, literally, two people would sit in front of a keyboard or a CRT and would code together. Again, those are things that we did out of necessity without always appreciating some of the benefits that we got out of it. Two people working together provide a continuous review and feedback and similarization process that is extremely valuable.

Carol: I think one thing that you have said, that we have alluded to in a couple of the shows, is that if you cannot test it, if you do not know what the testing criteria for it is as a user, that the user community has been able to get away with this. And this is not blaming them, but they were able to get away with for many years saying, "I kind of sort of want something that kind of sort of does, blah." The developer community says, "I know exactly what you mean." We have always had this myth. This extreme programming forced the user community to be more precise.

Ed: Yes, it is a very good discipline, I think, or it at least it forces them to acknowledge that they are in an area of undefined research. I mean, it is fine to say we are going to try out some ideas and we have no idea if it will work or not and we will just keep endlessly prototyping and experimenting if you happen to work in an R&D company. But if you are in a situation where you are supposed to deliver working results at the end of some period of time, then we need the discipline of forcing ourselves to be precise when we need to.

Carol: I think some people may be listening and saying why would software developers, why would these keen programmers even start working unless you have something solid to start working with... We will be back to wrap up with more of Ed Yourdon after these short messages... Welcome back to our final segment of Quality Plus E-Talk. We have been talking this week to Ed Yourdon who has written a number of books including The Death March, The Rise and Resurrection of The American Programmer, and he has been involved in modern structured analysis techniques for many years. We have talked about eXtreme Programming. We have talked about new processes and the types of things that are going on in the software industry. We have a caller who will talk to us very quickly and then we will wrap up with Ed Yourdon.

Caller Deborah: Yes, I have question, you have talked about the eXtreme Programming but I was wondering if you could highlight when possibly management might choose the wrong time to go to eXtreme Programming, project managers, or executive management might choose eXtreme Programming versus the normal methodology.

Carol: Ed, I will let you jump into that one.

Ed: Well, the most unfortunate version of that would be the case where management looks at XP as some kind of silver bullet that is going to provide miracles. Unfortunately, that has been a common tendency for the last 20 or 30 years, that managers who are under a lot of pressure and who are desperate for tremendous improvements or breakthroughs in productivity or quality will grab whatever tool or process or methodology seems to be the current fad of the day. I think there are some really solid ideas behind XP but I certainly see your point that there may be situations where it is just not appropriate, particularly in a safety critical system where you really want to make sure that you have done the job right and that you have software that is rock solid even if it has to be delayed. So, yes, if I was working on a space project or an aerospace system or defense contract or something like that or a nuclear reactor, XP might not be the appropriate way to organize the whole project. It would be a shame if management tried to impose that regimen or that whole approach on a project team. One of the strongest things that I think we are going to see more of in the future is more of an understanding that the project teams themselves have to come up with the strategies and the tools and techniques because they are the ones who actually carry it out.

Carol: Right. I think Deborah makes a good point, that sometimes in the middle of a crisis project, where things are already behind schedule, there has been so much change that management will go in and inject a new process and say here is a savior, lets parachute in a hero with an XP on his chest emblazoned that will rescue this project. Unfortunately, sometimes that works and then that can impose some future projects. Kent Beck who is going to be our guest on December 5th wrote a book on eXtreme Programming and he says anywhere from 3 to 10 programmers is the maximum team size and maximum project size that you would ever want to attempt for a project.

Ed: I think that makes sense. They can all fit into one room. They all have a common goal. They can all talk to each other and so on. You know an awful lot of the systems and projects that are underway today do fit into that size range, and they are projects where speed is perhaps more important than anything else. But if you are building the next generation of Boeing Aircraft or if you are building the next generation of the smart nuclear bomb, then you probably want to follow a different approach.

Carol: When you are building a smart nuclear bomb, I do not think the requirements are going to change dramatically on a day-to-day basis. They may not be solid to begin with, but you sure hope that you are spending millions and billions of dollars toward, hopefully, a goal.

Ed: Not being a military expert, I hesitate on that one.

Carol: I have to say thank you very much to Ed Yourdon. We are out of time today. We have Mark Paulk of the Software Engineering Institute who is going to be our guest next week. We have Kent Beck who is the author or eXtreme Programming who will be our guest on December 5th. I would like to say thank you very much to Ed Yourdon. Ed, you have two seconds for your Web site - actually I will give it out: www.yourdon.com, and there are some exciting things on his Web site. We will see you next week for Quality Plus E-Talk.

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.