They usually start small, meaningful, useful, and bring practical added value. But then, something happens— those meaningful concepts become bloated, excessively complicated, overinterpreted, and even absurd or downright harmful. Why is that?
Once upon a time, I held a seminar on “100 management concepts.” I was surprised by how many of my management friends showed up to that little seminar. The curiosity was probably inspired by the sheer number of management concepts and methodologies, and the number “100,” although it appears high, does not seem to be exaggerated. I couldn’t find a really comprehensive list of all management ideas, management methodologies, concepts, and fads, but I am convinced that it would be in the four-digit figures.
UML, for example (the Unified Modeling Language), was one of such fads. For a couple of years, I was a UML trainer for object-oriented analysis and design for various organizations. Please don’t be alarmed if it already sounds too technical. Bear with me for a few minutes.
Let me briefly explain.
The purpose of the UML, to put it very simply, is to have a common understanding of “boxes” and “lines” on the whiteboard. Everything in our world can be grasped as objects and relationships between them. The only problem is the interpretation of a box or a relationship. For example, an association between objects can be a “has an interface,” “inherits,” “is part of,” “is associated with,” and so on. The fundamental idea is to replace textual, often redundant and vague essays, usually created by teams to describe (e.g., system requirements) with pictures that can be simple and less ambiguous. That’s all that’s to it. I used the handout below to summarize all essential concepts (note: the below UML charts are UML 1.4 compliant. UML 2.x notation differs in some aspects from the chart below):
That was all I needed to “sell” UML to the team. Everyone was able to understand it. Some of my trainees were sales and marketing people who had nothing to do with software, and yet they had no problem going through all those concepts and quickly developing an understanding of what UML is and why it made sense.
There are tons of concepts associated with UML, such as model-driven development, object-oriented requirements analysis and management, and many more, but that’s beside the point here. I loved the simplicity of the “old” UML. It was a practical, easy-to-understand, scalable, and generally cool idea to use instead of unspecified, proprietary blocks and lines that always often had an implicit meaning that only insiders could fully understand.
Since my past days as a UML trainer years ago, UML has gone a long way. Back then, in the late nineties, the UML specification 1.4 was already quite a book at some 400 pages. UML version 2.41, however, is now a monster of almost 1000 pages (230 pages “infrastructure” and 750 for “superstructure”).
But wait: there’s more! Take a look at the number of the UML interpretations: The OMG® Specifications Catalog. Only hard-core exponential complexity zealots remain unmoved by the seemingly endless UML adaptations. While most of those specifications seem meaningful, their sheer number renders them eventually meaningless. It is not unlikely the Soviet legislation in the past: there were so many different, contradictory laws in the Soviet Union that there was ultimately no law at all.
I feel that UML was originally great, but has become less and less useful than initially intended by its inventors: the “three amigos,” as they were sometimes referred to: Jim Rumbaugh, Ivar Jacobson, and Grady Booch. What has happened to the UML is the parade example of how something can be too progressive for its own good.
The UML story is just a slight digression from the general problem the intellectuals seem to have: we often suffer from the disconnect from the rest of the world; The ordinary corporate reality of daily work. Many other originally good ideas have suffered a similar fate, be that the structured analysis, the waterfall development, the V-model, the idealized agility, maturity models like CMMI and Automotive SPICE, or management-by-objectives, just to name a few examples. I have been through all of it, and I am not proud of what has become of those concepts.
Complexity Coach?
Always attempt to work with possibly simple constructs because whatever you do, it will soon get too complex to grasp, especially for other people than yourself.
Such a mindset is something that can be trained and couched. Only half-jokingly, I once said that we need a new role of a “complexity manager.” Maybe it was not such an outlandish idea after all.
Why not give it a shot? It is still better than just repeating the same mistake again and again, hoping for a better outcome. Fundamentally speaking: what do we have to lose?
Let’s start a conversation on LinkedIn or X.com (formerly Twitter).
I am a project manager (Project Manager Professional, PMP), a Project Coach, a management consultant, and a book author. I have worked in the software industry since 1992 and as a manager consultant since 1998. Please visit my United Mentors home page for more details. Contact me on LinkedIn for direct feedback on my articles.
Be the first to comment