Circular Logic in Project Management

Straight line or Circle?

Listening to one of my favorite public radio programs (The World) while carting the kids around this weekend I heard about an interesting study by the Max Planck Institute for Biological Cybernetics. A team of biocyberneticists wanted to find out how well people navigated. They hired a bunch of hikers, gave them each a GPS, and one simple instruction: Go straight that way.

Tracking the GPS devices from the comfort of the lab the researchers discovered that people don’t navigate so well on cloudy days or dark nights. Without an external frame of reference, like the sun or a mountaintop, people tend to walk in circles. Even people who claim to have a great sense of direction.

After reading more about the study I realized that people don’t tend to walk in circles. People only walk in circles. With out an external reference point the natural human programming is to only go so far, turn around, and go the other way.

And this makes perfect sense. Over millions of years, if an individual strayed out of his natural habitat without a good reason, that individual seldom got to reproduce. Our natural inclination is to stick to our territory, to the known, and within boundaries. Even when we think we are on a new path.

The mind is not exempted from this bit of hard coded behavior. I see it in others and myself all the time. In programming we call this recursion when we mean it and a bug when we don’t. In business it’s know as “once size fits all”, “if it plays in Peoria”, and “if it ain’t broke, don’t fix it.” Actually, I wish the business world had relegated circular thinking to tired old cliches. But insidiously it’s in your MBOs. It’s in you mission statement. It’s in your strat plan. Any goal that isn’t externally verifiable is a carrot on a stick.

The typical recursive program looks like this (pseudo code):

As long as there is data DoIt() will call itself. The data is the external reference point, the mountaintop. Remove the call to GetData(), or if it fails to return false, the function DoIt() will do it forever (or until the stack overflows—which ever comes first).

What is interesting to me is how strong the impulse to think in a circle really is. Many times we ignore the Sun or miss the mountaintop.
I have so many specific examples that I can hardly choose one but this is my favorite: The project is behind schedule so we need to:

  • Add more resources: The team is swamped so adding more should help!
  • Spend more money: More hardware, more consultants, more tools ought to help!
  • Work more hours: We just need find another 12 hours in a week to get back on track!
  • Motivate more: Obviously the team doesn’t understand how critical the project is to the company!

All of those solutions are examples of circular thinking because they seek to resolve the problem with more what the team is already doing.

When a project is late (and the calendar is the ultimate external reference point for any project) you have stop. Break the sprint. Reverse course. Look up for a guiding star that points to true north.

This is what works for me:

  • Shuffle the project’s management: Poor execution usually means one thing—Poor leadership. Good leaders take poor plans and make them successful (or change them until they are successful). Poor leaders complain about the plan, the team’s skills, and the design of the product.
  • Hold the budget: Throwing hardware, consultants, and tools at the project usually just makes it more complex. Sometimes running on a faster CPU will temporarily buy time for your pokey little puppy of an app server. But you’re just making some other project late down the road. You should only spend more budget if you inadequately budgeted beforehand.
  • Work 9-to-5: I know I’m going to get a lot of tech management mad at me but I’ve seen this go on for 20 years. Working 12-hour days just buys you bugs and burn out. You can do it for a short “sprint”, maybe at the end of the project. But you can’t sprint your way out of a hole. The secret here is to make sure the 8-hour days are not interrupted by meetings, fire drills, and shop talk. Engineers shouldn’t go to very many meetings, outside of the daily scrum. They get bored and ask silly questions.
  • Admit it’s not going anywhere: The current team is your greatest resource. They’ve been working on the problem, they know why the project is late, and they feel bad or mad or just resigned. Get their help and really listen to the suggestions. Honesty will get you for free what bonuses can’t buy. The team should be working for long term company success not a short term project bonus.

These techniques are counter-intuitive, and that alone probably means we are on the right track for breaking out of a recursive situation. As you can probably guess I’ve had more than a few projects go circular over the years. In the end there are no quick fixes. When you finally figure out that you are lost the realization doesn’t make the problem go away. It’s usually a long walk home—even when you are on a straight line.

Worst Ever Paragraph in a Technical Doc

I’m working on my Flash game framework. Progress, which I admit is slow, requires a good understanding of the Flash CS4 Component model. I embarked on this project a few weeks ago without realizing 3 things:

  1. The CS4 Component Model is very different from the CS3 model.
  2. There is very little good documentation for CS4 Components.
  3. Flash and CS4 Components have become the step children of Flex and it’s entirely different, incompatible component model.


I’m not sure why the CS3 Component Model had to go. The major change seems to be that CS3 Comps were based on a subclass of MovieClip while CS4 Comps are based on a subclass of Sprite. This change in inheritance has some great technical advantages but even more practical disadvantages.

MovieClip is a heavy weight object with lots of functionality. It’s a great starting point for components because you have all of Flash’s frame-based animation at your command. Sprite is a superclass of MovieClip and hard-coded to a single frame. Sprite is a great idea, since a many elements in a Flash game are static. Using Sprite-based components means less overhead for the Flash engine to grind through. Sprite-based components are less overhead for the programmer too: Since Flash plays any MovieClip by default you don’t need to include frame management code in a CS4 Component.

That’s all good. Here’s the bad:

CS4 Components can not share the same stage with CS3 Components. You have to choose one or the other!

There are 5 less Adobe-authored CS4 Components than CS3. Some of my favorites were not ported to CS4 including Accordion, Tree, and Window. I can still use the original CS3 set of components but not in the same application with CS4 components.


A quick search of FlashDen lists 236 CS3 components and only 51 CS4 components. This means to me Adobe has been doing a poor job of evangelizing the benefits of CS4 Components or that the benefits aren’t worth the effort. Or, as I suspect, all of the above.

CS4 components can be compiled so that their code is hidden. I hate that. I hope I don’t need to argue the open source model here. But someone at adobe should read the Wikipedia entry. I know developers who want to make money from their Flash components probably demanded this feature. I want to grab these follow capitalists by the shoulders, look them square in the eye, and say “There is a better way!” Look to the Perl community! Look to the Ruby community! Look to the PHP community! None of our brothers and sisters are starving there! Hiding your code leads to a lack of adoption, a lack of quality, and the illusion that you can sit on your butt and no longer have to innovate.

For me, the single biggest problem with the CS4 component model is the scarcity of quality documentation. The books and sites devoted to CS3 components are too numerous to mention. I found only one decent article on Adobe’s DevNet about CS4 Components: Creating ActionScript 3.0 components in Flash by Jeff Kamerer. It’s a very comprehensive article, points out many of the problematic design details that need to be considered when authoring CS4 components, but it’s rambling and needs much editing.

In fact it contains one of the worst paragraphs I’ve ever read in years of reading technical documentation:

You’ll find ActionScript metadata throughout all component code: in ActionScript 2.0 and ActionScript 3.0, in Flash and in Flex. ActionScript metadata comes between square brackets. It has a name that is followed by a list of name/value pairs enclosed in parentheses. For example, here is metadata with the name Inspectable and a single name/value pair, defaultValue/Label: [Inspectable(defaultValue="Label")]

Confusing yes?

What the author means to say (and I don’t blame him, I blame the nameless Adobe technical editor who should have fixed this) is that metadata is enclosed in square brackets and defined by a name and a string value or a list of key/value pairs. The example given is the most confusing part of this paragraph: It would be much clearer if a general example was used like [Name(key="value")]. By using a specific example he makes us hunt for the general hidden in the details. The example uses “defaultValue” as the key and confuses us with the word “value” on the left (the value is on the right). By using the string “Label” for the value the example confuses us with a synonym for a name on the right (the name, or key, goes on the left).

Unless I’m so confused I got it wrong.