I now have a Twitter account, so if you want to tune into my ongoing answer to the question “What are you doing now?” then feel free to follow my tweets. The sidebar of my blog now also includes my latest tweets. I plan to keep them to two to three per day, and I’ll see whether I can make them interesting. But no promises.
Whew! Today I’m finally ready to talk about the secret software project I have spent more than three years on: Flying Logic.
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
Haiku1 is a Java applet I wrote that simulates a multi-player version of a classic toy. I primarily wrote it to experiment with the Apache Mina project, which facilitates building robust and scalable network-enabled software.
Some users may need to click the applet before the keyboard controls become active.
Currently this applet is known to not work under Firefox 1.0.7 for Mac OS X, as that version of Firefox does not support applets written using Java 1.4.2.
Your comments are welcome.
The Pixelfest group artwork experiment asks: can a group of random people, each contributing a teensy weensy bit, make a coherent piece of art/design/garbage purely through the influence of the work itself? See how its coming along here.