Soft delete vs hard delete: a removed driver kept showing

If a driver you removed still shows on trips, or a driver’s slot shows nobody and nobody can say who was there before, the usual cause is a soft delete: the system blanked the record instead of removing it, leaving empty shells that every screen has to remember to skip. The choice between soft delete and hard delete matters less than keeping a separate history written at the moment of change. The first check is to remove a driver on a test booking and look at every screen.

Here is how that looked at one car rental business, and what fixing it took.

You take a driver off a booking in the rental office. The booking still shows a driver. Or it shows a driver’s slot with nobody named in it, and nobody can say who was there before.

In a car rental business’s system this happened on eighteen trips: bookings that appeared to have a driver when they did not. On seven others, the person who had been removed could no longer be identified at all. That matters the day a customer, a driver or an insurer asks who was supposed to have that car.

What was actually going on

Removing a driver used to blank the driver’s name on the assignment record and leave the record in place. The reasoning sounds responsible: never destroy data, keep the record in case you want it later.

What it produced was an empty shell. A record that still belongs to a trip and names nobody. Nine places in the system read assignments without being told to ignore those shells, and each one was a separate chance to show a driver who was not there. And the shell destroyed the very thing it was meant to keep. Blanking the name in place is exactly how seven records lost the identity of the person who had been removed.

The owner’s own description of how it should work was simpler than what had been built: one record per leg of a trip, holding the current driver, with every change written to a log. Removal deletes the record, and the log entry is the history. He was right. A record kept “just in case” is a second, weaker copy of the truth sitting in the same table as the first, and every screen has to remember to ignore it. A log has no such problem, because nothing reads it by accident.

What we changed

Removing a driver now deletes the assignment and writes the change to the audit log. A leg with no driver on it means exactly that and nothing else.

I had started building the opposite: a fallback that would show past drivers on every office screen with a “historical” marker. The owner’s clarification made that the wrong design, so it was reverted the same afternoon rather than shipped.

Deleting a record that has other records hanging off it is risky, so it was tested by driving the real office screen against the real system. The first run failed: deleting an assignment that has handover photos returned an error. That was the database refusing to let the change go through. Had it been set to delete the photos along with the assignment, the removal would have succeeded and destroyed every photograph the driver took at handover, and the record of who took them. Removal is now refused outright when photos exist. The reason is a business one: photos mean the driver already did the job, and changing who did a job that is finished is a reassignment, not a removal. Reassignment still works.

One more safeguard: the driver’s phone sends a bare status update when a handover finishes. The system distinguishes “no driver mentioned” from “driver explicitly set to nothing”, so completing a handover can never delete the assignment of the driver who just completed it.

What it did not fix

Two other faults turned up during the work and were written down rather than fixed.

Two fields on the assignment record have the same name but point at different vehicle numbers. On one test booking they read 43 and 92. A careless comparison suggested all 5,193 assignments disagreed with their booking’s vehicle; the real figure was 103.

And a delete function the office screen never calls looks a record up with no check of which leg it belongs to, so it could delete the pick-up when the caller meant the drop-off. It was left alone, because changing it would alter something other systems rely on, and flagged instead.

How to check your own system

1. Ask how your system shows “removed”. If the answer is “the record stays but blank”, every report and screen must remember to skip it, and some will not.
2. Remove a driver on a test booking and open every screen and document that shows a driver.
3. Ask where the history lives. A separate log written at the moment of change keeps the current picture clean and the past intact.
4. Ask whether removal is refused where it would destroy other records, such as the photos a driver took at handover.
5. Ask whether testing does what a user does. A check that sets things up behind the scenes and only looks at the result can pass while the screen people use is broken.

Where this ends up

Driver assignments in Sazinga Rentals are removed outright and the removal is logged, which is what makes a leg with no driver on it mean exactly that and nothing else.