The community centre that wants 'a program that sorts the timetable'
A community arts centre runs six rooms and takes bookings by phone, email and a paper diary. About 40 recurring weekly bookings and 25 one-off bookings arrive each week, handled by two part-time staff. Double bookings are only discovered on the day, when a tutor arrives to find the room occupied. The manager wants 'a program that sorts the timetable'. Staff already agree on the rules: a room cannot host two bookings at once, recurring bookings take priority over one-off bookings, and the kiln room needs 30 minutes of cleaning after any pottery session. Nobody has written these rules down, and the manager cannot say what the program's screen should show, only that it should be 'less messy'.
1. The manager asks for 'a program that sorts the timetable'. Explain how you would decompose this request into smaller problems, and state which single sub-problem you would solve first. Justify the order using the constraints in the setup.
Read the worked answer
Decomposition. 'Sorts the timetable' names an output, not a problem. The underlying problems are:
- Capture every booking in one place (phone, email, paper) so there is a single source of truth.
- Detect a conflict between two bookings in the same room.
- Apply the priority rule (recurring beats one-off).
- Apply the 30-minute cleaning buffer to the kiln room's availability.
- Present a timetable view.
Solve (1) first. Everything else is a query over data that does not yet exist in usable form. A conflict checker cannot run against emails split between two staff and a paper diary; whatever you build for step 2 will be tested on dirty data and its failures will be blamed on the checker.
Write the rules down before (3) and (4). They live only in staff heads, and 'recurring takes priority' is ambiguous: does an existing one-off get displaced, or is the new recurring booking refused? That decision changes the data model, so it must be settled before coding.
(5) is last because it is cosmetic: it can change next week without breaking anything behind it.
2. A volunteer proposes checking clashes by comparing each new booking only against the previous entry in the list. Give a concrete booking scenario drawn from the setup where this fails, and describe the correction as plain steps (an algorithm), not code.
Read the worked answer
Why it fails. Adjacent comparison assumes two things are true: the list is sorted, and a clash is always with the neighbouring entry. Neither is guaranteed.
Failing scenario. Monday, Kiln Room. Pottery is booked 09:00–13:00 and entered in January. In March a one-off workshop 09:30–10:30 is added, then a photo session 12:00–12:30. Sorted by start time the day reads: pottery, workshop, photo. Adjacent checks compare pottery-vs-workshop (fine) and workshop-vs-photo (fine) - yet pottery still runs until 13:00 and overlaps the photo session. The clash is with a non-adjacent entry. A booking appended to the end of an unsorted list is worse: its 'previous entry' may be a different room on a different day.
Correction (algorithm).
- For a new booking, select all existing bookings with the same room and same date.
- For each one, treat the later end time as
end + 30 minif that booking is pottery in the kiln room. - Declare a clash when
new_start < existing_end AND existing_start < new_end(strict inequalities, so back-to-back bookings are legal). - If no pair clashes, accept the booking.
With ~65 new bookings a week against a few hundred stored, all-pairs checking is a few tens of thousands of comparisons - fast enough that no clever optimisation is needed, and correctness beats speed here.
3. The manager wants the timetable displayed as a grid at the front desk. Identify what the program should deliberately hide, what it must not hide, and explain why that choice is an abstraction rather than an omission.
Read the worked answer
Hide: the channel a booking arrived by (phone/email/paper), internal booking IDs, staff free-text notes, and the booker's phone number in the front-desk grid. None of these help answer 'is this room free, and for whom', they add clutter, and phone numbers are personal data that should not sit on a screen visible to visitors.
Must not hide: the cleaning buffer. If the grid shows the kiln room as free from 13:00 when pottery ends at 13:00, the front desk will book it and the original double-booking returns in a new form. Any rule that changes availability has to be visible in the view that people make decisions from.
Why this is abstraction, not omission. The grid is a model of the diary that keeps only the attributes needed for one decision - room, date, start, end, title - and discards the rest on purpose. The test of a good abstraction is whether the decision made from it is correct: hiding the arrival channel is safe, hiding the buffer is not, because a user of the view would reach a different conclusion from the one the system knows to be true.