STATEMENT OF FREDERICK PHILIPS BROOKS, JR., KENAN PROFESSOR OF COMPUTER SCIENCE, UNIVERSITY OF NORTH CAROLINA, CHAPEL HILL

Mr. BROOKS. I am Fred Brooks from the University of North Carolina at Chapel Hill.

I have come extemporaneously to this hearing from another meeting on another subject.

Senator WARNER. Well, we are grateful. If you could state your history that qualifies you as an expert witness and then give us your judgment.

Mr. BROOKS. Twenty years ago, about a thousand very able people under my direction built the largest software system that had been built at that time, the operating system and compilers for the system/360 family of computers. This, at the time of delivery in 1965, was about 10 million bytes of code. This system and its evolutionary descendants are still in use today as the MVS operating system for almost the entire IBM middle and large product lines. We have been through a lot of learning in that process.

I would like to make several points, but I will state the net position first. I see no reason why we could not build the kind of software system that SDI requires with the software engineering technology that we have today.

Now, may I make a few other brief points. I had a chance to discuss this issue in a public session with my good friend, David Parnas who, was at Chapel Hill some years as a colleague.

Senator WARNER. And for the record, he is-

Mr. BROOKS. He is Lansdowne Professor of Computer Science at Victoria University.

Senator WARNER. And he is referred to extensively in an article which we will incorporate in the record at this point, or at some point in this colloquy, in the Washington Post today.

[The information follows at the conclusion of this hearing.]

Mr. BROOKS. He has published a set of eight little papers, which are appearing in Software Engineering News and the American Scientist, in which he details his technical arguments as to why he thinks SDI software is not feasible. So the sponsors organized a panel discussion on the subject at the Eighth International Conference on Software Engineering in London this past August. It was my opportunity to appear on the panel. Professor Parnas and I agree on some things, and we disagree on some things.

The foremost matter on which we agree is that I, like he, believe there is no magical software technology coming over the horizon. I see no development-artificial intelligence, new languages, work stations environments, program verification, and so forth-I see no single development that will give us as much as an order of magnitude improvement in our ability to build software in the next decade.

Therefore, I grant that if one cannot foresee how to build the SDI software with today's technology, one should not believe that he can build it at all. I think the central technical question is, "Can it be built with today's software engineering technology?”

Now, I think there are some straw men in Professor Parnas' arguments. One of them is, he seems to take as a criterion of success

the construction of an absolutely perfect system that has no flaws. I think the real requirement is that it be perfectly guarded against catastrophe; but if the system, for example, assigns two weapons against one threat when it should have assigned one, that is not a flaw one would lose sleep over. He argues that since it has to be perfect, and since such a system by its very nature is very complicated, then it cannot be exhaustively checked and tested.

But we cannot exhaustively test even a half-inch square microchip. In fact, we use a variety of testing techniques to establish the reliability of everything we do in the computer field without exhaustively checking all the possibilities.

Now, I would not be so bold as to assert that the SDI software can surely be built. What I would say unequivocally is that it is much too soon for gloom. The problem is not sized. One hears people talking about 10 million lines of source code; but I have seen no basis whatever that leads me to believe that 10 million is anything other than a guess.

We have many years of experience with the testing of complex software systems-not only testing but gaming, in which adversaries take computers and put them in the same system with the system that one is testing, using the computers to make up disasters to which the system under test has to respond.

That was done on the Apollo program. IBM delivered five system/360 model 75 computers to that program. Four of them were used for planning and simulating flights. One was in the hands of the black hat team. They used it to inject made up troubles into the system. All day every day, for years, the Apollo ground controllers practiced against the troubles that the black hat team synthesized with their computer.

The SDI system has a major difference from the Apollo system: it is against an intelligent adversary instead of against nature. But we have experience with many kinds of software systems that are military and defense systems, and we have testing procedures that are routinely used for those.

The next point I would make is that the hazards and uncertainties that Professor Parnas describes are common to all defense systems, present and future. You do not know what the opponent is going to do; you do not know what technology he will bring; you do not know which parts of your system he will knock out; you do not know which parts of your system will be electronically jammed. These are the hazards that we face in all the defensive systems that we have today.

This is true not only of our defensive systems; these hazards face us in our retaliatory systems. We live today under the shadow of those uncertainties.

The fact that a defense is difficult to build and its effectiveness when called upon is ultimately uncertain is not a reason not to attempt one.

I myself have not arrived at an informed personal opinion on the wisdom of the whole SDI system, and I am not sure anyone can at the present stage. Nor have I an informed opinion on the feasibility of developing the hardware. But with respect to the software I see no reason why I or any better software manager and there are many-could not build such a system.

Some properties make this system easier to build than many others. There are some pluses. Defensive systems have some advantage over offensive systems in terms of the limited types of catastrophes that can happen. I believe that the most important ingredient in building a very large software system is plenty of calendar time in which to do it. Because the hardware will take a long time, I think the software people have a chance of having enough calendar time. I have talked to people who have been working on the system-and I have not worked on the system-who see the possibility of a high degree of decentralization and independence of operation of the parts of the software system. That is a tremendous advantage.

The task should have plenty of priority. It should have plenty of resources. Something which I consider a very great advantage is that everyone believes it will be hard. Therefore, the danger of brash overconfidence, which has characterized many software efforts, is radically diminished. Everyone thinks it will be hard, so the builders will go at it with much caution, close attention, and a limited and modest set of objectives.

That is the best insurance of success.

I think it can conceivably be done. I agree with Professor Parnas that it cannot be done in a business-as-usual military system-building environment. I think it will have to be a Skunk Works of some kind, as the Polaris system was, for example. That is the only hope that I see for building such a system. But I see no reason why we should not proceed on with the feasibility investigation and a preliminary design to find out what the troubles are.

Senator WARNER. Thank you, Doctor.

For the record, Skunk Works is a laboratory I think primarily under the jurisdiction of Lockheed that has developed some very fine aircraft.

Now, Dr. Lipton, if you could briefly state your credentials and your views.

STATEMENT OF RICHARD LIPTON, PROFESSOR OF COMPUTER SCIENCE, PRINCETON UNIVERSITY

Mr. LIPTON. Yes; I am professor of computer science at Princeton University, and I was on the panel that was convened in the summer to look into these problems that Professor Parnas wrote about his attack against the SDI plans. I would like to say that one of the things that he said in his notes is, just so I can quote a little piece of it-

Senator WARNER. You were going to tell us a little bit about your experience. When you go into a court and you have an expert witness, you have to lay a foundation.

Mr. LIPTON. I have been a computer scientist for approximately 15 years and involved in a variety of projects.

He said simply that the strategic defense system cannot be obtained by the classic systems that you are considering, as he wrote to the office. I think that is in a sense the key point here that the critics, and Professor Parnas included, have looked at the earlier Fletcher report and earlier descriptions of potential SDI configuration systems, and have pointed out that those systems would have

grave problems, and I think he is actually quite accurate on that. I think what we cannot do is build a strategic defense system that is one large monolithic system. For example, if we were going to operate in a conventional battlefield, I do not think anyone would seriously consider that the general aim every gun for every soldier and decide what every soldier does at every point in time, how he walks, where he looks, what he does. That is clearly a crazy idea, that kind of centralized system which does not work.

No one suggests we do that for banking. We all have automated tellers, probably, at our banks. We all have lots of banking systems we use. They are not all tied together to one monster machine in the United States. If we did that, we know what would happen. That machine would go down at some point and there would be no banking service for quite a while.

What I think you need to point out to Dr. Parnas and other critics, and what they need to realize is that there are many ways to structure and build a strategic defense system. One of the findings I think of the panel this summer was just that, that the way to build the system that will have a very good chance of success is to model it after some of the systems that work very well, that have lots of independence and separate pieces.

So the way you might envision a star wars defense would be something like this. Rather than having one large centralized system with all the difficulties of getting that right, you might have dozens or even hundreds of separate pieces, each capable of tracking, each capable of targeting, each capable of shooting at and eventually destroying targets coming at the United States.

Now, each of those systems would be possibly different kinds of systems with different kinds of weapons and different kinds of sensors. They might be built by different contractors, different vendors, perhaps at different times, using different technology. The Russians would be faced, or anyone attacking us would be faced with something like a triad, but it now would be a many-legged defensive system.

If one of those battle groups had a software bug, had a flaw, had some misassumption about what a threat could do, it might misfire, it might fire at decoys instead of targets, it might not work. But an adversary attacking us would have to be convinced that not only that system would fail, but all of them would fail.

Now, if you take the analogy to the phone system, we all know that the phone system prides itself on great reliability. Yet we have all probably been out of service during certain unusual events. When I was at Yale University we were out of service for approximately 30 hours because somebody was digging a gas main line and they pulled up the main cable for all of New Haven. That was a very annoying situation. But on the other hand, the probability that simultaneously the entire United States would be without the phone service due to failures at all the switches across the country or even half the country would be out of service seems to be too much, to really think about.

And I think the fundamental problem that the critics have made is they have taken the straw man, they have taken this monolithic view. They talk about the system, and they give large numbers of lines of code estimates. They are right in that that will not work,

but they are also wrong in that that is the only way to do the problem. And I think if we have any hope here to build a system of this sort, we need to move to this more distributed, independent structure.

There is one more very important advantage for this, and that is testability. Parnas says, I think in some of his papers, you may be able to build a system, it may even work, but you may have great trouble knowing that. Clearly, someone will have to testify in the future in front of such a panel trying to convince you that it works, and I think you will want very good proof of that.

It seems to me that if the system is composed of lots of separate pieces, you can get very good testing. You can put a little piece of the system up, test it exhaustively perhaps against live attacks that could be launched, gauge how well it works just like you would test a gun or even an ICBM, and see what its success rate is. After all, the critics believe that the current offensive systems work. No one has ever launched, and hopefully no one ever will launch a thousand ICBM's at once. Yet everybody is willing to believe that that system works, and the critical reason they believe it is that we have done single tests and they worked to some success, not perfectly, and they know that once those missiles are launched, they are all independent, they are operating separately. So if one fails or even if one type of missile fails, there are other kinds of missiles that will work.

So there is an independence argument that allows for testability, and I think that is, if you will, the fundamental mistake that is being made in the public debate on the software.

Senator WARNER. Dr. Lipton, we thank you.

Now, General Abrahamson, I am going to give you the opportunity to cross examine your three colleagues, if there was some fact they did not bring out that you would want as a part of this record, and feel free to use leading questions.

General ABRAHAMSON. Rather than cross examine them, I just would like to add several points.

I have indicated that I thought that the software problem and the entire combination of computer and data handling are really the long pole in the tent, and therefore, by the way, the least mature. But as I indicated earlier, it is an area of fundamental technical advantage in the west, and it is an area that we can and should exploit, and it makes sense in terms of being a foundation of the very kind of complete strategic defense that we are trying to build.

We are moving in the direction of a distributed software and command and control system, as these gentlemen have emphasized is so important. Our management plans are such that we have to have a centralized place where not just theories and architectural concepts will come together. Our management plans include that. That is the national ground test facility, and we will soon be going out on requests for proposals for large scale simulations which will be part of that. And then the second half, different concepts which will eventually nick down into the best architecture to be able to build such a thing in the future.