Grady Booch gives his opinion on the UML as part of this interview .

Let me just highlight the best modeling-related comments in the interview for those that prefer not to read it in full (comments mine):

• When we began with the UML, we never intended it to become a programming language. I agree, modeling makes sense when the abstraction level is higher than that of programming languages. However, I’d say that most people do not use UML as a programming language (except, maybe, for those following the ExecutableUML approach). I think it is just the opposite, UML is used more as a sketch .
• I think that there’s a fairly narrow domain for which model-driven development makes sense : I disagree, I think the combination of UML and/or DSLs (depending on the domain) allows model-driven to be beneficial in many domains
• we should return to the roots OF the UML : assuming that he means that UML has become too complex, I think we all agree with this and, fortunately, even the OMG has realized about it
• one should only use a graphical notation for those things that cannot easily be reasoned about in code… most important artifact any development team produces is raw, running, naked code. Everything else is ssecondary:again, here Grady seems to completely disregard the whole field of model-driven development. I wonder why. True, we don’t have many empirical studies proving the benefits of model-driven development (I’m collecting those I’ve found so far for a future post) but I don’t think going back to code-centric development process is the solution (but, of course, I’m not Grady Booch so I don’t expect you to believe me 😀 )

Additional opinions, now taken from InfoQ interview that I recommend to read in full. Enjoy (and discuss)!

Regarding the UML

• The notation retains modest use, but the underlying concepts live on. The penetration of the UML probably never exceeded 10-20% of the industry, although some domains – such as in the hard real time world – found use much higher.
• The MDD movement turned the UML into more of a programming language … Our intended use case for the UML was more modest: to be a language for reasoning about systems. In practice, one should throw away most UML diagrams.
• We never got the notation for collaborations right. Component and deployment diagrams needed more maturing. The UML metamodel became grossly bloated, because of the drive to model driven development. I think that complexity was an unnecessary mistake.
• The presence of the UML helped in transforming the way people approached design. Second, the presence of the UML, I think, helped lubricate the demand pull for design patterns.
• I rather still like the UML 🙂 Seriously, you need about 20% of the UML to do 80% of the kind of design you might want to do in a project – agile or not – but use the UML with a very light touch: use the notation to reason about a system, to communicate your intent to others…and then throw away most of your diagrams.
• The code is the truth, but it is not the whole truth. There are design decisions and design patterns that transcend individual lines of code, and at those points, the UML adds values. The UML was never intended to replace textual languages..it was meant to complement them
• The UML should be used to reason about alternatives. Put up some diagrams. Throw some use cases against it. Throw away those diagrams then write some code against you best decision. Repeat

On Software Engineering and development processes

• The history of software engineering is one of rising levels of abstraction
• The fundamentals of good software engineering can be summarized in one sentence: grow the significant design decisions of your system through the incremental and iterative release of testable executables.
• I think that the dogma of pair programming was overrated. TDD was – and is – still key. The direct involvement of a customer is a great idea in principle but often impractical. Continuous development is absolutely the right thing.
• XP gave a name and a legitimacy to the notion of refactoring. Still, one must use refactoring in moderation. It’s ok to refactor a bit of Javascript; it is not ok to refactor a large subsystem on which human lives depend
• I think it was a sad and foolish mistake to separate BPML from the UML. I think the failure came about because we failed to find a common vocabulary with the business individuals who drove BPML.
• Development is team sport. Even further: development as a social activity, with attendant issue of ethics, morality, and its impact on the human experience.
• You really do need a language that lets you weave together loosely-coupled components in a rapid fashion. Scripting languages fit this need perfectly. Personally, I use PHP and Javascript the most in that world.
• (citing John Backus) The reason that Functional Programming failed in his time was that it was easy to do hard things but almost impossible do easy things.