I built SeatSwiper. It watches restaurant reservations and books the table when one becomes available. For a long time I described it, and built it, as a cancellation watcher. Somebody gives up a table, we catch it, you eat. That is a real thing that happens and the product did it. What I missed is that a table becomes available two ways, and the second one is bigger. The first is a cancellation, which arrives at random and is mostly a latency problem. The second is a release: the restaurant opens a new window, usually at a fixed hour, often thirty days ahead, and several hundred seats appear at once. That is not a latency problem at all. It is a calendar problem. You do not need to be fast if you are not awake at the right minute, and almost nobody is, because the release hour is usually mid-morning on a weekday when everyone with a job is in a meeting. Those two need different code. The cancellation path wants a persistent watcher tolerant of nothing happening for days. The release path wants to know a schedule and be present at a moment. I had built the first and was quietly treating the second as a special case of it, which is why the results were mediocre in a way I could not explain for weeks. The tell, in hindsight, was that users described the problem the other way round from how I had modelled it. They rarely said someone cancelled and I missed it. They said it opened while I was at work. I heard that as the same complaint. It is not. The generalisable bit, if there is one: the noun in your product name is a model of the problem, and you will keep re-deriving that model without noticing. Mine said swipe, as in catch what someone lets go. Half the job turned out to be showing up on time.   submitted by   /u/carval [link]   [comments]