Imagine you are a developer, working on a backend system with reservations. A new requirement comes up: if a reservation is not paid within 24 hours, it needs to be expired.
Your reservation table already has a field creationDate . So all you need to do, is to create a periodic job that looks at all active and unpaid reservations, that were created more than 24 hours ago, and set their status to expired .
Simple, right? You feel a bit queasy about using the creationDate field in this manner, but decide to go for it anyway.
A few weeks later, someone from customer support comes to you. “We have this reservation that has expired. But we really want to give the customer the option to pay, even though he was too late. Could you un-expire it?”
It seemed pretty important, so you change the creationDate value of this reservation. Yes, this will screw up the statistics, but who’ll notice that? Let’s hope this won’t happen too often.
Some time later, you receive a feature request. “Is it possible for all reservations made by premium users to have an expiry time of 48 hours instead of 24?”
Sure, no problem. You expand your expiry code. Instead of only looking in the reservation table, you JOIN the users table to check whether a user is a premium user. This does work, but it has a small bug in it: the user’s premium status should actually be checked when the reservation was created, not when it’s being expired.
So you ponder whether you should add a history log to the user’s premium status, but in the end you and the business decide to accept this small defect instead of spending time on fixing it.
The next feature request arrives. “Could we have a way to increase the expiry time for individual reservations via the reservation overview page?”
Hmm, tricky. You tell them that it’s possible but it will screw up the creation statistics. They accept it, and you program it.
And another one. “We are A/B testing our reservation site. Can we change the expiry time to 6 hours for reservations created on the B version of the website?”
This one has you puzzled. How can you do this? The reservation in the database is not aware of any A/B testing going on in the website, and neither is the expiry script.
So you consider adding metadata to the reservation to keep track how it was created. Based on that, the expiry script can calculate what the exact expiry time needs to be. So for a reservation by a premium user on the B version of the website, should that be 6 hours or 48 or maybe 1/4th of 48…
Suddenly, everything becomes clear.
… and suddenly you realise that it’s actually much smarter to store the expiration time in the reservation and also to add an “expiry time” argument to the API call that creates the reservation.
After all, whatever system creates the reservation in the backend knows exactly in which circumstances the reservation is being created, and thus can decide what the expiration time needs to be. Thinking about this a bit more, you realise that this solves all previous feature requests as well.
At least, you have learned a few valuable lessons from this experience.
- It’s really hard to predict the future.
- Trust your queasy feelings. They are there for a reason.
- Don’t put too much meaning in a single field. You will regret it later on.