In the beginning was the flowchart. Software diagramming - a warning from history.
regdeveloper.co.uk
regdeveloper.co.uk
Then came the "consulting industry" asking the question, "How can we squeeze a few more bucks out of this situation?"
So they came up with stuff like UML, DFD, Rational Rose, etc., etc., etc. to support their primary objective, which has always been...
<cue dramatic music>
To make those who do not know what they are doing appear as if they do.
</music>
How else could they take someone who knows nothing, pay them $50K per year and bill them out at $250 per hour?
Every time I read a post about "diagramming", I'm reminded of the end of a Boston Celtics game in the late 80's. Down by 1 point with 3 seconds left, Coach K.C. Jones was diagramming the play on his chalkboard when Larry Bird wiped everything off it and said, "Gimme the ball." They did. He shot. They won. So much for diagrams.
Nothing like reading a critique from somebody who doesn't know what they are doing and using some technology as a straw man.
UML class diagrams are good. UML class diagrams are love. Leave my UML class diagrams out of this! (grin)
I'd go with the bigger point that engineers never met a helpful tool that they couldn't eventually overengineer and beat into something that people loathed.
Or, rather, my colleague's bastardized version of it. When in doubt, stick another moment-interval in between some green stuff to make it look "right".
Then again, I live in BPMN these days. Or, rather, in limbo between BPMN and UML Activity.
I completely understand the gist of the article. Diagramming is supposed to be a tool for communication, collaboration, and discussion. But instead it becomes some kind of tool to control the universe. Sometimes I wonder if we only need about 1-5% of all of the tools we use. The rest is just overkill.