Don't Worry; Be Happy

An IrRational Tools Report

After our nation's year-long ordeal in 2004, the word "vote" should have left us pessimistic. But we are, after all, Americans. Even the most cynical of us are engineered to automatically increase our level of optimism when confronted with challenges.

We were optimistic because, let's face it, we are ClearQuest experts, right?

Here's what we were optimistic about. In the middle of the lifecycle of a change request, it is shackled and brought before a star chamber for judgment. We often call this panel a Configuration Control Board (CCB). In a recent customer's organization, CCB deliberation is not merely pass/fail. Instead, each member of the CCB is given a pool of points which they assign to the change requests appearing before the board. The voting members distribute the points according to their ranking of each item's importance. At the end, the points are tallied and high-scoring change requests move on to be assigned to release/implementation.

The existing ballot-based system (using paper and pen) left participants pessimistic about the value and ease of deliberation. Ballots were difficult to track; scores were erased or scratched out leading to misunderstandings; voters had difficulty remembering how many points they had remaining.

We were optimistic that ClearQuest could be configured to enable the voting process electronically. We created a stateless record to represent the meeting of the CCB. The CCB record was designed to hold voter assignment and each voter's available points. It also identified (via a back-referenced REFERENCE_LIST) the change requests associated with the meeting. Even better, using ClearQuest Web, voters could vote from the comfort of their hotel rooms.

So, we cooked up hooks to calculate total scores and subtract allocated points from the voter's available pool. Our initial testing worked like a dream. Charts showing point spreads and change request rankings were easy to concoct. Our optimism soared.

Then we tested the schema with two users. We immediately started seeing this error message:

ERROR! Cannot apply the requested changes to the Defect "TALE00000067". The record probably has been updated or deleted by another user while you were working on it.
(Details: ID = TALE00000067, rows = 0, old version = 33, object version = 34, new version = 34)
Can you guess what our problem was? It seems that ClearQuest is optimistic, too. ClearQuest's optimistic locking design allows us to set up a race condition. This is the use case:

  1. User A opens a ClearQuest record for modification.
  2. User B opens the same ClearQuest record for modification.
  3. User A changes a field or two and saves the record.
  4. User B changes data and attempts to save.
  5. ClearQuest doesn't know how to merge the changes and so prevents User B from saving to keep from wiping out User A's changes.
It would be nice if ClearQuest were more pessimistic. I suspect (and I can only suspect) that it is not more pessimistic because ClearQuest is not truly client-server. It is client-database. Imagine this scenario:

  1. User A opens a ClearQuest record for modification using ClearQuest Web.
  2. ClearQuest locks the record so nobody else can use it.
  3. User B attempts to open the record and is rebuffed.
  4. User A's browser closes without logging out.
    • There is nothing to tell ClearQuest to unlock!
  5. Six weeks later, User B still can't modify the record. It's stuck.
For defects and enhancement requests, this race condition will rarely appear because of dispersed timing and process limits on who is responsible for changes to a record at any given time. But a system that has multiple users responsible for entering data to the same record in a small time-box (like, say, an election) is bound to run into this issue.

Is there something we could do to make this work? I'll go on about that more at some other point. For now, let's just say that I have reason to be optimistic.

0 thoughtful messages from friendly readers: