Software Development and the Red Bead Experiment

"Just once it might be instructive to pretend you're accepting an award for failure, just to see who you would thank." ~Robert Brault

There seem to be endless quotes related to failure. Many of them are a variation on "The only real failure is failing to try again." Heart-warming stuff. Encouraging. And dead wrong.

Success deceives. It tells us what happened, but not why it happened. And left to come up with an answer to why, we often choose the most flattering narrative. The road from self-congratulation to self-delusion is short -- and well-traveled. Failure tell us "You have fundamentally misunderstood something of importance." This keen insight is most often accompanied by a high bill.

I have a fair amount of experience consulting with companies who want help with their development process. Put another way, these are companies who have, to some extent, experienced failure in developing software and who, like all sufferers, just want to make the pain stop.

It seems almost too cruel that before we can make the pain stop, we must often cause more pain -- digging deeply to discover the real source of the suffering.

The candidates for the role of this is our problem! usually come in two shapes: people and things.

Things I've Heard Of the "People are the Problem" Variety...

"The Boss is such a micromanager, it's no wonder nothing works right."

"I have to spend half my time protecting myself from Joan who will throw me under the bus if anything goes wrong."

"I ask for a reasonable deadline and everyone scrambles for the latest date possible."

"Deadlines? It doesn't matter what our input is. The Boss is going to set one. And we're going to fail. Again. And Again."

Things I've Heard Of the "Things are the Problem" Variety...

"Our version control system blows big time. If we had git, things would be a lot better."

"We have to support IE6. 'Nuff said."

"Our internet connection is so slow it's almost worthless."

"If every developer had two monitors, things would be a lot better. But management is too cheap to invest."

Now, I'm sympathetic to pretty much all of these complaints. They're all real. But none of them is at the core of what causes an organization to become dysfunctional. That is, while all of them have merit, the problems did not cause the dysfunction. Rather, the dysfunction caused or exacerbated these issues.

So, if it's not (or, at least, seldom) the case that people and things are the core problem, what is?

To understand, let's take a look at a game invented by Edwards Deming in 1982 called the "Red Bead Game". Dr. Deming created a paddle resembling a Chinese Checkers board. The paddle could hold 50 marbles.

Dr. Deming then asked four volunteers at his talks to come on stage. He then explained the rules of the game.

"We have a vat of white marbles with some red marbles mixed in. Your goal is to dunk the paddle into the vat and come out with white marbles only. The fewer red marbles you get, the better. Ready?"

Ann is up first. She dunks the paddle, pulls it out and, let's see: 1...2...3: 3 red beads. Dr. Deming looks pleased.

Now, it's Bob's turn: Bob dunks the paddle: 1...2...3...4...5...6...7...8: 8 red beads. Dr. Deming frowns as he enters notes into Bob's personnel file.

Next up is Carla. Her total of red beads is 6. Dr. Deming doesn't look too pleased, but Carla figures she's safe since Bob made such a bad showing.

Finally is Dave. Dave confidently plunges the paddle in and comes up with...2 red beads! Amazing. Dr. Deming is very happy. Ann feels sick: she was so close.

Well, things are looking up for Dave. He'll be given an appropriate reward: "Employee of the Month", perhaps. A nicer parking spot. A gift certificate to a local restaurant. Yes, we need more "Daves" in the world. Perhaps we can hire friends of Dave on the theory that winners tend to associate with winners. Bob, though -- I'm afraid he'll have to go. We just can't have such low standards. And we better give Carla a written warning to reinforce our desire for all-white beads.

By this point, the audience is laughing -- and groaning. It's absurd, of course: none of the volunteers had any effect on what came out on the paddle -- it was the sheer luck of the draw. And yet, individuals were getting the praise -- or blame.

Dr. Deming, renowned for sparking the quality revolution that transformed Japan from a producer of cheap goods to a brand of quality, pointed out what should have been obvious: products are produced by systems.

A system is the integrated working of people, processes, products -- geared towards producing something. Systems produce what they were designed for. In the case of Dr. Deming's red and white beads game, he left out one crucial detail: the distribution of the beads. 94% were white; 6% were red. Given this, it's simple math to determine what "product" the system would produce. And all the coercing, threatening, cajoling, "incentivizing" in all possible worlds won't have any effect on the product.

That's almost always the case with software development shops -- i.e. software development systems. Systems produce the quality of software they were designed to. The problem is we're often unaware that we're part of any system design. A system is the combination of decisions made -- decisions about the environment developers work in, the way requirements are uncovered, the process by which software is developed, the testing procedures in place -- and a myriad of other decisions.

Managers are incredibly important. They have a huge impact -- both on the lives of developers and the quality of software they produce. Too often, managers misunderstand their role: they think they're job is to manage developers when actually, the job they need to do is to manage the system.