.gif) |
| Grady Booch Discusses .NET and the Art of Software Development |
.gif) Grady Booch is recognized internationally for his innovative work on software architecture, modeling, and the software engineering process. He has been with Rational Software Corporation as Chief Scientist since its founding in 1980. Grady is one of the original developers of the Unified Modeling Language (UML). He's the author of six best-selling books on computer science, including The Unified Modeling Language User Guide (Addison-Wesley, 1999) and the seminal Object-oriented Analysis and Design with Applications (Addison-Wesley, 1994). MSDN® Magazine recently caught up with Grady to discuss the impact of Microsoft® .NET and Visual Studio® .NET on the world of software development.
MSDN Magazine How would you describe the trends and the changes you've seen over the past five years in software development and how do you describe your influence on those trends?
Grady Last summer I was invited to keynote the international conference on software engineering on that very topic, the future of software. As Alan Kay once said, "The best way to predict the future is to invent it." So we're certainly in the process of helping invent some of that future, but given that there are lots of other folks out there doing the same, I chose to interview about 500 interesting people around the world. Those 500 included virtually every Association for Computing Machinery (ACM) and IEEE fellow working in the area of software engineering, every living Turing award winner, and lots of interesting CTOs and CIOs, and some CEOs as well. From that I began to draw some conclusions in terms of the future of the business as well as the future of software itself. I'll really concentrate upon the latter.
There is no doubt that the presence of the Web has changed everything, not just in terms of how we deliver applications, but also the means by which we create those applications. We see a number of folks using the Web as their virtual meeting space for projects. I think that is a significant step forward.
As I look at the general software engineering trends, I would say that there are a handful we can discuss. It really was in the late 1990s that I think we, as an industry, began to understand what the best practices for software development are—what works, what doesn't work, and the kinds of tools that codify those practices. Certainly since that time there have been some interesting developments such as XP. And here I don't mean Windows XP, but the original definition of the term, extreme programming, which I think brought to the table some interesting ideas about the social dynamics and the psychology of small teams. Now the reality is that XP and the Rational Unified Process are not opposites of one another, but rather they complement one another very well. Indeed, if you look at the sizes of teams that organizations have, especially those that are building Web-centric apps, they tend to be modest-sized teams. The truth is, no team is an island and those teams tend to work in teams of other teams. Therefore, you really need the proper processes at all levels.
From a technical perspective, I think there are several key understandings that have happened over the last five years or so, in this order: the first is the mainstreaming of object-oriented technology; the second is the creation of UML, which has given us a basis for a common language and a blueprint for software, and last, the notion of software patterns as best typified by the work of the Gang of Four. What is interesting about patterns is that they represent a step up in the next level of abstraction. Indeed, if you look across the whole history of software engineering, it's one of trying to mitigate complexity by increasing levels of abstraction. And object-oriented technology followed by design patterns is indeed that natural trend.
I think the advent of technology such as the Microsoft .NET Framework represents a realization by the industry that there is quite a bit that can be codified at the middle level. It really represents the proper separation of concerns between those who are building applications and those who must architect the infrastructure because what's in .NET represents a lot of the infrastructure that, in previous decades, organizations had to build on their own. Furthermore, it builds off of so many wonderful standards like SOAP and XML, that it makes it far easier for organizations to build applications that are quite sexy and quite complex and that can do great things for their business. That's where we are today.
MSDN Magazine What are the changes you expect to see in the coming years?
Grady That's really the role I have—to look beyond where we are today and into the future. As I think about the next three to five years, I see two things on the horizon that are particularly interesting for me. The first one is the advent of what I call collaborative development environments (CDE), and I think this will be of immediate use to the readers of MSDN Magazine. Consider for a moment the creation of Windows® 2000, which was developed by a team of people that was so large that they could not physically sit in the same room. I understand that oftentimes the team would use Microsoft NetMeeting® to keep in touch with the larger extended team. We see this happening in the construction and manufacturing industries. The use of the Web is the basis for development.
I believe the same thing will emerge over the next few years for developing an environment for software. It really does represent a discontinuity from the traditional, integrated development environment to the collaborative development environment—environments that are Web-centric and artifact-centric, meaning the tools become more invisible and they can present multiple views to different stakeholders. There are a variety of technologies that exist today in terms of things like NetMeeting and WebEx for conferencing and sharing of media over the Web, discussion groups and virtual meeting spaces, and virtual project spaces on the Web. There is no one killer application, but it's really lots of small things that work together to form these CDEs.
I alluded to this notion of multiple views, which leads me to the next great leap I see—the notion of aspect-oriented programming (AOP), which has been pioneered by Gregor Kiczales of Xerox PARC and others. In fact Charles Simonyi, in his work on intentional programming, really has a piece of the action as well. Charles, Gregor, and I were together this last summer at DARPA and National Science Foundation (NSF) meetings looking at the future of software and software research. The three of us realized that there really is something fundamental here in terms of how software development might be approached from a multidimensional perspective. Charles had some really fascinating ideas about IP, as did Gregor. We bring to the table the notion of multiple views and building a system architecture. I think as I project out over the next several years, I see AOP becoming an interesting development. Keep in mind, it's not that AOP is replacing OOP; rather, all the work we see going on with aspect-oriented programming, especially at Gregor's end, tends to complement what is already happening with the UML and OO techniques.
I guess the last thing I'd say is that software is still fundamentally the world's most important industry. Even in these shrinking economic times, business, organizations, and individuals rely upon software. There will be no end to the need for the services that the professionals in our business provide. These are very exciting times.
MSDN Magazine Do you feel like you've had direct influence on all of those trends you've just discussed?
Grady Yes, especially in the area of OO programming. I guess I could make the claim, or I will make the claim, that I probably published the first use of the notion of OO design back in 1982 or 1984 by writing the first paper on the topic. Bjarne Stroustrup and I sort of found one another through our collective writings. It was in the late 1980s that he and I went off on a tour together because we found that his work in C++ and my work in object-oriented design really complemented one another. So I think there is some small piece I had in helping people use C++ effectively.
Of course with the creation of UML, Dr. Ivar Jacobson, Dr. James Rumbaugh, and I were the key instigators. Even though we were the ones who were the original authors of the UML, the truth is that UML has gone far beyond us. We see the use of UML to model business processes for real-time embedded systems; and indeed there is current work to provide a UML mapping to Web Services as well. I think that is relevant because as organizations move to more and more complex things—technologies such as the Web Services Flow Language or XML itself—we find that as you become concerned with issues of scale, having a common set of blueprints that all your stakeholders can deal with makes a significant difference in managing the complexity of the system. Then lastly, I keep my fingers in things like AOP and patterns and such, so I'm a busy guy.
MSDN Magazine What was your first reaction when you heard what Microsoft was doing with .NET?
Grady I thought it was great, because as I look at the ways people struggle with technologies on the Microsoft side and the COM/COM+ world, and on the non-Microsoft side of CORBA, my reaction has always been that there is more complexity here than there needs to be. So I applauded the presence of .NET as the codification of many things people previously have had to do themselves. I would claim also that .NET represents yet another step up in level of abstraction. Previously people had nothing to build upon. Then there were operating systems, and then there was middleware. Now there are things like .NET that raise the level of abstraction so that I, as a developer, can focus on those things that are fundamentally value-added for me—mainly the stuff about my business—and I have to worry less about all the infrastructure below me. Anything that reduces complexity and allows me to build applications of quality more quickly, I welcome, and .NET does that.
MSDN Magazine Do you think that the .NET Framework will change practices of object-oriented analysis?
Grady Well, I want to answer that question in terms of methodology, but let me also answer it in terms of teams and processes. Increasingly over the last few years, I've seen organizations struggle with using all of these technologies, and there has been considerable technology churn that made it very challenging to say what technology they should select. So we found within organizations a small set of people who really understood the middleware and all the plumbing very, very well. Then you had the people who understood the business very, very well. But getting those two teams to communicate was—and always has been—very challenging. You throw into the mix your database folks who sort of live and breathe schemas and know all that. Even worse, in terms of added complexity, you have all the people who are content creators. Those folks know HTML inside and out, and they can build wickedly beautiful Web pages. So all of a sudden for modern systems, you have a constellation of stakeholders that's far more complex than it was in the past. So keeping those people together has always been challenging. The UML helps teams carry out the best practices of software development that we have identified.
With the advent of Microsoft .NET, what you see is the opportunity for all those worlds to communicate much more effectively. .NET raises the level of abstraction, so as someone who might know all the things about my business, it is easier for me to isolate or segregate the business parts of my project and build on these higher-level abstractions.
From a methodology perspective, I think the presence of .NET and object-oriented technology are still incredibly complementary of one another. Because all well-structured systems we see that rely on this technology are still inherently object-oriented, .NET presents—especially through Web Services—sets of objects that people must combine in interesting ways.
I think .NET creates the opportunity for higher level frameworks as well. In fact, in that effort we have at Rational a thing called a Reusable Asset Specification (RAS), and Microsoft is a member of this consortium. This group is composed of all the major component vendors—IBM, Component Source, and FlashLine, among others. The initiative is to first specify a common way to deliver assets—code assets, test assets, release assets, vision assets, and requirements assets—all the things associated with the major framework. The RAS specification has been circulating for well over a year and is reasonably stable. And we're tackling the .NET side first. So now the attention of these teams is on harvesting potential frameworks against .NET and other middleware so that we can deliver up higher-level patterns. You can think of this as representing yet another step up from the Gang of Four design patterns into the domain of frameworks. Once I deliver up frameworks (and, by the way, these are inherently OO-based), I then provide mechanisms that application builders can build against. So it's bridging the gap between .NET and what has to be delivered.
.gif) MSDN Magazine Visual Studio .NET has incorporated quite a few more modeling features. What do you think about this?
Grady I think it's great. It recognizes from a Microsoft perspective that modeling is a good thing. I've certainly always known that, but then I'm a little bit biased. I think that whatever can be done to push modeling further is an excellent thing. Here I've got to refer to the work of another gentleman, Edward R. Tufte, and his classic books Envisioning Information (Graphics Press, 1990) and The Visual Display of Quantitative Information (Graphics Press, 2001). What he observes is that the right kind of models and the right kind of abstraction not only help you deal with complexity, but they also help you look at problems in a fundamentally different way so that you can break through that complexity. That's what UML is all about. That's why modeling is so relevant. Modeling helps you deal with complexity, and it helps different stakeholders communicate with one another. If I'm the business person, I know my business rules, but I really don't want to know C# or Visual Basic. I really want to express these business rules in my language. That's some of the basic tenets behind Charles Simonyi's work on IP by the way—the notion that you have a domain-specific representation of things. Moving down to the software level, that's where the UML sits, and that's why I am delighted to see more and more modeling in Visual Studio .NET.
MSDN Magazine One of the things that is easier now with Visual Studio .NET is being able to mix multiple languages in a project. What do you think about special opportunities or problems that this creates?
Grady I used to be a language bigot. I thought years ago that ADA was God's chosen language. Then I found C++, and I thought I was wrong, so I changed religions. Then I saw Smalltalk, then I saw other languages, and I realized I need the right language for me technically. While the choice of language is often not a technical decision, there is a cultural decision associated with it—the culture of my team, what they've used before, the domain they have worked in, and so on. So, because I looked over the current crop of languages that are out there—C#, C++, Visual Basic®, and lots of other languages in that same space—I now believe that, yes, at some levels they are different, but at other levels they are also very similar. It's not so much the language that is essential for me unless I am talking exotic languages like the Common Lisp Object System (CLOS) and the like. We're talking about most kinds of languages that developers work with. It's not so much the language that is relevant to me; it's all the stuff that surrounds that language—its frameworks, its tools, and its components.
The reality is, I can find very, very few projects that involve a single language. I was just talking to an architect of a company that builds cell phones. He was telling me about their next-generation phone, that it will include lots of different languages, from Assembly on up. That is the reality of most projects. They are not single languages, they are not homogeneous, they are heterogeneous. Like it or not, the culture demands that organizations deal with multiple languages simultaneously. A single team might have a single language, but with the organization as a whole, you generally have multiple languages. Therefore, anything that will help bridge the gap and break down the walls between these languages is a great thing. That's one of the things .NET does well.
MSDN Magazine Have you looked at C#? What do you think about its influence?
Grady Again, given that I am less bigoted about languages these days, I am less concerned about new languages that come out. I think C# has some wonderful features in it, and because it's not the only language I can use with .NET, it's a great thing. Relative to C++, it's a little simpler and a lot nicer in some ways. I still predominantly use C++ in the things I do, but then I work in a lot of systems besides just Web-intensive ones.
MSDN Magazine Another aspect of .NET is being able to use side-by-side assemblies. Do you think this is good, or do you see this perhaps leading to sloppier releases because they can be easily fixed?
Grady As for sloppier releases, I don't think the marketplace will tolerate them to any greater degree than it has in the past, just because fixes can be implemented more easily. Anything that facilitates an incremental process is a positive development. Here at Rational, we have ClearCase. ClearCase is a powerful tool because it supports multiple releases almost simultaneously and multiple views of system development. In today's world, you never have a single kind of release, especially in distributed systems. You have different versions of things deployed in different places, and you are constantly making changes. So we need anything that facilitates the rapid, quality, incremental release of systems.
MSDN Magazine Have you seen projects at Rational or at other companies where the architectural guidelines are set ahead of time, as you can do in Visual Studio with enterprise templates. Has that approach been successful?
Grady I am a great believer in architecture first. Here (in Visual Studio .NET) we have an IDE that lets the architect impose their view upon the world. In a sense, this allows some degree of multidimensional development and allows the architect to have some control, which is a good thing. Now, whether that kind of architecture control will be well received by organizations frankly depends upon how well they understand the importance of architecture. From our experience, having a solid architecture is an excellent predictor of project success. I don't mean heavyweight kind of architectures, but architecture in the sense of codifying significant design decisions early.
One of the things I do at Rational is to serve as an architectural mentor on projects, so I actually do a lot of architecting myself. About a year ago, I was working with a chief architect at a large Swiss bank that had just merged with another large Swiss bank. He looked at the systems that they had to build, and I'll paraphrase him in two ways. First he said that there aren't enough PhDs in all of Europe to build the thing he needed to build. And second, he said that the software fundamentally is the bank, so what they were building was essential to the future of that organization. As the architect, he realized they could have lots of people coding things left and right, so there were some significant technological risks ahead. The purpose of that architect team was to establish the basic frameworks and the basic mechanisms by which all applications would be built. By developing those, validating those, making sure those worked before you start employing lots of other people, the architecture actually served as a means of attacking risks. To put it clearly, according to Tom Gilb, "If you don't actively attack the risks in your project, they will actively attack you." One of the major technical risks is the presence and absence of the strong architecture. By architecture, I don't mean "tight restrictions," but rather the specification of the key mechanisms by which applications will be built.
MSDN Magazine At the magazine, we hear points of view on both ends of the spectrum. We have many developers who are extremely excited about .NET and who have investigated it and have Web Services up and running even on beta software. Yet we also hear from those who are still trying to deal with a lot of legacy systems and really don't want to hear about .NET yet. What advice do you have for developers today, and what do you see as the best things they could do to move toward the future?
Grady Technology churn is always a challenge. You know, many legacy systems are what keep people in business right now, yet they still must move forward with new kinds of technology. What .NET provides through Web Services is really a very different way of constructing systems. The shift toward systems that are delivered up as services with the use of SOAP and XML to transport objects across firewalls, in effect, is indeed the very natural direction Web-intensive systems are going. In fact, if you look at all the stuff going on inside the W3C and Tim Berners-Lee's notion of the Semantic Web, all these technologies push us more and more in that direction, so that kind of change is inevitable. I would therefore offer the general guidance to those teams to focus on some of the best development practices, architecture first, the use of modeling, controlling your change management; these are fundamentals that will prepare you to absorb technological change, which you'll have to do over time. If you're moving from C++ to C#, it is not that great of a leap. Making the move from client/server to Web-intensive systems has been jarring for some, but moving from Web-intensive systems as they're being created today to Web Services is not that great of a leap. I expect we will see organizations struggle to build their own kind of Web Services because they would initially choose to not build upon public services out there, unless they are provided by a platform member such as Microsoft. It simply has to do with trust, availability, security, and scalability. And so they will probably dabble by building their own services, and later build systems upon public services.
MSDN Magazine We hear a lot about design patterns, and you mentioned aspect-oriented programming. Do you include those in your general advice for teams?
Grady As for design patterns, absolutely. Design patterns are something that all hyper-productive teams that I've encountered use. What's great about design patterns is that they give a team a way to talk at higher levels of abstraction. When I'm at a project and say, "Oh you should use a proxy pattern here" or "You should use pattern X," they'll immediately know what I'm talking about. The best projects will start creating their own kinds of patterns, too, and that's great. So design patterns fit in as sort of platform-independent technology because they're a way of using object-oriented technology even more effectively.
As for aspect-oriented programming, this is really something that's a few years out. We see some ideas that are coming to fruition, but I certainly wouldn't want to bet my business on AOP at the moment. However, it certainly interests me as a technologist. I worry and care about these things because I need to help people make the next leap and to build quality systems.
MSDN Magazine Are there comments you'd like to add or are there additional messages you would like to convey to our readers?
Grady If I were to summarize, I would say three things. First, software development is still the world's most important industry, and so what we do as an industry is still fueling the world's economy. Businesses of quality and enduring businesses still rely upon software. Organizations, countries, everyone relies upon software and that will not change. If anything, it will become more and more important over time.
The second thing I observe is that software development is still wickedly hard. That's why we, as professionals in this field, must employ whatever we can to provide systems on time, with high quality, because in a sense the world is relying upon us.
The third thing I'd mention is that it is an exciting time to be in the software industry because of all these things. I'm pleased to see new initiatives such as .NET, the steady adoption of best practices that we have at Rational, which complement what Microsoft offers. And I'm pleased with things like the RAS specification, design patterns, and such that I mentioned. All these things contribute to the toolbox for the individual developer, the team of developers, and the teams of teams to help build those systems with quality.
|
|
.gif)