Indeed, the UML has become the lingua franca for describing software. It is a good example of what happens when instead of trying to maintain a proprietary standard, one instead opens up to giving away intellectual property with the aim of creating momentum behind an industry standard. What happened was that several companies could now focus on building tools to support the UML. Each one did not have to create its own standard, and competition could take place at the tool level instead of the notation level. This in turn had the benefit that diagrams produced by different tools could all be understood, because they used the same underlying notation and semantics. In most areas of human activity, we call this progress.
Right. But developers still have to write code. Maybe less of it, if they reuse standard modules that their UML diagrams might suggest. But, still, cutting code is primordial. It is never going to go away.
Nor, I'm afraid to say, is the turmoil engendered by advances in programming languages. Our languages are getting better and more sophisticated, but they are a form of planned obsolescence. Developers have to learn a new language every 10 years or so, and this is a very disruptive process. Those that don't make the leap to the "next great thing" become consigned to maintaining legacy code in one of the older languages. This is the software developer's version of Purgatory.
As managers, we have a slightly different problem. Our code-cutting days are behind us, but languages march on. How can we familiarize ourselves with the latest language? That is the subject of the next chapter.