The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Why write workflows with diagrams?

Why do worflow tools require workflows to be writtten in the form of diagrams?  We don't write any other parts of apps as diagrams, so why workflows?
Anon for this
Friday, May 11, 2007
Maybe, because the adage "a picture is worth more than a thousand words" apply?
Phillip Send private email
Friday, May 11, 2007
Because if you write them with text, it's a language.
Friday, May 11, 2007
Who is the audience for the picture? 

Programmers?  Business users?  The former are quite comfortable doing everything else with code.  Why do they need diagrams just for workflow?  The latter might like to think that the diagrams will be readily understandable, but for any non-trivial diagram, is that really true?

Anon for this
Friday, May 11, 2007
Some of us programmers like pictures, please don't assume that all programmers love code so much we want to eat, breathe and sleep it. It hinders our external communication to.


Saturday, May 12, 2007
True.  But why is "workflow" the only programming domain where everyone expects to actually execute those pictures?  You might indeed draw UML (or whatever) for all sorts of apps, but you don't normally expect the diagrams to _be_ the program.
Anon for this
Saturday, May 12, 2007
Workflows are to a certain extent flow charts which are best understood in a visual sense (I remember having to write Finite State Machines at university, they're a lot more confusing in text than as a chart).

In most common Workflows each element of the diagram will have code attached to it, to either email someone, transfer a file or just do some internal processing. The diagram is a very efficient way to manage that.

Actually while I write this I get the impression that all code fits this description to a certain extent. So really who knows? :-)
Nigel Sampson Send private email
Saturday, May 12, 2007
At least in theory, the intended author of "workflows" are not developers, but business analysts/MBA types. These folks will typically document processes using flowcharts, so it makes sense (to marketing folks, anyway) that you should be able to enter these things into diagrams.

Of course, in practice nothing the analysts produce actually makes any kind of sense, so the devs are stuck dragging and clicking in an attempt to get the $@!$#!% diagram to do what it would take three lines of code to perform.
Chris Tavares Send private email
Sunday, May 13, 2007
Gregor Hohpe calls diagramming tools "doodle-ware". I tune out pretty quickly when a vendor starts demonstrating them. They look great in a brochure or demo, but I still have nightmares about diagrams with hundreds of nodes and lines. They also tend to fall into the category of easy to do easy things, but impossible to extend to do hard things.
Stan James Send private email
Monday, May 14, 2007
What's the alternative? Haiku?

The convenience of diagrams is that you can quickly pick out paths and branches. You can similarly do Venn diagram analysis if the graph was constructed well.

I don't know about you, but I don't always want to hundreds of lines of code just to figure out which steps and functions are called in a specific scenario. (Sometimes it's a necessity, but the diagram gets you in the right neighborhood instead of starting at line 0.)
Monday, May 14, 2007
"...I don't always want to [read] hundreds of lines of code..."
Monday, May 14, 2007
Diagrams help visualisation. Visualisation helps humans better understand, analyse and remember information, tackle complexity. Mathematicians visualise complex data all the time. 

One of the problems with software generaly, as Mr Brooks has noted, is that its hard to visualise.

Workflow diagrams, however, is just a model of real process and as such doesn't contain all the detail of the real world. It also tends to abstract the details that are not critical to its understanding.

Code is a different matter. It has all sorts of abstraction layers and tiers built into it (see Joel's Law of Leaky Abstractions). Therefore, you naturally have to do some extra work to incorporate all that detail.
John Cribbon
Thursday, May 17, 2007
Someday say maybe 2 years from now you may have to revisit a section and figure out WHY you had that code doing those things.
Joeinmi Send private email
Monday, May 21, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz