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.
Ed: Again, the very formal classical way of carrying out a software project that my friends and I first began