Frontier Journal (FJ): You got your MS in computer architecture from UCSB, what's your perspective on adopting your co-invented UML for hardware modeling at system-level? Will the day of Unified System (Hardware/Software) Modeling come soon?

Grady Booch (GB): That day already exists. The UML is already being used for many kinds of software-intensive systems, from traditional enterprise systems to embedded ones as well as military systems and many things in between. The work that Murry Canto and others are doing in applying the UML to engineering has already proven useful in a number of hardware/software domains.

FJ: What's your perspective on next programming paradigm shifting after the shift from Structural Programming to Object-Oriented Programming? And which language will be the next big language based on the next big programming paradigm? Will that be a scripting language?

GB: It's much easier to predict the past that it is the future. If we look over the history of software engineering, it has been one of growing levels of abstraction - and thus it's reasonable to presume that the future will entail rising levels of abstraction as well. We already see this with the advent of domain-specific frameworks and patterns. As for languages, I don't see any new interesting languages on the horizon that will achieve the penetration that any one of many contemporary languages has. I held high hopes for aspect-oriented programming, but that domain seems to have reached a plateau. There is tremendous need to for better languages to support massive concurrency, but therein I don't see any new, potentially dominant languages forthcoming. Rather, the action seems to be in the area of patterns (which raise the level of abstraction).

Software developing has been, is, and will remain fundamentally hard. Mashup architectures, fueled by AJAX and SOA in the enterprise domain, are taking root, but these are less fundamental and more pragmatically expeditious than anything.

FJ: During past several decades, people in software industry have adopted many types of software processes, such as Rational Unified Process (RUP), CMM, CMMI, eXtreme Programming (XP) and various in-house software processes, what's the Holy Grail Software Process in your mind if there is any or is it just the State-of-the-Art Best Practice per se?

GB: There is no Holy Grail, no royal road to software. We as an industry tend to seek out faddish things to solve our problems, where in reality a focus on the fundamentals never goes out of style: forming crisp abstractions, having a balanced distribution of responsibilities, forcing a clear separation of concerns, pursuing simplicity fiercely: these are the fundamentals. Couple this with a development process that lets you grow a system's architecture through incremental and iterative means, and pretty much everything else is just details.

FJ: Raising the abstraction level in vertical view and separation the concerns in horizontal view are two popular ways to tackle software complexity. Now in terms of raising the abstraction level, tremendous efforts have been made during past several decades, from assembly-level programming to structural programming such as in C, from structural programming to OO programming such as C++, from OO programming to UML-based modeling, the question is how to make the refinement of high-level abstractions such as in UML to lower-level models or code be fully automatic, as it is done from C/C++ to assembly?

GB: This is why patterns are so important: they represent a higher level of design abstraction. We have means of translating patters to code (and those patterns can be expressed in models). The problem is that there is a loss of information from patterns to code, and so a really interesting problem is the automatic discovery of models from code itself.

FJ: Raising the abstraction level in vertical view and separation the concerns in horizontal view are two popular ways to tackle software complexity. Now in terms of separation of concerns, how shall we deal with the decoupling (of those concerns) issue and choosing granularity (of concerns) issue?

GB: Your question touches upon the fundamentals I mentioned earlier. Building crisp abstractions and having a balanced distribution of responsibilities is what helps you form good separation of concerns.

FJ: Software Reuse and Reinvent My Wheel are two fundamental ways in building a software system. For software reuse, so far no programming language (hence its associated programming paradigm) and no software architecture can achieve the goal for serious reuse. Is serious software reuse a hype or hope? Are we in the wrong way that might lead to the dead-end or we are at the darkest time before daybreak?

GB: I disagree with your premise: we see high degrees of reuse in many systems - it's just not at the code level, as most presumed it to be. Rather, it happens at a much higher level, in the form of patterns and entire subsystems that are reused. This is why services have gained so much traction: they permit us to reuse behavior from large chunks of code.

FJ: For any non-trivial software project, what is your Rule of Thumb on choosing software process, software architecture, programming paradigm, and software development platform based on your several decades of industry practice?

GB: Grow a system's architecture through the incremental and iterative release of executables. This is a practice common to virtually all hyperproductive projects, and notably absent from projects that fail.

FJ: What's your vision on UML after UML 2.0?

GB: I hope that UML 3.0 will be made simpler than 2.0. I also expect that the UML will be used even more for systems engineering.

FJ: Do you think the innovation in software engineering is diminishing or thriving? What's the Best Practice in software innovation?

GB: Software is perhaps the world's most important industry: what we do touches upon every other industry, and both create new businesses as well as greater efficiencies in existing ones. Some areas of the field are mature; some are still in a stage of vibrant innovation, some areas need a bit of new vitality.

FJ: What's your career advice for people who work in software industry?

GB: Being a software developer is both a privilege and a responsibility. In this field, there are so many places to grow and contribute. Learn by studying the work of others; follow your passion. Most of all, be sure you have fun in the process.

Back to Home Page