Willy Wonka Conflict Resolution

At the end of the classic children's book,

Charlie and the Chocolate Factory ISBN 0141301155

Willy Wonka takes Charlie for an elevator ride in his amazing network of omni-directional elevator shafts. Charlie gulps when Willy tells him there is only one problem - there are two elevator cabs traversing the same network. Charlie asks what will happen if they collide? Willy answers "hasn't happened yet."

As a younger programmer I used this story to ridicule an attitude about programming I didn't appreciate, but over the years I've come to realize that equating software to life-transporting-and-preserving-vehicles (as NASA is wont to do) can often be a barrier to progress. Sometimes, you have to relax and not worry about an unintended collision between parallel development efforts if you want things to flow. I've found it easier (and more enjoyable) to resolve conflicts once they arise (once the elevators crash) than to live with systems that rule out parallel efforts. -- ScottJohnston

Boy, I'm glad somebody said that. Some folks use the term "mission-critical" as if life on this planet would cease to exist if the system went down. Most systems just aren't a matter of life or death. -- DavidBrantley

When Is The Mission Really Critical?

I really appreciate this viewpoint - I interpret it as not worrying about possible future problems which are mathematically unlikely. If we discover there is a problem in the future, fine; we can deal with it. But until then, we have plenty of other work to do. YouAintGonnaNeedIt. -- BrentNewhall

Yeah, well, a guy I worked with on my last medical device gig thought that same way. Unfortunately, there are conditions where a software product is life and death - literally. You need to think out potential problems up front before they byte you where it hurts the most. I was being accused of spending too much time thinking about solutions to non-existent problems; this despite the fact that I had thought out the natural logical conclusion to where the product's usage and performance where heading. Even though we didn't have an immediate need for a certain aspect of architecture right now, we still needed room for the hook. This was because just one tiny change in the requirements (for a feature which the marketing people had already expressed an interest in) would introduce an entire realm of possible errors sneaking into the system. I wasn't going to wait for the elevator cars to collide. -- MartySchrader

I agree, there are situations where it is extremely important to remove as many bugs as possible from software before it is fielded. But this has to be the burden of testing as much (if not more) than design and development. Once again, I really didn't think this way when I was younger. I had a belief in building bulletproof systems from the bottom-up, where testing would simply show the lack of problems. I had an inadequate appreciation for the real-world complexity of any real-world project. -- ScottJohnston

Life and death products aren't a place where I want to do field testing to find the bugs. In fact, I don't want to find any bugs at all after the product has been released. If I can't design the thing right in the first place and allow for plenty of FaultTolerance, then I shouldn't be making Class II and Class III medical devices. Period. And yes, I have beaucoup appreciation for the real world complexity of real world solutions. However, when working on any medical device the first thing I ask myself is, "would I let my mother be hooked up to this thing?" That last PCA (patient-controlled analgesic) syringe pump project -- now a released product, if you can believe it -- failed that test; it is the first medical device I have ever worked on in nearly 30 years that I wouldn't want used on me or mine. -- MartySchrader

I've found in design we can say these things won't happen in the real world but the testing team tests for them anyway so we end up having to worry about it.

WillyWonkaConflictResolution and Wiki

On the other hand, in the EditConflictResolution discussion where this is mentioned, we keep finding scattered pieces of smashed elevator cabs all over the floor. Maybe we should do something to stop the bad things that are happening. Sometimes people find that others have "SteppedOnMyEdit," and don't like it. -- JeffGrigg

No, I don't think so. I've had plenty content clobbered, and that was always a good thing, stopped me from shooting my damn fool mouth off. If you're posting to some topic where there's already too many people posting, take a day or two and wait until it cools off. WillyWonka? encourages that. Probably part of WhyWikiWorks.

The real mystery is what Ward does with all that inconvenient information he logs. -- PeterMerel

When conflict detection was new, my log reported one or two conflicts per week. Now I observe ten to twenty. This increase may be due to increased popularity of wiki in general or unusual focus on a few pages due to, say, writing habits or new change reporting scripts. -- WardCunningham

If you're short on error messages, I'm sure Ward can spare a few. ;->

I can relate to the usefulness of periodically losing your contribution, if you're lucky enough to have this happen at the right time. But with a reasonable strategy for merging changes, the number of actual collisions is greatly reduced. Why have collisions just because you've edited the same file at the same time as someone else? As long as you didn't edit the same lines of the same file you probably don't have a problem (because Larry Wall's "patch" could be used to set things right - or any other diff merging stratagem). -- ScottJohnston

This reminds me of an interesting fact about random walks. In one or two dimensions, a random walk on the lattice points is guaranteed to eventually return to the starting point of the walk. In three dimensions, however, the probability of returning to the starting point is only about one-third. (For more details, search for "random walk" at http://mathworld.wolfram.com/.) I have a feeling that this question is quite similar to the question of whether two random walkers will ever end up at the same point. So I guess Willy is right not to be too worried!

See: IsYourCodeThatImportant, BugFreeSoftware