Developers-turned-dev managers often struggle to contain themselves when it comes to bug hunting. After all, they can usually resolve problems faster and better than the coders in their employ. The problem is, no developer wants a boss who takes more time explaining what must be done than it actually takes to do it. That leaves dev managers in the difficult spot of delegating the bug hunt and waiting for results.

As a newly hired development manager of a travel-bookings system, Dan E. found himself in this very situation. Overseeing a crew that was maintaining a fairly large ASP/VBScript codebase, Dan wanted to stay close to the technical details of the project while giving his coders room to do their jobs. So he simply offered some suggestions on what might be causing various error messages to appear.

Perhaps a "NULL Receipt Date" was behind that formatting error? Or maybe the user simply clicked twice when canceling his order? Despite the light touch, Dan soon learned that his coders didn't appreciate his efforts. No one was used to having a technical guy in charge, and many felt they were being micromanaged.

A few months into the job, and well after he stopped offering suggestions, Dan came across an odd bug-two bookings seemed to be mysteriously intertwined. Though they originated from different customers, the bookings shared the same flight plan and, consequently, the same ticket reservations. This wasn't good.

Dan had his suspicions on the cause but kept quiet. He assigned the bug and two days later the developer closed the case: "There's absolutely no way this could happen in our code. It had to be some bizarre data fluke."

A month or so later, the same problem happened again. There were two "mixed up" bookings, one that had almost completely overwritten the other. Again, Dan held back and assigned the bug to his developer. A few days later, he received the second resolution: "The chance of this happening was incredibly small; it's impossible to guarantee it won't happen again, but now the chance of it happening again is infinitesimally small."

Dan wasn't terribly satisfied with that answer, but let it slide. When the same problem happened again a short while later, Dan couldn't resist. He jumped in and attacked the problem himself.

The first thing Dan noticed was that the bookings were created at the exact same time. That shouldn't have made a difference, however, as the bookings were stored using a transaction-safe SQL Server IDENTITY: Every single booking had its own, unique identifier.

Parsing the code, Dan noticed this rather odd snippet: 

'Generate a random number so we can retrieve the 
'bookingId from the database after creating it 
rndNum = rnd*10
rndNum2 = rnd*10 'FIX: add a second random to prevent double-bookings

The block was followed by code that inserted a row in the database and assigned rndNum and rndNum2 to columns with the same name. Later on, when the bookingId was needed, the row was retrieved using the two "random" numbers.

To Dan, the problem was immediately apparent. Every experienced coder should know that Random functions-be it in C or C#-don't actually return random numbers. They're formulaic and simply return a series of predictable, "pseudorandom" numbers based on an input "seed." Generally, developers set the "seed" to the current time, which, in this case, presented an issue. As expected, VBScript's Rnd() function returned the same two "random" numbers from the same time-based seed.

Of course, the use of pseudorandom numbers was completely unnecessary in the first place, so Dan removed the code and replaced it with code that functioned properly. As soon as the booking row was inserted, it called SQL Server's built-in SCOPE_IDENTITY() function to retrieve the bookingId. Within a few minutes, the problem was solved once and for all.

At the team's weekly development meeting, Dan explained the fundamentals of "Randomness" and the importance of reading the documentation.

Identity Crisis was originally published in Alex's DevDisasters column in the September 15, 2007 issue of Redmond Developer News. RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!