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