Home Forums Programming General Theoretical: Checking variable positions in a date-ordered queue RE: Theoretical: Checking variable positions in a date-ordered queue

  • I didn't review the code, because I think the problem may need some redefinition. There seem to be three considerations: (1) efficiency (where efficiency = book in the hands of a patron, rather than on a shelf or in transit), (2) fairness/good service to patrons (where fairness/good service = serving hold requests in the order received without anyone waiting too long for the book), and (3) manageability - minimizing the administrative burden on the library staff and systems (you didn't expressly mention this one, but it should be implicit, since a system that achieves the first two goals still fails if it is untenable in practice). Finding the balance can be challenging.

    IMHO, your proposal does not accomplish the fairness objective well enough. If I understand the logic correctly, a patron waiting to read one of 66 copies of a book could theoretically see 16 people who requested a hold AFTER him get a copy of the book BEFORE him. I think most library patrons would grumble if they came out on the short end of that stick, and I would not want to try to explain the system you laid out to an angry caller who found out that three or four friends who requested the book after he did have their copies while he's still waiting.

    I think I might achieve a better balance of the three considerations with something like a "hold clearinghouse" process. As part of the check-in process, titles with active holds are marked as "on hold - pending transfer" and set aside. At a set time each day, the system processes all holds. Each copy is matched to a hold request, with hold requests fulfilled in the order received and copies at a given branch assigned to hold requests at that branch when possible (in which case the library staff notify the appropriate patrons) and transit slips printed for copies that must be transferred to another branch to satisfy a hold request (in which case library staff route the book appropriately).

    This process would run somewhere around halfway to two-thirds of the way through the business day. Librarians could notify patrons with "same branch" hold requests well before closing time, possibly allowing them enough time to collect their copies that day. Books that must be transferred to serve hold requests could possibly be collected from the sending branch the same day (depending on pick-up and delivery schedules, of course), hastening their arrival at the recipient branch.

    On reflection, this doesn't sound much different than the system in place, as you described it. However, it does avoid the most asinine scenarios. For example, the library owns two copies of a book, and patron A requests a hold on it at branch 1 on Feb. 1 and patron B requests a hold at branch 2 on Feb. 2. One day, a copy is returned to branch 2 at 9 a.m. The system assigns it to patron A's hold at branch 1 and the librarians route it accordingly. At 10 a.m., a copy is returned to branch 1, and the system assigns it to the next active hold, patron B's, and the librarians route it accordingly. Later that day, one copy is shipped from branch 2 to branch 1 while the other copy is shipped from branch 1 to branch 2.

    Here is my assessment of my system with respect to the three considerations it must serve.

    Efficiency: 6 out of 10. The number of unnecessary transfers will be lower, but books are effectively out of circulation until the clearinghouse process runs; books may be transferred more frequently

    Fairness/good service: 8 out of 10. Hold requests are served in the order of receipt, but inefficiencies may still result in longer waits for everyone.

    Manageability: 8 out of 10. Library staff can process the hold list just once a day, but there must be storage space for the "on hold - pending transfer" shelf and each book must be handled twice (once when checked in and shelved on the "on hold - pending transfer" shelf and once when library staff processes the hold list.

    Thanks for the interesting problem!

    Jason Wolfkill