 | Level: Introductory Michael O’Connell (moc@us.ibm.com), Editor-in-Chief and Editorial Director, IBM developerWorks
Scott Plamondon (plamsc@sbcglobal.net), Freelance journalist
03 Apr 2003 Grady Booch spends his time pondering how to improve software development. As such, he thinks about how current trends -- UML, aspect-oriented programming, Web services, and so on -- will evolve into tomorrow's development environments. Most importantly, Grady believes that we solve the complexity problem by continually raising the level of abstraction. Find out what Grady thinks about these and other issues in this exclusive interview with developerWorks Editor-in-Chief Michael O'Connell.
Will J2EE (Java 2 Platform, Enterprise Edition) vanquish Microsoft's .NET? Will Web services combined with XML schemas raise the level of abstraction? Rational Software Chief Scientist Grady Booch is paid to ponder such questions concerning the future of software development. If you think such a man possesses insights into how your development process will evolve over time, you'd be correct.
Grady Booch
Grady's contributions to easing software developers' lives stretches from co-creating Rational Rose, to writing (at last count) thirteen software development-focused books (see Resources), to co-developing the Unified Modeling Language (UML). As such, Grady believes software development will always prove difficult, but we, the developer community, should strive for improvement.
Now Grady is with IBM, since IBM's purchase of Rational Software, and is one of the featured speakers at the IBM developerWorks Live! conference April 9-12 at the Morial Convention Center in New Orleans (see Resources). We asked him to share a preview of his speech. Grady, being Grady, gave us much more in this exclusive interview with developerWorks.
developerWorks: Let's start with your technical background.
Booch: I built my first computer when I was twelve in Amarillo, Texas. At the time I was into hardware because you couldn't really program things. No courses or books existed, and, as a twelve-year-old boy, I couldn't ask my peers for help. So, I pounded the doors at the local IBM sales office until a salesman took pity on me. After we chatted for a while, he handed me a Fortran [manual]. I'm sure he gave it to me thinking, "I'll never hear from this kid again." I returned the following week saying, "This is really cool. I've read the whole thing and have written a small program. Where can I find a computer?" The fellow, to my delight, found me programming time on an IBM 1130 on weekends and late-evening hours. That was my first programming experience, and I must thank that anonymous IBM salesman for launching my career. Thank you, IBM.
dW: And now IBM is reaping the dividends?
Booch: Yes. The lesson: no matter where you are inside IBM, be careful because your actions may produce consequences far more reaching than you imagine.
dW: I imagine your early hardware focus relates to your appreciation for modeling?
Booch: Yes. In fact, my master degree is in hardware from the University of California Santa Barbara. I earned a good software engineering degree from the Air Force Academy, but later I decided I needed a deeper grounding in what software runs on, and so my masters was primarily on computer architecture.
I've held only three jobs in my life: Baskin Robbins, the Air Force, and Rational Software. As Rational's chief scientist, I'm the company's designated free radical in which I worry about the next three to five years.
As such, I work from the premise that software development has been, is, and will remain a fundamentally hard profession and no one thing will make a state change in how we develop software. As I look forward, several things appear on my radar screen that may fundamentally change the developer's experience -- state changes from what we see today. From the hardware side I see the rise of Grid computing because it makes pure economic sense, and I'm delighted to see the technologies and standards falling into place.
dW: From that perspective, can you describe the most important new technologies or tools that will improve application development performance, reliability, scalability, and
simplify development?
Booch: I see the maturation of platforms like J2 (Java 2 platform) as well as Microsoft's .NET. While both will continue to dominate middleware, they can mature only incrementally. For example, people will invest so much in either platform that they can't absorb radical change from them. So, we'll see some stabilization -- good for the industry because technology churn creates tremendous heat and friction for organizations.
Moreover, if I polish off my crystal ball I foresee the rise of aspect-oriented programming (see Resources). Today's large software systems, systems of quality economic value, include tens of thousands of moving parts, so we tend to never turn them off. Therefore, the challenge becomes how to morph such systems without turning them off and yet add value with many stakeholders as part of the solution. Stakeholders can range from graphic artists, to network types, to security people, to business experts. In such cases, you can't face the problem as a traditional programming problem. In fact, you're no longer building a program -- it's morphing parts of a large system with those parts interconnected with each other. In that context, with aspects you build those systems from threads that cross-cut through those pieces and let domain experts from those particular views express an aspect. In the next two years or so I think aspect-oriented programming will bear fruit in testing, deployment, and business rules.
dW: Can you elaborate on what you mean by "express an aspect?"
Booch: Sure. Let me give a low-level example, logging, then follow with a high-level example, security. WebSphere has a logging problem because each WebSphere piece includes its own logging mechanism. Developers would benefit if we could assert a logging policy that says, "Thou shall log this way." If that were so, you simply express a logging aspect, express the policy, and have the tools to weave the logging aspect into the rest of the system.
At a higher level, consider asserting a security policy that cuts across the system. As things exist today, you must touch so many disparate pieces to create a tight security policy. In reality, most individual developers cannot build concurrent, secure, distributed systems -- they just don't possess that skill set. And yet, what individual developers do locally can have tremendous global implications. Therefore, by rallying security around an aspect you compartmentalize the problem so that, in effect, the developer needn't worry about such issues.
As another prediction, I believe Java as we know it will not be the dominant programming language in the next ten years. Rather, I see textual and graphical programming elements morphing together. I don't believe we'll ever see a purely graphical programming language; rather, I see a handful of graphical and textual representations coexisting with one another.
Another big change to the developer experience will revolve around collaborative development environments. Development environments have evolved from independent command-line tools to Integrated Development Environments (IDEs) in which the developer's basic tools sit on the individual desktop. But notice the operative word I used, "the individual desktop."
Development today is a team sport, but teams may not be co-located. How do you gel a team with widely dispersed members? That's where the Web comes in: we can use the Internet for software development itself, not just as the target for software development.
However, the leap has not happened yet in combining IDEs with collaborative environments. Collaboration doesn't represent a killer app -- it's hundreds of small things working together. Instant messaging, contextual discussion groups, artifacts, repositories, integrated configuration management on the back plane -- these must weave together to provide a collaborative environment. Indeed, I think IDEs will morph with those elements into collaborative development environments.
dW: Speaking of software applications, why are word processors and spreadsheet programs monolithic and not an assembly of cheap interacting components?
Booch: Your question speaks to the economics of those parts themselves. Ultimately, and this will sound strange, end users hate software: it gets in the way, costs money, and stops them from doing what they want. But they must use software because it enables their businesses. We resolve that paradox by building complex software but hiding that complexity by creating the illusion of simplicity. As an independent information worker I don't want to take these pieces of word processing apart and assemble them. Yes I have Microsoft Office Suite on my desktop, but do I use all of its power and do I program against it? No, because I pick and choose the pieces I want and my big machine absorbs it all.
I'd say, by and large, we haven't seen the commoditization of software systems because, frankly, there are so many pressures upon the individual projects there's no time or economic incentive to go back and do that componentization.
dW: What do you think of agile development?
Booch: At Rational we're great believers in agile development. I'm enamored particularly with agile development in relation to the social dynamics of small developer teams. Agile methods address such social dynamics, thus helping the developer team gel.
dW: What about XP, Extreme Programming?
Booch: Rational's experience indicates that while XP offers some great ideas, it's silent on some larger software development problems. We just don't have enough experience with XP scaling to large teams spanning offices.
dW: How do you see the Java technology versus Microsoft's .NET battle?
Booch: The world has two great religions: Microsoft and not Microsoft. Today's marketplace dictates that for enterprise systems you must choose either .NET or Java enterprise technology. I believe both platforms will persist in the coming years because, while from the 65,000-foot level they look similar, at the most basic level they're different.
Sidestepping the middleware arena, however, I'm more interested in Web services coupled with XML schemas because you can assert system architectures independent from middleware platforms. That said, I don't see a viable economic model in Microsoft's Web services view; rather Web services will prove powerful by raising the level of abstraction for developers. Both .NET and J2EE prove far too complex for the average developer to work with -- they both have too many knobs and dials to twist. To their credit, both .NET and J2EE keep raising their level of abstraction by absorbing common practices.
dW: What do you think of the various object-oriented (OO) programming models -- COM+, Java technology, .NET Framework objects, Perl -- available to programmers today?
Booch: Well, there are too many. That's both good and bad. It's good because so many models indicates a vibrant marketplace. As organizations gain experience building enterprise systems, some models may drop to the side.
Such disparate models will continue for a while, but with what's happened in the patterns movement and design patterns community we finally have a language to describe those patterns. That should help reduce the number of programming models by raising the level of abstraction.
Let me amplify something: looking backward and projecting forward on software engineering, the industry has faced complexity issues by raising the level of abstraction. We see that in the rise of middleware, for example. Middleware represents levels of abstraction on top of operating systems by codifying common experiences -- giving economies of scale, thus the economic incentive.
dW: Do you see risks in raising the level of abstraction too far?
Booch: Yes, if you go too high you cannot control the underlying system, but that's not necessarily bad. The problem can come when you raise the level of abstraction so high that it becomes difficult to debug when mysterious things happen.
dW: People have hyped OO programming for years now. Where do you stand on OO programming's reality versus its hype?
Booch: I generally don't believe hype. Maybe I'm a cynical person that way -- there is no silver bullet. As I mentioned earlier, software development has been, is, and will remain difficult, and I foresee nothing that will change that. In terms of objects, the hype claimed it would increase reuse. Well, yes, it did, but in ways we didn't expect because OO programming languages led to design patterns. As a result, we're seeing reuse at a level orthogonal to programming languages, namely the level of design itself. Did we achieve the reuse promise? Yes, but not in the way we originally thought -- a truism for many technologies.
dW: So you don't see OO's original reuse intention being fulfilled?
Booch: My objective with OO programming never was reuse. Instead, objects for me provide a means for dealing with complexity. The issue goes back to Aristotle: do you view the world as processes or as objects? Prior to the OO movement, programming focused on processes -- structured methods for example. However, that system reached a point of complexity beyond which it could not go. With objects, we can build bigger, more complex systems by raising the level of abstraction -- for me the real win of the object-oriented programming movement.
|
Grady Booch speaks
What does the future hold for software development? Hear Grady Booch expand on his software development ideas and predictions at the IBM developerWorks Live! conference (April 9 - 12, 2003).
To find out more about Grady Booch's speech, as well as hundreds of technical sessions, check out the IBM developerWorks Live! site.
|
|
dW: To wrap up, what's coming next for UML?
Booch: Developers won't see visible changes in UML 2.0. Many 2.0 changes will ease tool developer's move to model-driven development. We will see tangible improvements in component semantics because, given today's middleware, the notion of components has matured. Another improvement will let us graphically model business rules and processes. Ultimately, UML 2.0's big win will give us a stronger technological basis for doing model-driven development.
Resources
- Grady Booch will speak at the IBM developerWorks Live! conference April 9-12 in New Orleans.
- The developerWorks Resource Center for Rational Software introduces you to Rational's powerful software development tools.
- Grady Booch has written numerous software-development books.
- Grady Booch's recommended resource list:
- He visits Slashdot several times weekly.
- For readings in distributed development, he recommends Pamela Hinds and Sara Kiesler's Distributed Work.
- In the Agile Development space, Grady advocates these writers:
- Discover how you can add aspect-oriented programming to your Java projects in "Improve modularity with aspect-oriented programming" (developerWorks, January 2002).
- JavaWorld offers a short series introducing aspect-oriented programming, "I want my AOP".
- In his column Java Modeling, Granville Miller offers a four-part introduction to UML.
- To better manage your UML-based design process, read "XMI and UML combine to drive product development" (developerWorks, October 2001).
- Rational's UML Resource Center explains UML's ins and outs.
- The Object Management Group's UML page offers good UML information for both beginners and experts.
- For more insights from Grady Booch, read "
Interview: Rational pursues liberation for app dev teams" (InfoWorld, August 2002).
- To cut through the XP hype, check out the Demystifying Extreme Programming series on developerWorks.
About the authors | | | Michael O'Connell is the Editor-in-chief and editorial director of IBM's developerWorks site, and has worked as a computer journalist since 1991. Before joining developerWorks, he served as founding Editor-in-chief of IDG's JavaWorld magazine. He also was one of the founding editors of SunWorld Online, and an editor for Advanced Systems, Workstation News, and other technical trade publications. You can contact Michael at moc@us.ibm.com. Thanks to freelance editor Scott Plamondon for his contributions to this article. |
| | | Scott Plamondon, a former senior editor at JavaWorld, is a freelance journalist specializing in technology. |
Rate this page
| |
