Why paint a picture, sketch a cartoon, or play an instrument? Artistic expression. Maybe there is more to these images and sounds than simply conveying how we feel. Maybe they're a communication channel, more efficient than talking or typing out the information. Depending on what you're trying to divulge, choosing the right communication channel can improve how well that information is received. This doesn't exclude communication with yourself, either.
Consider note taking — little reminders for later. It isn't the content here that's important, but rather the timeliness — it has to be now. Probably just a little scribble, utterly meaningless to someone else, but to you, it means a lot. You come across your reminder the following day, and all the context surrounding your earlier thought comes flooding back. Our minds suit our own needs best.
If we think about communication in a larger group of people, say, a software development team, things suddenly become more complicated. We're engendering the potential for ambiguity — mostly misinterpretation — unless we take the time to make ourselves clear. When we're writing code, or even just having a casual discussion about the way software should be built, we all have different angles. Our past experiences shape our opinions of software and its development.
Diagrams are an effective means to bridge differences in software development thought processes. Mostly because they're an abstract visual aid, a tool to visualize concepts. There are standards that assist us in creating consistent diagrams, such as the UML. More broadly, the aim of these standards is for it's users to construct a collection of diagrams — a model of the software system. In fact, this can sometimes take away from the value diagrams bring in advocating communication.
Problems that standards solve
The UML is the de facto standard when it comes to proclaiming what software diagrams should look like. What elements are allowed, how they're shaped, how they're connected to one another, and so on. Standards such as the UML are a worthy cause, one that I practice to the best of my ability. Understanding diagrams that someone other than yourself has created can be a strenuous exercise. Without the diagram creator's guidance, you must make sense of the meta-data in the diagram before you can truly understand the diagram's content.
This, in short, is the problem the UML solves — how do we make sense of diagram elements that describe software systems? The UML solves this problem by giving us the meta-data about our diagrams. The theory is, if Bob knows the UML, I can draw a diagram using elements found in the specification and he'll be able to interpret it without my help.
It is a good theory. It's goal at an even higher level is along the lines of unambiguous communication. I think the UML adequately meets those goals, perhaps even too profusely at times. There are elements that we're always going to use, and there are those that are hardly ever used. The abundance of different things we can represent in the UML make the language challenging to learn, but you don't need to learn the entire language. Just like you don't need to learn the English vernacular in it's entirety to communicate effectively.
Problems that standards create
With every standard ever conceived, a slew of concessions blossom as a result. Standards are standards because they're the standard way of doing something. A pattern that's beneficial to the whole instead of a subset. In the case of the UML, software development teams create diagrams to aid in communication. We now have a standard way of doing that. Any activity a team performs will impact other activities. There is really no way around that, and so, you need to strike a balance. If abiding diagramming standards means less code is written and tested, you're wandering down the wrong path.
One specific problem I have with UML doesn't have anything to do with the standard itself, but the culture it creates. That is, we have this big and powerful specification that can express everything we could ever want. And everyone understands it! Brilliant! These diagrams are obviously of the utmost value and must be preserved. I don't think this is true. It's difficult to maintain formal models of software systems. You have to make sure they reflect the current reality of the physical software. You have to coordinate with other developers to ensure your diagrams don't contradict one another. A lot of work, so where is the value?
Vast models of software systems that attempt to illuminate challenging issues with beautiful diagrams could be valuable, if they're used over and over again. For example, if your model is your project's documentation. This is rarely the case. What diagrams do best, in my opinion, is assist with the initial thought process that goes on when we're trying to solve a problem. They're a communication tool, some of which have staying power, and some don't. Valuable diagrams that you'll want to keep are fairly obvious. They're usually simple too. So if your model isn't helpful in putting thoughts about software into picture form, start focusing more on the diagrams. They're a much better tool.