The Future of Software Development

Executive Editor , Computerworld |

Some people have a hard time figuring out what they're going to do for lunch tomorrow. But Grady Booch, one of the original developers of the Unified Modeling Language (UML) and chief scientist at Rational Software Corp. in Cupertino, Calif., has a time horizon of the next three to five years. So Computerworld asked this software engineering visionary about what he sees on the horizon for programmers of complex systems.

Q: Why is modeling so important?
A: Humans have a limited ability to deal with complexity. And models are a means of expressing complex things at a higher level of abstraction.
We see modeling in every engineering discipline -- from civil engineering, where we have blueprints, to mechanical engineering, where you have models to describe the behavior of things. The reason we do that is that, given models, we can reason about the system in different ways than just staring at the weeds of the code itself. We advocate a risk-driven approach. You identify the key risks in your project and you aggressively attack them first. With a model -- especially UML -- you can look at the architecture from different angles.

Q: Are we getting any better at dealing with software complexity?


Grady Booch, chief scientist at Rational Software Corp.

A: There are fundamental limits on the ability of humans to deal with complexity, but we've been creating tools to help amplify human ability to deal with complexity.
The history of software engineering has been one of raising the levels of abstraction, which helps us deal with complexity. We see it in languages, from assembly to object-oriented; we see it in platforms such as .Net and J2EE [Java 2 Enterprise Edition], which provide services that I no longer have to build, and we see it in processes. We, as an industry, understand better what works and what doesn't. We can codify our practices so we can build on what we know works -- and that helps amplify human ability as well.
But here's a postscript: The one constant in the industry is that complexity increases.

Q: You've said we need to remove the "friction" from software engineering. What does that mean?
A: Software development is fundamentally hard. And being a human process, we have to consider what are the things that eat away at our ability to focus on delivering good software. That might be project start-up costs, collaboration costs, stakeholder collaboration, technology churn ... and the activities of a code warrior that have nothing to do with quality code. I consider those points of friction. The best we can do is start nibbling away at those points of inefficiency. We need to find processes and means of automation to reduce that friction and produce a frictionless surface of software development.
We don't want to eliminate the social things, like the virtual water cooler that helps to build the team, but we want to have tools and processes that remove some of the tedium and free the developer to do other things.

Q: Has market acceptance of object-oriented programming turned out the way you had hoped?
A: It has exceeded my expectations. Great technologies become invisible. Object-oriented programming used to be a thing unto itself, but now it has entered the mainstream of development. All of the mainstream programming languages -- Java, C++, C# -- are object-oriented. It's woven itself into the psyche of software development.

Q: What's the future object-oriented programming?
A: I'd like to expand that the future of software engineering in general. I polled some 500 [software experts] and asked them the same question, and virtually everyone said this stuff will get more complex over time, and we have to fight this growing complexity.
Other trends we saw:

The emergence of pervasive computing, such as distributed applications and the wireless Web.

The rise of platforms such as .Net and J2EE. It's not a bad thing that we have two platforms. It's annoying for developers who have to make a choice, but competition between the two makes both of them better. With Web services, we can deliver services that transcend those platforms. Ultimately, platforms such as .Net and J2EE become commodities over time, which forces the platform makers to keep making them better.

The rise of architectural patterns. The idea of a pattern is providing a common solution to a common problem in context. For all well-structured object-oriented systems, you find the same societies of classes working together in the same kinds of patterns. We're seeing a rising level of abstraction from design patterns to architectural patterns as well. In the military world, there are some common patterns for command-and-control systems, for example. There are common architectural patterns that can be applied again and again.

We see the rise of agile software-development methods. Agile methods are a good thing because they address the social dynamics of small teams, for which the Rational unified method is silent. But it's also good to have an interplay between the two, because there are a lot of things that the Rational unified process deals with but for which the agile methods are silent. So we have some learning to do on both sides.

Aspect-oriented programming. If you look at complex systems, there's no single view that's sufficient to describe the interesting complexity of that system. It requires multiple views. There's a networking view, a component view. Aspects such as security cut across those views. How do you express the stakeholders' security requirements and architecture to the rest of the system without being incredibly disruptive?

Further out, we'll have the advent of collaborative development environments. It used to be that people did development with command-line editors and compilers ... then we moved to the notion of an integrated development environment, or IDE, with programmer tools on the developer's desktop ... and now the extended development environment that adds requirement tools, design tools, configuration management tools. As we deal with larger, geographically distributed teams, then we'll need a collaborative development environment -- a virtual meeting space.

Q: Will Web services really lead to the componentization of software?
A: The current economic model that most of the platform vendors have for Web services is fundamentally flawed. I don't see corporations going off and building systems upon Web services for which they have no control. And so the notion of this large economy of Web services that people buy and sell and trade and use -- I don't believe it will materialize, just as it hasn't materialized for the component business either. The reason is one of trust and control of those components themselves.
What I do find happening is that organizations are leveraging off of standards such as [Simple Object Access Protocol] and XML to deliver their own kind of services internally that they'll never expose to anyone else. Why is that of value? There's a great gap between what those .Net and J2EE platforms provide and what I have to deliver. If I'm in a bank, I've got business people who know the arcane rules of currency transactions, but we're not going to turn them into programmers. The solution is, rather than bringing them down to the programming language, bring the platform up to them.
"Many organizations doing this already componentize what they're doing, but there hasn't been a standard way to deliver up those components. For those organizations, Web services isn't hype -- it's not that big of a deal. It represents a recasting of the component architecture they already have in more standard ways. That's a good thing for everybody.
I view Web services not as revolution but as a common evolution of standards and fusing into the whole [existing] component-based approach.

New Tools, New Choices

Stories in this report:

Software Development

Mitch Betts is an executive editor at IDG Enterprise. He was previously executive editor of CIO and Computerworld magazines.

It’s time to break the ChatGPT habit