Level: Introductory Scott Laningham (scottla@us.ibm.com), Podcast Editor, IBM developerWorks
19 Apr 2006 The following is a transcript of a podcast interview between developerWorks podcast editor Scott Laningham and Grady Booch.
developerWorks: Welcome to our first developerWorks Interviews podcast. I'm Scott Laningham. developerWorks Editor-in-chief Michael O'Connell joins me in conversations with technical thought leaders in and out of IBM, as well as other interesting personalities in the technical community.
We're joined today by Grady Booch, someone who usually needs no introduction to software developers. Grady is chief scientist of Rational® Software and an IBM Fellow. His lengthy list of accomplishments includes developing the Unified Modeling Language (UML) with Ivar Jacobson and James Rumbaugh. I'm borrowing from his blog bio, which, by the way, is one of many in our great stable of bloggers on developerWorks. Grady has served as architect and architectural mentor for numerous complex software-intensive systems around the world in just about every domain imaginable. He's is the author of six best-selling books and has published several hundred articles on software engineering, including papers published in the early '80s that originated the term and practice of object-oriented design. And I suspect that just scratches the surface of the total Grady Booch picture.
Grady, we're grateful for your time today and would like to kick this off by asking you if you feel there is a single overriding issue or focus area that is a must for the software developer to be aware of and stay on top of today.
Booch: Wow, that's interesting. You know, trying to focus it down to one -- because I might even reject the premise of the question by saying that perhaps the real challenge for the software developer today is that it's probably a mistake to focus upon just one thing because there are so many things to be involved with.
There appears to be an increasing compartmentalization in the skill set that various developers need. Depending upon the domain, culture, and part of the world you're in, I'd give a different answer to that question. If
you're a game developer, for example, where I just came from -- and as an aside, it sounds curious, here I'm an IBMer worrying about gaming. But IBM® had a large presence at the Game Developers Conference. IBM provides a cell processor for the PlayStation 3. There's a large, interesting software challenge and opportunity in that space. You talk to that community, and the problems they're facing are larger ones of scale. As they start building larger and larger systems, they're coming across the classical problems that the enterprise community hit a few years ago.
If you talk to a classic Web developer, well, depends on where they are in the world. If they're dealing with things on the fringe of an enterprise, knowing about Ajax and its details are important. If you're inside a
system, knowing about service-oriented architecture is perhaps the most important thing.
So it depends upon, again, your domain, your country, your developing culture. But I think overall, I'd reject the premise of the question and say the challenge of every software developer is to balance the flood of new
things with which they have to deal with, while at the same time not rejecting the fundamentals of software development that have proven themselves to be effective over the many years.
developerWorks: So no, not a single thing, and, no, you can't afford to, either?
Booch: Or put it another way: The single thing is you have to be comfortable with advancing on many fronts simultaneously.
 |
Guest: Grady Booch
Grady Booch is recognized internationally for his innovative work on software architecture, software engineering, and modeling. He has been with IBM Rational as its chief scientist since Rational's founding in 1981. He is one of the original developers of the Unified Modeling Language (UML) and was also one of the original developers of several of Rational's products. He has served as architect and architectural mentor for numerous complex software-intensive projects worldwide.
He is the author of six best-selling books, including the UML Users Guide and the seminal Object-Oriented Analysis with Applications. He has published several hundred technical articles on software engineering, including papers published in the early '80s that originated the term and practice of object-oriented design. He has lectured and consulted worldwide.
Grady is 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). He is an IBM Fellow, an ACM Fellow, a World Technology Network Fellow, and a Software Development Forum Visionary.
He received his bachelor's degree from the U.S. Air Force Academy in 1977 and his master's in electrical engineering from the University of California at Santa Barbara in 1979.
He lives with his wife and cats in Colorado. His interests include reading, traveling, singing, and playing the harp.
|
|
Michael O'Connell: Grady, what is that the biggest challenge you're facing right now personally?
Booch: Well, personally, I have my own issues because I'm not a code warrior, for one. So I don't make my living by pounding out code on a daily basis. Yes, I still do cut code, but it's a difference in priority.
For me, the challenge is now that I'm part of an organization that's literally 100 times the size of the Rational organization, there are some wonderful, fascinating, brilliant people inside IBM and lots more customers to deal with. So my personal challenge has been one of just balancing where am I in the world. I need to clone myself because I could be traveling twice every week at this current rate.
developerWorks: Grady, one thing we were curious about your thoughts on, talk about a bit, if you would, about the general innovation initiative at IBM and what that means to developers and to companies today.
Booch: Sure. I think this is a very exciting one. The whole GIO is really focusing upon the need for and the implications of innovation. Sam has been, you know, really focusing upon this as a core value for IBM, and not just because this is where the world is going, but I think also because IBM has a very real opportunity and dare I say it responsibility to continue to drive innovation in so many areas.
Innovation is an emotionally laden term. but the way I step back and look at it from the perspective of the software development community is that software development has been it, it is and will remain fundamentally hard,
and yet the products of our industry have literally changed the world. We have enabled individuals to connect and do things they could not have done before. We have enabled companies, countries and, dare I say it, parts of civilization are changed because of the presence of software.
Predicting innovation is difficult. Creating an environment for innovation in which amazing things, things that we could not have imagined before we began to flourish, I think that's the goal of what IBM is trying to do, what we're seeing in the marketplace, and what the GIO study reflected -- having that kind of environment for innovation will reap benefits in ways you never could have anticipated.
developerWorks: You know, I also think about the parallel to this technological innovation is certainly business model and just the way the world operates, there's innovation evolution going on so much. I've been reading Thomas Friedman's book The World is Flat, and I'm probably the last one to read it. But it really -- it speaks to that idea -- doesn't it? -- that things are moving and changing and evolving swiftly. And so this isn't a topic that is necessarily one reserved just for, you know, cocktail-party discussion or something. But this is at the heart of a lot of what's going on in our lives.
Booch: It ultimately has pragmatic implications for us individually and for the generations that will come behind us.
By the way, I appreciate you using the word "evolution" and not "revolution." I'm a little bit allergic to the word revolution because at least from the inside, all of the things that we have seen that I think the common press would call as revolutionary are really things that build upon the shoulders of giants.
You look at the infrastructure behind the Web itself, and I'm not discounting the work of Tim Burners-Lee and really the fusion of things that he did, but if you look at the elements that made up the Web, these are things that evolved over many years. And there was a point where a perfect storm, to use another metaphor, came
together. And its growth has been steady and moving forward, and I think historians can step back and say, "Well, at this point in time, we can call this, you know, a state change." But from the inside, many of these things really do look like incremental changes. And again, this goes back to creating the environment for innovation because you can't predict the way these things are going to come together or how they're going to come together at all.
O'Connell: One of the things I remember from your keynote at the Rational conference last year was the comment that innovation occurs at the intersection of innovation ... or intersection of invention and insight. I
thought that was a really good way to think of it.
Booch: Did I say that? Boy, that was really good.
O'Connell: Yeah, it struck me.
Booch: I don't remember saying that. But OK -- I'm sure I did. Yes, I remember that bit now, yes, I do.
O'Connell: The fact that you were talking about innovation almost 12 months ago, and IBM is still talking about it and seems to be ramping up its focus on that topic.
Booch: Sam was even talking about it a year before that. He was, I think -- Sam is a gentleman who has incredible foresight, and I'm glad he's at the helm of IBM because he sees these things coming and applies the energy necessary to turn this stuff into reality. Thus, for this year, this is why the GIO work was really focused upon the implications of innovation.
I think Sam and a lot of folks at IBM understand that this is important, not just for IBM Corporation, but it's simply the right thing for our civilization to focus upon.
O'Connell: I just wanted to ask one other question in terms of advice for others who are trying to let innovation flourish in terms of how they can be intentional about it. Do you have any advice or suggestions on how to
make that happen?
Booch: I think the heart of it comes with an apparent conundrum with the word "innovation" and "IBM." I think if you look at IBM, people will say, "Gosh, isn't that just a huge old organization? How can they be
innovative?"
Well, having had the opportunity to work with so many different folks inside IBM in the last two years and the folks in IBM Research, I am just utterly stunned at the number of advances IBM has made and continues to make on so many different fronts. And I think the key to that is that even in the presence of a large organization, that it is possible -- well, not even just possible, but it is -- necessary for the future health and future growth of that organization to still maintain a culture that rewards and permits innovation.
And so for me, the experience over the last several years has been simply innovation in the context of small teams and even large organizations is absolutely possible.
developerWorks: You talked about an atmosphere that's supportive of innovation, and we were thinking about those qualities -- those characteristics that are so often mentioned in this discussion at IBM about being open, collaborative, connected. How important are those characteristics in not just the end product but in the atmosphere that surrounds all this work?
Booch: Sure. And to the phrases you also used, I would add global and multidisciplinary. As an example, when Nick Donofrio, who is the sort of godfather for all the Fellows, when he first spoke to me after I was given this amazing honor, we had a long discussion about what it means because I hadn't grown up in the culture of IBM. And the conversation basically led to the realization that I have two jobs in IBM: One is to invent the future, and the second is to destroy bureaucracy. And those are both things that are really very much elements of creating an atmosphere for innovation.
The Fellows program, the distinguished members of the technical staff, the distinguished engineers, rather, the senior members of the technical staff, those kind of structures are structures within IBM that are part of the
atmosphere for creating innovation.
We also have things like the IBM Academy of Technology based upon the National Academy of Sciences, which is yet another mechanism throughout IBM that gets people together from various disciplines and around the world. So it has features that match every one of those characteristics you described that are essential for forming an atmosphere of innovation.
Another important aspect of this kind of atmosphere is that it must be in some ways sheltered from the daily demands of, you know, you've got to do this thing because we've got to make money on this at this date. You've got to shelter some groups away from that from time to time because many innovations, when you first begin, it's very difficult to build a business case around them. But you perceive of them simply because they appear to be the right thing.
You have a manager who overshadows it and says, "You know, I think this is right. Let's take a risk." And so innovation must also be part of an atmosphere of calculated risk-taking. And at the same time, it can't be so
divorced from reality that it would never find any kind of tangency with reality.
And so the people involved in such innovative efforts, the best innovations we see are always coupled to some obvious or some intended end use or some marketplace that maybe we don't quite understand how it will be used. But we'll let it flourish.
O'Connell: Grady, are there things that you're aware of right now that are in the IBM innovation pipeline or perhaps, even more interestingly, innovations you're aware of that are taking place with customers of IBM?
Booch: Sure, and there are even some of them I can talk about.
O'Connell: Great.
Booch: There are some of them I can't talk about. But the ones I do, what comes to my mind immediately are a couple. And where do I begin? Not necessarily in any order of importance, but if you look at programming languages over the years, there have been bursts of rapid innovation and lots of languages being considered that point to stability. We're in a plateau at the moment where the dominant languages are those
such as C++ and Java™ and, to a much lesser degree, things like C#. Cobalt still lives, of course. C still lives. But the ones where a lot of software development is taking place are Java and C++. Now, those are the traditional languages. And where we've seen a burst of activity of late has been in the scripting languages: PHP, Pearl, Python. And now things such as Ruby.
If you look at each one of those languages, in some ways they look an awful lot a like from one another and tracking research that's going on in the language space, there are some interesting and innovative things. Many of
these languages still end up looking like one another in terms of their expressiveness. There are a few exceptions, but by and large, that's the case.
There's a state change happening, though, and this is something coming, bubbling up from the bottom of hardware and that's the shift from single-core to multicore chips. The cell is certainly a good example of that. But both Intel® and AMD are moving down this path, as well. And the reason for that is, again, an evolutionary one, that we've hit the point in the chip space where chasing higher frequencies is simply not getting us the best returns.
And so another way to change the game is, instead of having single processors that are faster and faster, we have multiple processors on the same chip. Now, that impacts a certain small community very early on. The people that build the middleware and database folks, all the traditional folks in the divisions in the software group -- they're figuring out "How do I leverage the power of these multicore systems?"
However, there's going to come a point, and we're seeing this in the gaming community, they're kind of the canaries of this marketplace for us, where they're realizing that even individual developers are going to have to deal
with intimate concurrency.
One of the limiting factors in the high-performance computing community is that they're dealing with programming topologies, hardware topologies that are massively parallel, yet the languages and skills of those individuals to use those, the power of those systems, we simply don't know how to break through to that.
So there's a programming model program that is looming, and there are a number of efforts inside IBM Research, the compiler folks up in Toronto, even inside Rational, where we're exploring what do we need to do in terms of programming models to support multicore systems. So that's one of them.
Another area I can mention with regards to innovation is in the whole area of collaboration for collaboration. The software development problem is one that, like the general innovation problem, involves communities of
people that are often geographically and temporally disbursed. Ideally, you want to develop software with the smallest team possible and have them co-located. But for a variety of economic, historical, business reasons, that simply can't be so for systems of scale. And so we increasingly see organizations that are building software -- and not just because of outsourcing but because of how they're organized -- will divide up their software development teams across buildings, across cities, across countries, and across time, too.
So we think there's an opportunity for applying some of the things that have been learned in the general collaboration space and applying those to the problem of software development in a distributed way. There are a number of efforts we've been funding with IBM Research. There are efforts, of course -- inside Lotus® and elsewhere -- that are germane to this as well. And we think these can come together to provide a different environment for development. So those two come to mind that I can talk about.
developerWorks: Grady, you know this brings us full circle, but back to that first question and the way you spoke about it, software developers and where they need to focus their attention and time and how broad their view should be. But when you think about the individual developer who is so busy addressing a lot of specific problems related to their projects they're working on, why should all this matter to them, or maybe the more
intelligent thing to say is how should they go about trying to, in the midst of their busy day and busy week and busy year, whatever, carve out time for addressing and staying up to speed on all this stuff?
Booch: Great question. I'm delighted that IBM is getting back to its Think Fridays. You may remember in Thomas J. Watson's day. You may not remember because I don't think any of us were around then. His moniker
for IBM was Think. Now, of course, we've instituted the policy that at least in the Software Group that Friday afternoons should be largely void of telecons and other kinds of meetings so people have the opportunity to sit back and reflect and think and recharge. Google does this too, setting aside some 10 or so percent of their developers' time to do it. And I think those are great signs for an organization that's invested in innovation.
But an individual developer, however, who is laboring perhaps under a death march and focused upon so many pressures upon them, I sympathize with them because I recognize it is very, very hard to lift your head out of
the trenches and see what else is going on in the world.
So it requires energy on the individual's part to say, "You know, I'm going to step outside of my box. I'm going to, you know, look around and read some of the blogs of people who are doing things in this space that I respect and I can learn from. I'm going to do some more reading from not just the trade journals but some of the professional journals to learn outside my box."
So many people get so driven in their particular domain they neglect to see what's happening in other domains, and I think that's a considerable loss of opportunity for innovation because in many ways, software
development has a set of problems that are common across domains and across development cultures. And if it's solved one place, it's likely been encountered elsewhere. It's just simply a matter of seeing where those
things happen.
So I guess the lesson here: It requires energy for the individual to say, "I want to keep growing, and to do that, I've got to spend some time myself to carve out -- look beyond -- my current domain."
developerWorks: I love those thoughts and it makes me think about your comments earlier about evolution and how so often this process is as much about discovery as it is about creation.
Booch: Yes. You know the day I get bored of this community of software is the day I stop learning. I'm currently on a couple of external efforts I've intentionally gone after because I realize these are areas I don't know enough, and so I'm intentionally pursuing them so that I can learn myself -- I, myself, can learn. I'm sorry, that was a mangled phrase. And one of these is associated with the Computer History Museum where I approached the trustees some years ago and said, "Hey, you guys should also become a museum of software." And not a direct cause and effect, but I helped precipitate a lot of action in there. They know have a software curator and software collections committee and actively collecting source code for future generations. It would be a travesty if the products of our time were lost to future generations. Because the products of our time were part of the incredible ramp-up of how software has changed in the world.
The other major project is this building of the handbook of software architecture. I know a lot about a variety of kinds of systems, but there are many other kinds of systems I don't know about. So my intent is to codify the architecture, about 100 seminal systems across the domains of software. And it's striking at the heart of the problem I mentioned earlier that people in one domain have no clue about what's happening in other domains. The intent here is to provide that kind of reference work. Such reference works exists for civil engineers and other types of architects, but not for software. And that's what I'm trying to do here. This is where I'm spending my time trying to learn.
developerWorks: Thank you so much, Grady, for your time today. It's been a great pleasure being able to chat with you about this. We know there's a lot more we could cover, so we'll look forward to another one sometime.
Booch: Sure. Glad to help out. Take care, gentlemen.
developerWorks: You can subscribe to the developerWorks Interviews podcast series and our other podcasts at ibm.com/developerworks/podcast. We do hope you'll subscribe. In the coming weeks, we'll have interviews with thought leaders on the Rational Software Development Platform, the Eclipse story, service-oriented architecture, more on open standards, emerging technologies, the evolution of community on the Web -- a lot of great topics. So stick with us. Check our developerWorks podcast page for a new 2006 entry in the WebSphere® Technical podcast series, this latest entry including discussions on resource utilization. And join Michael O'Connell and I for This week on developerWorks, where we run down new site content and features and chat with developerWorks staff.
For Grady Booch , Michael O'Connell, and everyone at IBM developerWorks, I'm Scott Laningham. Talk to you next time.
Resources
About the author | | | Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. His other work has included reporter and director for programming featured on Public Radio International, freelance writer for the American Communications Foundation and CBS Radio, and songwriter/musician. |
Rate this page
| 
