Summary
Apparently Einstein went to his grave believing that "God does not play dice with the universe," that the Heisenberg uncertainty principle was wrong, and that there was just some other variable that we weren't taking into account that would explain everything.

This was called the "hidden variable theory." Numerous subsequent experiments have shown that there is no hidden variable and every event really does have a probabilistic component.

In the case of software development, there really are extra variables, but they are not hidden. We just ignore them. These variables, called "people," are unpredictable only if you are searching for a methodology that excludes them, which many people are. What is the intent of the methodologist? I think it is to create a formula that works regardless of the individuals involved. The great wish of managers is that programmers can be treated as interchangeable parts, because otherwise the company seems to be completely at the mercy of chance as to whether a project will be a success or not.

I think the problem with this, and with many issues in computing, is that of deterministic thinking. Which seems like a logical conclusion to draw; after all, we are in the realm of binary "yes" and "no." But there seems to be some kind of uncertainty principle at work -- as systems get larger and more complex, we move out of the realm of "yes" and "no" into the world of "maybe."

But the promise always seems to be there, just beyond our reach: there should be a magic formula that will allow us to deterministically control the outcome of a project. And as long as we are pursuing a deterministic solution, we are unable to consider the possibility that there is none, or at least that this is not the most productive path. And we certainly cannot admit that the road to success may be primarily in the realm of human interactions, and that successful projects will stack the odds in their favor by hiring the "best" team possible, where the meaning of "best" varies with far too many variables to control, and so can be quite different for different situations.

The hardest thing to admit, I think, is that software development is the complete opposite of an assembly line, but is far more of an artistic endeavor like writing a novel or performing a play. Or even painting. It's as if we completely skip over the important details of the activity, saying, "Painting means applying paint to a surface. So I can achieve the same effect with a spray gun on a barn as Monet did when he applied paint to a surface using his paint applicators." And after all, we are just manipulating bits, so it seems a logical conclusion to draw, other than it doesn't seem to work very well.

And as long as we cling to these thoughts of determinism, we are blinded to potentially better approaches. It remains very difficult to let go and say, "What if it's not possible to control everything? How can we push things in our favor anyway, and work within those constraints?"

Talk Back!

Have an opinion? Readers have already posted 68 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.