Flying Logic: Just Another Outliner?

I am often asked to compare Flying Logic to other packages such as Austhink Rationale and MindMapper. I suppose the main thing that provokes this comparison is that all three are graphically-oriented programs for capturing knowledge. Traditional text-based outliner software is used for capturing knowledge too, but lacks the distinctive visual “boxes and lines” look that Flying Logic and the other packages share.

The main difference is that Flying Logic is not an outliner. What do I mean by this?

Outliners, whether they are traditional text-based ones or more visual ones like Rationale and MindMapper, are based on trees, also called strict hierarchies. If the sort of reasoning you want to do breaks down easily into this structure then outliners are fine, and of course Flying Logic does trees with no problem.

tree.png
A Tree

But Flying Logic is based on a more general structure called the Directed Acyclic Graph (or DAG). Unlike trees where every “child node” has exactly one “parent node,” in a DAG any child can have any number of parents. The only restriction is that a child not (directly or indirectly) be its own parent, a situation called a cycle or loop.

dag.png
A Directed Acyclic Graph (DAG)

In fact, FL allows cycles too, but specially treats the “back edges” that form them. This is useful when modeling so-called “virtuous cycles” or “vicious cycles.”

vicious.png
A Vicious Cycle (back edge in blue)

So Flying Logic is based on DAGs. So what?

Outliners (whether text-based or graphical) are useful when you are simply breaking a thing down into its subparts. For instance, “A degree program consists of a number of courses, each of which consist of a number of assignments.” This is a strict hierarchy. But what if you want to say that a particular course is a prerequisite for several degree programs, and see at a glance what degrees require which courses, and what courses are required by what degrees? Then the “course” entity needs to have several parents, and trees (and outliner software) do not permit this.

When modeling real-life cause-and-effect (such as when using systems thinking techniques like the Theory of Constraints), the need to break away from strict trees becomes even more apparent. Causes can have several effects, and effects can have several causes, or require several conditions, or both. This makes DAGs the most natural choice. But unlike tree-based outlines, which can be easily represented as indented blocks of text, DAGs have no simple expression in pure text without having to redundantly replicate information wherever a child has more than one parent. In other words: for trees, a graphical layout is a nicety, but for DAGs it is a necessity.

Flying Logic also includes features that are specifically aimed at modeling cause-and-effect, including junctors, operators, edge weights, and confidence spinners. Together, these allow various logical and/or mathematical relationships to be expressed, tested, and demonstrated step-by-step, including belief networks and probabilistic networks. (And they stay neatly out of your way when you don’t need them.) Outliners simply don’t do any of that.

Finally, if you look at the screen shot galleries of many graphical outliners, it’s often hard to tell whether more time and effort went into the actual planning work, or into tweaking the plethora of graphics options available. Flying Logic upholds a philosophy of Let the Planner focus on Planning. Since graphic design is not part of the planning process, Flying Logic deliberately avoids adding any graphical options except those that can be justified on the basis of supporting clean, understandable reasoning.

Flying Logic: Software for Visual Thinking

Whew! Today I’m finally ready to talk about the secret software project I have spent more than three years on: Flying Logic.

Flying Logic logo

I’ve had a really great client for the past several years: a small independent think tank near where I live in Los Angeles that has major clients in industries ranging from entertainment to automotive to furniture to defense. This little think tank is where these big players come when they want “imagineers for hire—” in other words, when they want some of the most highly skilled out-of-the-box thinkers to put their heads together and come up with some really innovative concepts— and prove that they will really work. (Sorry, these companies must remain nameless for now.)

So, one of the tasks their defense contractor client gave them was that of creating a better tool for Course of Action Analysis (COA), an essential part of the process in any military venture. My client in turn specializes in finding people like me— who have experience innovating in areas ranging from robotics to architecture to software interfaces (my specialty) and turning them loose on these problems demanding creative solutions.

Now, military planning is something I know very little about. But I could tell two things right off the bat: 1) It shares a lot in common with business process improvement, and 2) The artist conceptions of a new COA tool they had shown their client would never work (although they did get their client’s imagination moving in the right direction.) So (as is often the case) I found myself in the usually unenviable position of telling the client what they really want.

Fortunately, this wasn’t your usual client. Since this is imagineering, they were quite open to my ideas.

A couple of years before this time, I was VP of Engineering for a startup in the late dot-com boom era. Although they cratered like so many of their peers, the CEO of that company fatefully introduced me to a set of remarkable techniques and practices known as the Theory of Constraints. In particular, he recommended a book called Thinking for a Change: Putting the TOC Thinking Processes to Use. It was an easy yet exciting read: it described a visual language of cause and effect used for improving any dynamic system— business or personal.

This was great! I am a very visual person, and here were a set of visual techniques that could be used to describe a seemingly intractable situation, discover what needed to change, discover what to change to, and finally discover how to cause the changes that will lead not just to incremental improvement, but often to radical improvement. The techniques can be used by children to resolve conflicts, couples to improve marriages, or Fortune 500 companies to streamline manufacturing and multiply their markets, and they are especially applicable to groups containing diverse points of view. I remember thinking that for a complex situation, the diagrams needed could also become quite complex, and the suggested tools for creating these diagrams (whiteboards and typical drawing software) really weren’t up to the task: what was really needed was a sort of visual spreadsheet for rational thought.

But I was busy with other things at the time, and shelved the idea… until my client asked me for my take on a new COA tool. I showed them Thinking for a Change and pointed out that the techniques it described— using cause-and-effect reasoning to create new realities— closely mirrored the methods used by military planners. I said I wanted to create software where someone working with these cause-and-effect techniques could just say what boxes needed to be in the diagram and how they were related, and have the boxes and lines all fly around by themselves into the best configuration— the software would take care of all the little graphical details no matter how complex things became, and leave the human to do what they do best: creatively solve the problem at hand. To their great credit that they gave me full creative control over the project pretty much from the time I began my fanatical handwaving.

Of course, being a “Mac person,” and knowing that my client doesn’t produce finished, commercial products for their clients but only takes them to the proof-of-concept stage, I wrote the software as a native Mac application. Here again my client had no problem— they believe in giving the creative talent all the best tools that they’re comfortable with, and no-one wants to get real work done with a mere proof-of-concept. …At least that’s what we all thought until the software reached the stage where I could really demonstrate how it worked. Then their clients and the various government planners I gave demos to (even inside the Pentagon) began to ask for copies— they actually wanted to start using it right then! They were offered copies of the existing version but pretty much everyone in government uses Windows, and my software just wouldn’t play there— although I did get a few reports of executives justifying the purchase of Macs so they could run it.

We discussed what to do. My client wanted to be able to put the technology into the customers’ hands, but I wasn’t about to start writing native Windows software, so that was out. However, I did have a lot of experience writing in Java, although I had never used it to write anything so graphically intense— one of my selling points for going with the Mac in the first place was its great facility for graphics. Would Java be up to the task?

I did some research, and concluded that Java technology had advanced a long way since I had last looked at it— enough that the graphics could be drawn smoothly and the animation required might be fast enough. After a few more weeks of experimenting, I knew we had a winner— my software could be re-written to run anywhere Java would run (including Mac and Windows), and the performance would be excellent.

One of the sayings we programmers have is “Plan to throw one away. You will anyway.” So I embarked on writing version 2.0 of my software in pure Java, which became version 1.0 of Flying Logic. One of the great advantages of having to do something all over again is that you get to apply all the lessons learned you learned the first time around— and I had gotten plenty of excellent feedback on my Mac-only version.

From early in the project, I had come to understand that neither my client nor my client’s client (the defense contractor) were in the business of publishing shrink wrapped software— their speciality is integrating useful technology into larger systems for defense and other government customers. The results of my work would be broken into bits and used as they saw fit. But unless something was done, a stand-alone product would probably never see the light of day.

But I’ve never liked doing something cool and then just shelving it (especially something having such great potential), so I began a conversation with my clients about a deal to distribute the software as a finished commercial product. To my delight (and to make a long story short) they agreed and today I launched Flying Logic.

I am convinced of the critical importance of sound reasoning and its role in building solid paths to improvement in every facet of society. This opportunity has put me on a professional and personal mission to increase awareness of these essential subjects. If you are of like mind I hope you’ll check out my software and tell others about it— selling rational thought has never been an easy task!

Archimedes said, “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” I hope you’ll agree that Flying Logic is like a great lever with your mind at one end, and the world at the other.

— Robert McNally