Diagrams are our friends

Simple Flowchart: http://en.wikipedia.org/wiki/Flowchart

Simple Flowchart: http://en.wikipedia.org/wiki/Flowchart

The linked article is not a particularly strong one, but I agree with the basic premise that making diagrams can be a fantastic way to communicate your ideas. Also, it got me thinking of how I use diagrams at work and home.

I deal a lot with complex systems, most of which don’t exist when I’m dealing with them because I’m helping someone design them, translating their system requirements into sets of software (and often hardware) components that will not only fulfill their requirements but function as an optimal system to fulfill their mission goals. Those of you who’ve worked with customers designing systems, especially complex and expensive ones, know that considering only written requirements is a recipe for a very suboptimal system and often a disaster. IBM is now infamous for this practice. See http://www.cringely.com/2013/08/07/fulfilling-customer-requirements-is-a-weapon-at-ibm/ for high level details.

Many humans can only grasp complex relationships (i.e. systems) when they’re presented in a visual format. Even for those of us capable of wading through a huge mass of documents and discerning the purpose and critical requirements of a system, it’s usually very helpful to create diagrams of what we think the system’s properties are, so we can communicate this to both colleagues and the customers, to be reasonably sure that we all end up agreeing on the same architecture.

A mistake in understanding here can be costly in time, money, and reputation, since it’s often easier for a customer to blame the engineers than accept responsibility for a mistake. It’s just human nature to point fingers when something big goes wrong.

Okay, I really just wanted to say here that it’s worth the time to draw a diagram, structural, flowchart, whatever is appropriate, to help you understand and follow through on tasks, especially if you need to coordinate with others on a project. I often put off making architectural diagrams because it’s a pain in the ass, with Visio at least (thanks Microsoft), but I never regret putting in the time to create a diagram once it’s done.

There are advantages to creating diagrams even apart from communicating with others. Creating a clear representation of an idea or set of related structures (i.e. the diagram) forces you to clarify and often refine or substantially change your proposed architecture as you see things that sounded good in your mind but on “paper” are obviously suboptimal or unworkable.

Finally, you’re already using diagrams. A task or shopping list is a simple diagram, as is an itinerary or schedule. These tend to more text based than visual, but as you’ve probably experienced, even these simple diagrams can increase your understanding when you add order, time, and spatial (e.g. a map) relations to them.

I hope this was helpful. I started out to write a much simpler article but a lot of new thoughts jumped out and demanded to be included.

Leave a Reply

Your email address will not be published. Required fields are marked *