Q&A With: Grady Booch

Grady Booch is the chief scientist of Rational Software, a recently acquired subsidiary of IBM. He is best known as one of the creators of the Unified Modeling Language, a set of standards for graphically representing common software development concepts, such as classes, components, and behaviors. He started his career in the U.S. Air Force as an officer specializing in advanced software projects in such areas as graphical user interfaces and very large systems integration. Upon retiring as a captain, he joined Rational one year after it was founded by two of his Air Force Academy classmates. His work there led to his becoming one of the world's most sought-after advisors in the field of software engineering. For more on his background, please visit: https://www.developer.com/design/article.php/626961.

Spectrum Online: How did you become interested in patterns?

Grady Booch: If you look back over what I’ve done in the last two, three decades, it’s been an interesting progression from me being a language bigot--I thought Ada was the way God intended us to program--to the recognition that the hard problems are no longer about language anymore. It’s something at a higher level of abstraction.

Indeed, the way I characterize it is the entire history of software engineering can be characterized as growing levels of abstraction. We see this in our languages, our platforms, our methods, and our tools. Therefore, it’s reasonable to suggest that, as we predict out to the future of software engineering it, too, will follow the path of increasing levels of abstraction.

My interest these days has moved into the pattern and architecture level largely because of three reasons. The first is it’s a natural progression for me along the level of abstraction and moving up. Second, it’s an untapped area. No one has done a comprehensive study of architectural patterns across disciplines. And third, I just really have, personally, an insatiable curiosity. I look at systems and say, how did they do that? And I’d really like to know. So, to a large degree, I’m doing this work because I want to know.

SOL: What are the hallmarks of successful large software projects?

EGB: I find this to be true among all organizations that tend to be hyper-productive and notably absent in those organizations that are not successful. Here are the two rules, and everything else is detail. First, development should proceed by the successive refinement of an executable architecture. Second, the rhythm of a project is defined by a regular incremental and iterated release of those executables.

In essence, the presence of a strong architectural vision seems to be a factor in the success of most interesting--and by interesting I mean economically viable--software-intensive systems. For larger systems, we’re talking about millions of lines of code, for which a business or an industry or a government might depend upon having an architectural vision. In essence, all development swirls around the elaboration of that vision.

SOL: What’s wrong with the traditional way that companies developed software?

EGB: The traditional way in which we thought software should be built--and I’m talking about the '60s and '70s and, indeed, even the '80s, and there are still pockets of organizations that do this--their world view says: we’ll define our requirements, we’ll define our architecture, we’ll go off and code it, and then we’ll test it. To quote Rob Lowe from ”The West Wing,” this is so wrong on so many levels.

First off, it violates the very notion of what a requirement is. Requirements are not necessarily laws of physics which I can’t violate. There’s a curious reality of requirements in software in that (A) requirements are never done until after you deliver the system and (B) the presence of a system changes the world view of the stakeholders who define those requirements and, therefore, they cannot know a priori all the details of the requirements they wish to have. Those two factors alone negate the notion of trying to get requirements done right first, because experience says they are guaranteed to be wrong.

Testing at the other extreme of the life cycle is also misplaced. Testing is best done as a continuous process, even before the first line of code is written. Also, the best systems we find are grown from small systems that work in the first place. If I take more of the big bang, where I design and then I code, it negates the notion of trying to grow a system.

SOL: You’re a member of the Computer Professionals for Social Responsibility. Could you talk a little bit about what you see as the responsibilities for software developers?

EGB: It is an incredible privilege to be a software developer. We are in a time where our industry is facing some challenging economic forces. The business is down, to put it quite frankly, because the world economy is hurting in some ways. And yet it’s a privilege to be a developer, because we, as an industry, have changed the world. We have created systems that have affected individuals, corporations, governments, really the way that people work in the world. It’s so cool being a member of an industry that provides the facilities to create new businesses, as well as economize existing businesses, and that impacts every other business in the world. You know, how cool is that?

At the same time, it’s a deep responsibility, because what we do does change the world. So, as engineers and professionals in this space, it means we have to be not only the best we can technically, but it also means being cognizant of the fundamentals of engineering, of being cognizant of the ethical and moral implications of the things we do. And, indeed, there are legal and moral and ethical implications to writing software. That’s one of the reasons I’m a member of that society, because this is one of the very few groups that recognizes the importance of ethics in regards to the profession of software.