Grady Booch is recognized internationally for his innovative work on software architecture, software engineering, modelling and has made it his mission to preserve old computer programs and encourage software developers to adopt a more uniform approach to writing their programs.

“The average developer
 is not well-prepared to
 develop concurrent,
distributed, secure
 software. These are all
really wicked problems.“

He has been with IBM Rational as its Chief Scientist since the company was founded in the early 1980s and is one of the original developers of the Unified Modelling Language (UML). Grady has served as architect and architectural mentor for numerous complex software-intensive projects around the world as well as being the author of six best-selling books, including the UML Users Guide and the seminal Object-Oriented Analysis with Applications.

He has published numerous technical articles on software engineering, including papers published in the early 1980s that originated the term and practice of object-oriented design. A member of the Association for Computing Machinery (ACM) , the Institute of Electrical and Electronics Engineers (IEEE) , the American Association for the Advancement of Science (AAAS) , and Computer Professionals for Social Responsibility (CPSR).

“If I don’t have a sense of
the architecture, and I
keep piling on code, it
becomes a fetid mess”

He is an IBM Fellow, an ACM Fellow, a World Technology Network Fellow, and a Software Development Forum Visionary. Grady received his bachelor of science from the United States Air Force Academy in 1977 and his master of science in electrical engineering from the University of California at Santa Barbara in 1979. He lives a contented life with his wife and cats in Colorado.

RM:

How did you start programming?

GB:

I built my first computer when I was 13 or so. Having done that, I remember pounding on the doors of every company in my hometown the next summer, looking for a job in computers. Well, no one was going to hire a kid, but a kind sales man at IBM took me in, looked over my schematics, and said some kind things to me. I asked him about programming, and he gave me a Fortran IV manual. I returned the next week, having written some programs on my own (I wrote a discrete simulation of the collision of two particles) and he found me time on an IBM 1130 to use. That was my first experience in programming. By-the-way, when I interviewed John Backus, I took that manual with me, and got his autograph!

RM:

Do you remember what it was about programming that drew you in?

GB:

I loved the problem solving involved, and the ability to create new worlds of my own.

RM:

What was the first interesting program you wrote?

GB:

My very first program of any substance was in Fortran, and it offered a simple simulation of the position and energy release associated with two subatomic particles colliding with one another, as I mentioned above. I’d taken some equations from physics text and thought it would be fun to play them out. The first real program of (industrial) significance was something I wrote while in the USAF at Edwards AFB while at cadet at the Air Force Academy – I wrote a program that did circular error probable calculations to analyze the efficacy of the (then in development) F16.

RM:

What are the tools you use to program? Do you tend to write smaller programs, libraries and so forth?

GB:

I use Eclipse for code work, Adobe Dreamweaver for web work. I have a body of code of modest size (only about 25k sloc) that I continue to poke and prod actively. Most other things are indeed smaller things that live on the edge of the web.

RM:

What’s this ‘dirty little secret’ to writing software, you’ve spoken about?

GB:

In other disciplines, engineering in particular, there exist treatises on architecture. This is not the current case in software, which has evolved organically over only the past few decades. All software-intensive systems have an architecture, but most of the time it’s accidental, not intentional. This has led to the condition of most software programming knowledge being tribal and existing more in the heads of its programmers than in some reference manual or publicly available resource.

RM:

By not having a codified approach to writing software, we’re playing with fire.

RM:

Our society now runs on software. As a general rule of thumb, worldwide, software developers produce around 33 billion lines of new or modified code per year, and it quickly becomes outdated as new demands are placed on software. If I don’t have a sense of the architecture, and I keep piling on code, it becomes a fetid mess. The danger of this stagnation to a large business is that if a smaller and nimbler competitor comes along with a better way of doing things, the large business has trouble adapting and can easily lose its leadership position in a given market. There becomes a fundamental economic reason for software architecture then.

RM:

Okay, let’s switch away from writing software to the development of UML, which you’re well known for. What led to its design?

GB:

This was a particularly vibrant time in methodology. There were dozens of notations and processes being explored in the market place, as the industry were making a transition to object-oriented languages (which are now quite mainstream, but at the time were not). Ultimately, the market was going to decide, and the Booch Method, OMT, and Objectory had taken much of the mind share, but that fragmentation was unsustainable. With The three of us – me, Jim, and Ivar – already converging on common themes, it made sense for us to combine forces. Thus, we (Rational) hired Jim, so that he and I could unify the Booch and OMT methods. A year later, we acquired Ivar’s company, and thus the three of us joined forces. In the end, this ended the method wars and helped fuel the development tools of that year.

RM:

What was the overall greatest challenge you have faced in developing UML?

GB:

Being intentionally simple. In UML 1.0, we had a set of use cases and ideas of views that drove us. There were always corner cases, but we strove for an 80% solution with the most minimal notation we could define.

RM:

Do you use UML as a design tool?

GB:

Yes. I often sketch diagrams when I’m designing something new or trying to understand something old.

RM:

Do you see the multicore era changing the way we approach architecture and design?

GB:

The average developer is not well-prepared to develop concurrent, distributed, secure software. These are all really wicked problems. Our languages have few really good primitives for dealing with intimate concurrency such as multicore processors demand, and thus we’ve got a bit of a conundrum. My take is that we need advances in languages, in compilers, in patterns (such as Intel’s concurrency patterns) and platforms (such as Apple’s Grand Central Dispatch) to raise the level of abstraction.

RM:

How would you explain the “Booch” method in layman terms?

GB:

I’d say simply that it’s a notation and a process for thinking about the world in terms of objects.

RM:

Before this interview I was thinking about trends in OOP. Each time a new language is developed it cleans up what is understood about the old languages and adds something new, experimental and so on but no one has come to the point where they have a new language and then want to stop at what is understood. Do you think that some day someone will say ‘I’m not going to be innovative; I’m just going to be clean and simple, and I’m going to stick with it’ rather the way in which Pascal was started but didn’t continue?

GB:

Oh, there have always been attempts to return to simplicity. But you know, these days it’s less about the language and more about the frameworks in which they operate…and those frameworks by their very nature, are inherently complex.

RM:

Has market acceptance of object-oriented programming turned out the way you had hoped?

GB:

Yes; it is part of the atmosphere, and thus often invisible to many…but that is how all good technology should be: transparent.

RM:

Do you think that there is a lack of reusability in OO languages not in functional ones because OO have the implicit environment that they have? For example, you wanted an apple but what you get is an apple grower and a whole orchard!

GB:

Reusability is so misunderstood. The economics of reuse are such that reusing lines of code don’t make sense (except by simple cut and paste means) and that the real value comes in reusing subsystems and design patterns; The former of which are manifest in frameworks and the later of which are not manifest in code at all.

RM:

You write quite a bit about debugging on your blog and I’d like to ask you a little more about this. What tools are in your debugging kit? Do you ever step through code just as a way of checking it when you’re not tracking down a specific bug?

GB:

Do I talk about debugging that much? I really didn’t think I did! Well, I use Eclipse and all the usual Rational tools for my workbench. And do I logically step though code? Yes.

RM:

How about other debugging techniques, such as assertions, or proofs? Do you use any of these. Do you think in terms of variants?

GB:

Honestly, I don’t. Indeed, in my comings and goings, I’ve found only a very tiny segment of the domains in which I work to be appropriate for proofs.

RM:

Peter van der Linden in his book Expert C Programming has a fairly dismissive chapter about proofs in which he shows a proof with a bug in it. Has that happened to you and is necessarily rare that you have a bug in your program and then a compensating bug in your proof?

GB:

Your question presumes I prove some of my programs. I do not, never have, next expect to.

RM:

How does a software developer become a published writer? Was it a natural progression for you?

GB:

Many developers would be terrible writers; many writers would be terrible developers. I think there’s a small overlap, and I just happen to be a sufficiently articulate geek.

RM:

Is your writing confined to technical subjects, or do you harbour a passion to become a novelist for example?

GB:

I’ve started both a novel and a screenplay. The novel I start just for fun; it’s a technothriller in the spirit of Clancy. As for the screen play…well, just stay tuned. I can’t say more at this time.

Generally, I write when I want to better understand something. Writing forces me to think things through. My wife is my best editor and critic. Is she a writer? No; but she’s a voracious reader.

RM:

Do you observe all the time, like a journalist? Donald Knuth told me that when writing he’s pretty much a hermit and is unable to do anything else until he’s finished. He will not travel to conferences or accept speaking engagements, or undertake any new responsibilities of any kind.

GB:

I have to isolate myself when writing, but that’s hours at a time, not days or weeks. I often describe myself as an awe-struck seeker: I observe constantly; I’m staggered by the beauty of the world and of life; I’m deeply curious and in love with life.

RM:

Would you still study computers whether or not it had any commercial value?

GB:

Computers have commercial value? I hadn’t been paying attention…

Seriously, computing has deep implications to the human experience, and vice verse…they have in many ways co-evolved. As such, that interplay is of deep interest to me.

RM:

Are there books that every programmer should read? What would be your top five?

GB:

Design Patterns/The Mythical Man Month/Systemantics. Beyond that, I think it gets very specialized to mention others.

RM:

What about Knuth’s magnum opus The Art of Computer Programming? Are you the kind of person who read it cover to cover, who dips into it for reference, or who put it on the shelf and never looked at it?

GB:

I’ve read it cover to cover, and still dip into it from time to time.

RM:

Do you agree that to read Knuth you have to be able to read the maths and understand it. To what extent do you think having that kind of mathematical training is necessary to be programmer?

GB:

Oh, I don’t think understanding Knuth requires that much mathematical skill…if anything, one just needs the ability to reason symbolically.

RM:

Earlier, you spoke of your admiration of John Backus earlier and I’d like to work the next question around him. Most innovations in software have emerged from experience and experiment, without any appeal to an underlying theory. When John Backus invented Fortran, he had no theory to work by. What is stopping the same thing happening now?

GB:

But I disagree with your premise. John was a mathematician and therein lies considerable theory. John was working to make mathematics more approachable to the computer and thus his innovation came on the shoulders of much theory.

RM:

Do you feel we’re progressing in technology even though sometimes it seems that we are leaping backwards?

GB:

Life at any level of detail is essentially one of punctuated equilibrium. I can’t fully attend to your question because I don’t know how you measure forward or backward. I do believe in the arrow of knowledge in science; I do have confidence in the growing maturity of civilizations. I do hold hope for the flowering of the human experience. Technology is just a tool.

RM:

What do you think can be done to improve the quality of software?

GB:

There needs to be a consistent way of writing software that runs on different systems and in different situations that considers a number of different factors: Is the software running on a single machine with multiple processors or is it running on a cluster of single-processor machines? Will all of the software source code go into a single file on the computer, or will it be broken down and executed as multiple scripts? How will the software define and use the different data it encounters? These are questions that must be answered before the software is written in the first place. In civil engineering, if you ask someone to build a Victorian house, there is an inherent understanding of what that looks like. If you ask different programmers to design software for a high-throughput system [such as one that processes financial transactions], there’s no general agreement of how that software should be built.