Anarchy is Good

by admin on October 3, 2007

This post is a synthesis and continuation of some ideas that have been covered in other posts on this blog: Why volatile investments sucks, the 85/95 rule of project management, and Gantt charts versus PR database. If you have read all of those posts, then what follows might make sense to you. If not, then I guess we'll see just how good a writer I am.

To dumb it down somewhat, I'll use one of my favourite literary devices: The parable. Here is the story of Ploddin' Paul the project manager who is faced with a very difficult management decision. He has a team of 5 developers, of which three are senior developers and are capable of handling mini-projects on their own. Their names are Genius Gary, Engineer Eric, and Liason Larry.

The project is a somewhat risky one, but not overly so. The goal is to build an archiving interface to several different models of tape drive so that customers logging into a database have the option of leaving their data on-line, saving it to a tape drive, or restoring the data from tape. Of course, there are number of other features and design requirements. The project is to be delivered in 6 months.

The team has three choices: 1) Write the code from scratch 2) Re-work some existing code that was produced in-house or 3) Work with a third-party API that promises to deliver much of the functionality (published by a vendor called Babooza).

"The APIs of Babooza suck big-time, let's do it the right. Write the code from the ground up in C#," says Genius Gary, who is the best programmer of the lot but has the attitude to go with it.

"The least risky way is to re-work our existing code base," Engineer Eric says. "We already know how difficult it is to work with the drivers for the tape devices. Yeah, there's hair in the old code base but that's the devil we know."

"In six weeks, Babooza says they will deliver an API that takes care of most of this." says Liason Larry. "Why do any of this if those guys will do it for us?"

"Trust Babooza? You're nuts. And our old code base sucks. Everybody knows that. Go new."
"I agreed with you about Babooza. But you want to leap off into deep water with no lifejacket. Go old."
"But what if Babooza delivers something functional? We'll could have our developers add more features and a really good GUI instead of goofing around trying get the tape drives to archive."

At this point in the conversation, just about when the developers are about to run to their desktop and settle the matter by playing a deathmatch in "Unreal Tournament," Ploddin' Paul speaks up:

"Larry, what do you think the odds are of Babooza delivering the API on time and it being usuable?"

"Ah, I dunno, maybe 50%"

Both Eric and Gary make noises and Paul marks that down to 25% in his head.

"Gary, if and another developer work on building what we need from scratch, do you think we can ship on time?" asks Paul.

"Naw, too much work, I would need at least another guy."

"What if I gave you a guy three months in? Maybe two."

"Okay, 80% chance of being done on-time."

Now it's Eric and Larry's turn to roll their eyes. So Paul marks down the odds to 40% in his head.


"C'mon Paul, give me the whole team and ninety percent sure it's going to be delivered."

"Hairier than the back of a gorilla," Gary says in a loud whisper to Larry. "Think spa-ghetti."

"Eric, if you're just re-working the code, how come you need headcount of five?"

"Come on, the more the merrier. There is going to be a lot of debugging."

"You get one guy for now, with maybe more in three months. So are you still 90% percent sure?"

"Ah, no promises," says Eric

Paul mentally marks the odds down to 50-50. He has had a look at the code. It's terrible.

Paul makes his decision. "Everybody go off and do their own thing. We'll come back in three months and review." Everybody nods their head and walks off. It was always like that, with Paul never making a decision on the final path to take until the very last possible moment. It drove some of the developers completely nuts sometimes, with the odd grumble that the group always seem to be on the verge of complete anarchy. But Paul DID let everybody try their own way most of the time, so people were most happy. It just seemed so inefficient...


So, on first read, it looks like Paul is violating one of the golden rules of project management which is always work hard to change your 85s to 95s (that is to say, always try to up your odd of success, no matter how incremental it may be). Paul is forsaking some paths which promise a 90% percent chance of success and letting developers pursue some high-risk approaches. Also, I have to say that this approach would look like crap if you threw it up on a Gantt chart: Instead of clean little bar showing five developers working together as a team towards a common objective, you've got three bars working in parallel towards the same goal. At some point in the chart, you've got to end two of those tasks, with all the waste of resources that implies (In Paul's case, the decision point is halfway into the project or three months).

To summarize: The developers do not think Paul is a decisive project manager, and definitely, if Paul's boss lived and died by the Gantt chart, he would wonder why Paul was wasting resources with all the redundacy.

But once again, the math works for Paul, because in software development, parallel paths with a reasonable chance of success are a better than one path with a high chance of success. Note that parallels path means you add the percentages together, not multiply like in a sequence:

One path: 90% of success.
Three paths: 25% + 40% + 50%= 115% of success!!

Of course the 115% doesn't mean that the project is absolutely sure to be completed successfully and on time. These percentages are gambler's percentages, meaning that sum is the addition of a series of bets for a given payoff. A metaphorical story might make things clearer.

Let's pretend we are in casino rather than in a software development environment. You have $500 in your pocket and the prize is...Oh, I dunno... an brand new Ipod (The best version, the one with 40 gigs. The one my wife won't let me buy 'cause I don't have a job, even though it would make me really, really happy if I could).

You can place all your money on one bet and have a ninety percent chance of winning. Or you can make a more complicated series of bets like Paul did: You put down $100 and have a 25% chance of winning. You also simultaneously put $200 down and have 50% chance of winning and put down another $200 to have a 40% chance of winning.

And here is where the fun comes in: With the first bet, there is one spin of the wheel and you know whether you are a winner or a loser. If the estimate of the development is correct, you are a winner nine times out of ten.

But with the three bet scenario, you have three spins of the wheel, and if one of the spins comes up a winner, you get half your money back from the other two bets. For example, if one of the $200 bets comes up a winner, you would get back $150 (50% of the $100 and $200). That is to say, if Gary's approach looks to be a winner after three months into the project, then you can abandon Larry and Eric's approach.

But what happens if none of the bets comes up a winner? Aha, well if that happens, the casino will allow you to double up your bet and spin again, taking half of the total sum of your bets ($250) and allowing you to spin again (With the chances of success not know until after the first 3 spins are completed). That is to say, if after three months, the API from Babooza totally sucks, and Gary's team can't even do a daily build without the compiler going into hysterics, then Paul can make the decision to throw everybody on Eric's project to rework the old code base.

In short the complex, almost chaotic allocation of resources in a software development environment allows for a better chance of a project being completed, and for a more efficient use of developer resources. I stumbled across this discovery mostly by accident, when I was grumbling about the inadequacy of gantt charts to accurately describe what really goes in a true development environment. For sure, I didn't expect to find a mathematical proof for the behavior that I saw in the PWS (software) division of Creo.

Anyways, for me this is a really cool discovery, because it validates the everybody-run-around-and-do-your-own-thing-and-let's-make-a-decision-later approach. Well, I mean the math validates the theory. Hmmm, I don't know if I would to try to "sell" this approach in a job interview or something like that.

Cheers, Dj

P.S. If, in software development literature, anybody has come across ideas similiar to the ones presented above, please drop me an e-mail so I can link to it. It's quite possible (maybe even probable) that this "Anarchy is Good" theory has already been discovered and I am just ignorant of it. Thx.

The content for this website is provided by www.bluebutterfly

Comments on this entry are closed.