I'll chime in with a lesson learned from my own experience in niche POS systems: it can be amazingly valuable (in certain contexts) to let clerks pause sales and put them off to one side (think "git stash", but for sales). Customers wander in and out, run back for one more thing, or put things on hold while they go out to get cash out of an ATM. Letting a clerk wrap up a whole sale with context (some items rung up, payments created but not processed, etc.) and put it on a shelf to restore later is a superpower for POS systems.
And that's not even _starting_ on the nonsense and bizarre home-rolled systems that small businesses concoct around layaways.
I used to work in a supermarket without this feature and when a customer would run away mid-order, my options were either stand there awkwardly while another potentially irate customer stares at me or call over a manager to get the override key to let me cancel the order (any voids/cancels over a certain dollar amount required a manager override key). Neither option was good. Both wasted time and created a bad experience for the customers. I occasionally see cashiers these days doing these `git stash` maneuvers and honestly I get jealous every time.
The store I managed had a suspend/recall. Cart full of groceries only to realize you left your wallet (at home, in the car, whatever) suspend the transaction and print a slip with a barcode on it. Move the cart out of the way and take the next customer. The customer comes back and scans the slip at any register to recall the transaction, pay and collect their cart and leave without having to hold up lines/etc... Was a nice convenience many appreciated.
It was an option in the register when I was a cashier during the crash of '08 and I couldn't find a gig elsewhere.
But it was against policy to use the feature, since previous cashiers had worked out a way to scam the system somehow and pocket some of the cash being exchanged. I'm cloudy on the exact details after so long, but it was very, very annoying to have such a useful feature sitting there mocking me and a write up if I dared hit the button.
In the store I worked in, which was a notable spot for people attempting credit card/gift card fraud and/or theft, the manager literally just gave me the override code because it happened so often I'd have him coming over like every 15 minutes to cancel something. We were also a super busy store at the same time as this so it would just leave a bunch of hyper-angry customers in line.
The psychology of this is funny. The right thing with such a POS is to have customer pay for everything so far, move their cart to the side, let them run and get their item, and then let them be front of line at that point to finish their full set of purchases.
Honestly, to add on to what you said, it's amazing about the lack of domain knowledge that developers and product owners have in making systems for people.
For the clerks and workers using the POS, it's often more of a hinderence than it is a help. When you look at less technically reliant societies (i.e. market places in Asia) you'll see this more often. Prices are negotiated, they can be their own warehouse, smaller companies work together (your package getting from maker, middleman, aliexpress to your door is incredibly complex but they can make it happen within 2-3 weeks).
To be fair, though, the "customers" aren't the customers. In modern software companies, you don't sell products to be profitable, you sell them to be plausible. As a software company, your value to a venture investor is much greater than it could possibly be to a potential customer. The objective of the startup is to look plausible until the current round of investors sells their stake to the next round of investors. Part of they way those investors value the company is whether or not they think they can sell the company to a greater set of fools.
In the modern software company there is only one customer, the next early stage investor. I can assure you, your execs know how to pitch to them, otherwise they wouldn't have received their A round.
It's always much faster to check out with a couple of things in a New York bodega/deli, even while making small talk with the clerk, than to check out with the same items at the chain drugstore down the street.
I maintained a POS for a large retail chain - and the variety of transactions that it could handle was far narrower and less subtle than the type of trades that I witnessed working at a weekend open air market.
At the market there was all sorts of bartering and swapping and deal making - my “business analyst” brain recognised that to model all the “transactions” occurring at a typical market would be super complex.
However… the large retail chain should not support subtle/overlapping transactions of that sort- not because it’s too complex to model, even if it was free to model it, make the software track it — the reason the retail chain would avoid it is: profit margin.
You do profitable things, you do them a lot, and you don’t pay the opportunity cost of doing less profitable things. That’s the open secret of successful retail. And small businesses everywhere do not internalise this.
Isn’t the reason rather that management will say: Is this absolutely necessary and will it increase sales?
And often the answer is no unless you can demonstrate the time gain and emotion of your customer. When the margins are super thight anything that won’t help margings is left away and home delivery /online shopping will be prioritised for the tech team/budget.
I always like to say something meaningful before plugging my project, but that's exactly why I started working on https://notionsmith.ai
Overall I'm really excited about LLMs being integrated deeper into product development, there are a lot of insights already captured in their output that people building products could use
I was really impressed when the cashier at my neighborhood supermarket recently transferred my order in progress over to an empty lane so that I could deal with a credit card issue without delaying the people behind me. Seems like an obvious function but it had never even occurred to me!
I maintained a POS for a retail chain for a few years.
Our suspend/resume sale feature assumed that a suspended sale could only be resumed on the machine that suspended it. Then we had to change it to be resumable on any machine in the store. But only show a flashing notification that there’s a suspended sale, on the original machine.
(Thanks for storing that knowledge for me for the last decade, neurons. I doubt you’ll be asked to recall it again.)
>And that's not even _starting_ on the nonsense and bizarre home-rolled systems that small businesses concoct around layaways.
There are a number of things that even many just modestly-paid developers don't grok because they obviously make no sense.
Many years ago I remember asking a then-gf why such and such a store customer service accepted utility payments. And she was "Umm. Some people don't have checking accounts." Layaways are different but in the same general category.
That's a bit like opening a tab in a bar, isn't it?
I think it depends a lot in the country or the business, in some places is so easy, but in others is so difficult.
I remember at least 20 years ago, in the grocery store with the most basic digital scales, every clerk would have their "tab", shared between all the scales. So each one could use the scale nearest to the fruit they were weighing in that moment, then switch to a different one... And finally print the whole ticket without interfering with the other clerks.
We called that feature "parking" the invoice. It's pretty standard on every good POS system.
It can also become a challenge if you have a lot of those and want to find the right one. We had some users that prepared a lot of orders in advance into bags, so they can hand them to the customers right away when they come. Best solution was to print a delivery note for every order, attach them to the bag and then scan a barcode on the bag when the customer comes for pick up/payment. And you also need to be able to add or remove items before the customer pays, people often change their mind.
I developed POS software, and it is an extremely challenging job. The workflow described in this article is still rather simple, there are so many more possibilities (some apply more to shops than restaurants).
One hypothetical example: a tiramisu with coffee has a special price, but you still need to put them separately on the invoice, either because you track if the tiramisus are out of stock and want to stop people ordering more. Or coffee and tiramisu may have different sales taxes (very common in Europe to have a lower tax for food).
Different prices for take away and eating in the restaurant, happy hours. Payment in different currencies, some articles may have fixed prices in a foreign currency, others need conversion with the current exchange rate.
The possibility to split or join invoices.
Usability and speed is crucial at the POS, the users go crazy if they are busy and their software is too slow or has too many submenus. It has to be easy to learn too, often they hire people that fill in for a few days, and they need to be able to use it. A lot of people using it are also not very skilled with computers, or have no interest in learning how to use the software.
The owner may restrict some features to some users, so they can't cheat the system (taking cash payments, cancelling the invoice and keeping the money). There may be some tax fraud prevention laws to be implemented, vastly varying on the region, like digitally signed invoices or the need to report every issued invoice to the authorities in real time.
Those kind of tax and price variations are quite common in the U.S. too.
Some examples: Bread from bakery plus lunchmeat from deli = taxed at grocery rate, but a shrinkwrapped sandwich using the same bread and lunchmeat = taxed at the higher 'prepared meal' rate (because that's a luxury).
One candy bar is taxed at the grocery rate, because it includes wheat in the ingredients, while another is taxed at the junk food rate because it doesn't. They're both mostly chocolate and nougat, but one has some wheat, so it's legally considered a cereal.
And of course all of that varies from town to town and state to state, and sometimes even in different neighborhoods within the same town. And of course, some towns cross those political boundaries. I used to live just down the street from a shopping center where the tax rates were different depending on which store you were in (east side of the mall vs west side of the mall).
That's all before you get to sales and specials and membership discounts and such. Oh, and tax-exempt shoppers (because they work for a charity or something).
People always make fun of the U.S. for not just putting the total final price (tax included) on the shelf but the reality is, we can't because quite often we just can't know what it will be until you checkout.
For something that seems so simple and everyday, it really is bafflingly complex.
My extended family recently opened a pizza place which just happened to be at the same time as me wanting to take a break from startup grind. I worked at a pizza place in high school, and have continued to make pizza at home, and loved the idea of being able to combine that knowledge with the experience of building software startups, so I have been heavily involved in the last 6 weeks on everything from ordering, to kitchen layout, to POS and other IT systems, to marketing.
In short, the experience has been super interesting, not only in terms getting to learn tons of new things and get familiar with how the tech side is done (spoiler alert, not that well) but also just generally how much of an opportunity there is to take the sort of thinking and skills required to build tech products and to apply them to a quick-serve restaurant (and I would guess lots of other small business).
I have been planning on writing something up, but this article is giving me good motivation to actually do it :)
I wouldn't be surprised if the author visited your newly opened place and was inspired to write the article based off their experiences! It's a small world, after all.
You should talk to some of your local newspapers/culture magazines about your experience as well, they love these types of stories and you can get free exposure for it.
> That means you shouldn’t have something like a reference to a product’s foreign key to dynamically grab the price when you render the receipt.
This is vastly underrated principle that is rarely understood and should be much broadly applicable. My data is separate from other people's data. In Carta, I have had my startup investments leave the system (die, acquired, etc) and I am left taking screenshots of everything because my records are just foreign keys into some other data store. If they had mailed me PDFs even paper or something, I would be fine.
I feel like this is one of those cases where people take a mantra too seriously.
Storing values that could otherwise be derived results in complexity and discrepancy.
This may lead people to the conclusion that all values which can be derived should be derived, but in the case of a receipt/invoice, this is not the right call. Discretion must be applied.
I think the biggest deciding factor in this particular situation is what the article says in the sub heading. 'A “Receipt” is immutable'. You don't care about the consistency guarantees of normalization. You don't care about being able to re-derive it with new logic or additional features. And in all likelihood the storage savings from not storing the final generated output is going to be miniscule.
If some data is meant to be truly immutable, and storing it separately won't impact your storage costs, store it separately. Because otherwise that immutability needs to be somewhere else in the system.
If you normalize your data and dynamically derive receipts, your logic needs to include all receipt logic you have ever used, cordoned by timerange. Was the price of a large Pizza changed in 2018? Your receipt logic and data has to reflect that forever. Did you allow stacking coupons but in March 2017 you started limiting it to 1 coupon per customer? Your receipt logic and data has to reflect that forever. Did you have a week where prices were rounding in the wrong direction when a certain coupon code was used? That has to be in your receipt handling forever.
There's just so much additional effort, so much potential to go wrong, and so little to gain.
your comment doesn't provide when to decide one way or the other, which makes it more warning and less useful.
when the data is stuff that could be paperwork - you get a copy, i get a copy - it should not be the case that one side gets to unilaterally decide if the data is deleted or modified.
The general way I'd do this is to have the foreign key, but not to a "current prices" table, rather to an "all prices" table containing present and past prices. Which goes back to immutability. Maybe over-engineered for a small pizza shop that could get by fine with $ values copy-pasted everywhere, but we're talking about general principles.
It's not like the customers' data is meant to be separate, like they're all paying the same price that we decided for the day, other than promotions which would be a separate table or misc adjustments that would just be a col directly on the sales table.
There are a lot of things that can change, not only the price. The name of the product can change. What was "Medium crispy crusted pepperoni pizza" yesterday, may be called "Extra large pepperoni pizza" today. If you re-print the invoice, it should look the same as on the first print. Otherwise you may get some issues with the authorities (manipulating your copy of the invoices).
There may also be a lot of related tables for finding the price (in the system I worked it was about 10 joins to get from the article to the price). It can be done in an immutable way, but it is possible that the way of calculating prices may change after an update. There may even have been a bug in the first place (like incorrect rounding, issuing rebates that shouldn't have been issued, incomplete sync of the prices table from the main server to the cash register, ...). Once you fix it all the previously issued invoices would show a different price. Which means you "lost" your copy of the invoice. Authorities don't like that. Credit card companies don't like it, if the customer disputes the charge and you show them an invoice with a different amount. Your bookkeeper doesn't like it, if a lot of payments don't match the invoices exactly, ...
Edit: Example for rounding: Two people split a pizza for 19,99$. Version 1.0 creates two invoices with 10,00$ each. Version 2.0 creates one invoice with 9,99$ and a second one with 10,00$. Then the authorities pass a law that rounding prices must always floor them. So Version 3.0 creates two invoices for 9,99$.
I made an online store where I just stored the price in the order itself, as an immutable snapshot of the price at the time of purchase. I also included the product title and SKU, just in case someone decided to reuse an old product instead of creating a new one (it happened several times)
Alternatively you could go "all in" and create some form of versioning system, where you store the version number of the product
> You would still want that free pie to be put through the workflow and tracked. The only difference is you wouldn’t collect a payment.
In some jurisdictions you don't just want to put the pie through the POS system, you have to for both tax reasons and to make sure your employees don't ring up their friends on "faked" coupons.
The rest of the article is really nice as well and reflects with my personal experiences in bartending... indeed having experience in hospitality jobs is a major plus for anyone working in IT or design, simply because you learn to value first hand how important performance and good UX is at some of the highest-stress jobs there are.
Lots of retail businesses have a sign that reads "If you don't receive a receipt, your purchase is free!" It enlists the customer as an auditor to make sure the employee uses the POS system, rather than pocketing the customer's payment. If the cash in the till doesn't match receipts at the end of the day, the proprietor knows something's wrong.
(Just in case you're one of today's lucky 10,000.)
As a teenager I worked at a popular coffee chain. Once I started working the cash register autonomously I got very lightly reprimanded by co-workers for charging a customer (I forgot his name, this was a long time ago). They were like “oh you charged Tim? We don’t charge Tim!”. There were a couple regulars who we didn’t charge. I’m not sure if they were people on hard times or friends with the franchise owner.
It’s something I wouldn’t have expected to happen regularly before I worked there and I surmise it happens everywhere.
But you don't receive a receipt until after you pay, so you'd already given them the money before you realize if you're getting a receipt or not. That means you have to then escalate the issue, cause a scene, take up your time, deal with the whole your word vs theirs, etc.
When they first started calling these systems "POS", I thought that it was an unfortunate coincidence that they used the common acronym for "piece of shit". But later, I began to wonder if it wasn't intentional, a kind of inside joke.
Regan faced the engineers and fought to keep the annoyance from reaching his face. "What did you call it?"
"POS." Brenda's bubbly demeanor was reflected in a little dance that she did while saying each letter in an almost singsong pattern.
"You ..." Regan stops fighting his instincts, takes off his glasses, bows his head, and pinches his nose. "All of you understand that we can't call it that."
The rest of the engineers stood silently and without movement. They have to have planned it this way. He should have known something was up from the moment he walked in here.
"Why's that?" Brenda tilts her head to the side.
"Because it stands for piece of ..."
"Point of sale." Brenda blurts out before Regan can finish.
Regan slowly puts his glasses back on. "Is the POS going to be completed by the deadline?" He forces the words out through a clenched jaw.
Brenda remains still with wide eyes and a frozen smile on her face. The rest of the room nods that the deadline will be met.
"Then fine." Regan leaves; they can make the deadline then they can have their stupid little name.
Some people on the IT side where I work who deal with these things on a daily basis do that. Even I sometimes see POS as "piece of shit" now, even though whatever documentation I'm reading is obviously referring to 'Point of Sale'
Began my coding career because of the family hotel business. Started coding websites, progressed onto building status boards (vertically mounted tvs) for the today’s Programm, dabbled in document management (instapdf.com), employee management (baseping.com) and worked my way up to actually implementing 3 different versions of iOS apps interfacing with different POS systems (ordervisto.com). Getting live feedback from these systems was invaluable and really helped with finding out what works and what doesn’t instantly.
The hotel is sold now and I’m wondering if I’ll ever work in such a challenging and multifaceted environment again.
Has Undercover Boss taught nothing. Things are never how you think they’ll be with boots on the grounds. DoorDash was so right making devs do like an hour of actual gigging. Yeah, shit is really pretty and seamless from your Herman Miller chair and Uplift desk…
Yeah builders should understand the domain they're building for as well as humanly possible. On the topic of chairs, imagine the difference between a chair built by someone who has never sat in one, and someone who is absolutely passionate about sitting in chairs and is looking to build the perfect most comfortable one. It's actually deranged that such a large portion of the software industry has built up an insane game of telephone between the builders and the users and convinced people that it's an essential practice for success.
This is also true for regulatory regimes. I've been shocked at how cavalierly some regulators will treat decisions that have career altering consequences for those being regulated.
It doesn't just affect the regulations, it also means their entire mental model of how the regulated will behave can be wrong.
This is what happens when you view your job as "make regulations" (or even worse, enforce the ideological will of $PERSON on $INDUSTRY) instead of "make $INDUSTRY safer and better for consumers and the public."
I knew an early dev at DoorDash, and he hated that policy.
That said, I personally agree with that approach. It's the practical vs academic argument: the ideal is both. Anecdotally, the most productive dev on my team was hired from a customer of ours where he personally used and integrated with our software.
My son worked at Chipotle. The biggest problem with their system was inability to set a time-to-ready for online orders. Delivery time was set fixed to say half an hour, no feedback from the location. So in rush times there were a lot of unhappy customers, venting their unhappiness on personnel and - forget tips (during rush hour!).
If developers had experience at retail locations… strike that - if persons responsible for software purchases had experience at locations, this probably would have been avoided.
The article also does not mention communicating time-to-ready back as an issue. Or may be I’ve missed it - too many details already…
Readit News
And that's not even _starting_ on the nonsense and bizarre home-rolled systems that small businesses concoct around layaways.
But it was against policy to use the feature, since previous cashiers had worked out a way to scam the system somehow and pocket some of the cash being exchanged. I'm cloudy on the exact details after so long, but it was very, very annoying to have such a useful feature sitting there mocking me and a write up if I dared hit the button.
For the clerks and workers using the POS, it's often more of a hinderence than it is a help. When you look at less technically reliant societies (i.e. market places in Asia) you'll see this more often. Prices are negotiated, they can be their own warehouse, smaller companies work together (your package getting from maker, middleman, aliexpress to your door is incredibly complex but they can make it happen within 2-3 weeks).
In the modern software company there is only one customer, the next early stage investor. I can assure you, your execs know how to pitch to them, otherwise they wouldn't have received their A round.
At the market there was all sorts of bartering and swapping and deal making - my “business analyst” brain recognised that to model all the “transactions” occurring at a typical market would be super complex.
However… the large retail chain should not support subtle/overlapping transactions of that sort- not because it’s too complex to model, even if it was free to model it, make the software track it — the reason the retail chain would avoid it is: profit margin.
You do profitable things, you do them a lot, and you don’t pay the opportunity cost of doing less profitable things. That’s the open secret of successful retail. And small businesses everywhere do not internalise this.
And often the answer is no unless you can demonstrate the time gain and emotion of your customer. When the margins are super thight anything that won’t help margings is left away and home delivery /online shopping will be prioritised for the tech team/budget.
Overall I'm really excited about LLMs being integrated deeper into product development, there are a lot of insights already captured in their output that people building products could use
Our suspend/resume sale feature assumed that a suspended sale could only be resumed on the machine that suspended it. Then we had to change it to be resumable on any machine in the store. But only show a flashing notification that there’s a suspended sale, on the original machine.
(Thanks for storing that knowledge for me for the last decade, neurons. I doubt you’ll be asked to recall it again.)
I dreamed about just such a feature when I worked at a convenience store back in high school. That was 30 years ago. Such progress... >sigh<
There are a number of things that even many just modestly-paid developers don't grok because they obviously make no sense.
Many years ago I remember asking a then-gf why such and such a store customer service accepted utility payments. And she was "Umm. Some people don't have checking accounts." Layaways are different but in the same general category.
I think it depends a lot in the country or the business, in some places is so easy, but in others is so difficult.
I remember at least 20 years ago, in the grocery store with the most basic digital scales, every clerk would have their "tab", shared between all the scales. So each one could use the scale nearest to the fruit they were weighing in that moment, then switch to a different one... And finally print the whole ticket without interfering with the other clerks.
Something like this... https://cdn.wallapop.com/images/10420/5j/p7/__/c10420p335420...
It can also become a challenge if you have a lot of those and want to find the right one. We had some users that prepared a lot of orders in advance into bags, so they can hand them to the customers right away when they come. Best solution was to print a delivery note for every order, attach them to the bag and then scan a barcode on the bag when the customer comes for pick up/payment. And you also need to be able to add or remove items before the customer pays, people often change their mind.
One hypothetical example: a tiramisu with coffee has a special price, but you still need to put them separately on the invoice, either because you track if the tiramisus are out of stock and want to stop people ordering more. Or coffee and tiramisu may have different sales taxes (very common in Europe to have a lower tax for food).
Different prices for take away and eating in the restaurant, happy hours. Payment in different currencies, some articles may have fixed prices in a foreign currency, others need conversion with the current exchange rate.
The possibility to split or join invoices.
Usability and speed is crucial at the POS, the users go crazy if they are busy and their software is too slow or has too many submenus. It has to be easy to learn too, often they hire people that fill in for a few days, and they need to be able to use it. A lot of people using it are also not very skilled with computers, or have no interest in learning how to use the software.
The owner may restrict some features to some users, so they can't cheat the system (taking cash payments, cancelling the invoice and keeping the money). There may be some tax fraud prevention laws to be implemented, vastly varying on the region, like digitally signed invoices or the need to report every issued invoice to the authorities in real time.
Some examples: Bread from bakery plus lunchmeat from deli = taxed at grocery rate, but a shrinkwrapped sandwich using the same bread and lunchmeat = taxed at the higher 'prepared meal' rate (because that's a luxury).
One candy bar is taxed at the grocery rate, because it includes wheat in the ingredients, while another is taxed at the junk food rate because it doesn't. They're both mostly chocolate and nougat, but one has some wheat, so it's legally considered a cereal.
And of course all of that varies from town to town and state to state, and sometimes even in different neighborhoods within the same town. And of course, some towns cross those political boundaries. I used to live just down the street from a shopping center where the tax rates were different depending on which store you were in (east side of the mall vs west side of the mall).
That's all before you get to sales and specials and membership discounts and such. Oh, and tax-exempt shoppers (because they work for a charity or something).
People always make fun of the U.S. for not just putting the total final price (tax included) on the shelf but the reality is, we can't because quite often we just can't know what it will be until you checkout.
For something that seems so simple and everyday, it really is bafflingly complex.
My extended family recently opened a pizza place which just happened to be at the same time as me wanting to take a break from startup grind. I worked at a pizza place in high school, and have continued to make pizza at home, and loved the idea of being able to combine that knowledge with the experience of building software startups, so I have been heavily involved in the last 6 weeks on everything from ordering, to kitchen layout, to POS and other IT systems, to marketing.
In short, the experience has been super interesting, not only in terms getting to learn tons of new things and get familiar with how the tech side is done (spoiler alert, not that well) but also just generally how much of an opportunity there is to take the sort of thinking and skills required to build tech products and to apply them to a quick-serve restaurant (and I would guess lots of other small business).
I have been planning on writing something up, but this article is giving me good motivation to actually do it :)
This is vastly underrated principle that is rarely understood and should be much broadly applicable. My data is separate from other people's data. In Carta, I have had my startup investments leave the system (die, acquired, etc) and I am left taking screenshots of everything because my records are just foreign keys into some other data store. If they had mailed me PDFs even paper or something, I would be fine.
Storing values that could otherwise be derived results in complexity and discrepancy.
This may lead people to the conclusion that all values which can be derived should be derived, but in the case of a receipt/invoice, this is not the right call. Discretion must be applied.
If some data is meant to be truly immutable, and storing it separately won't impact your storage costs, store it separately. Because otherwise that immutability needs to be somewhere else in the system.
If you normalize your data and dynamically derive receipts, your logic needs to include all receipt logic you have ever used, cordoned by timerange. Was the price of a large Pizza changed in 2018? Your receipt logic and data has to reflect that forever. Did you allow stacking coupons but in March 2017 you started limiting it to 1 coupon per customer? Your receipt logic and data has to reflect that forever. Did you have a week where prices were rounding in the wrong direction when a certain coupon code was used? That has to be in your receipt handling forever.
There's just so much additional effort, so much potential to go wrong, and so little to gain.
when the data is stuff that could be paperwork - you get a copy, i get a copy - it should not be the case that one side gets to unilaterally decide if the data is deleted or modified.
It's not like the customers' data is meant to be separate, like they're all paying the same price that we decided for the day, other than promotions which would be a separate table or misc adjustments that would just be a col directly on the sales table.
There may also be a lot of related tables for finding the price (in the system I worked it was about 10 joins to get from the article to the price). It can be done in an immutable way, but it is possible that the way of calculating prices may change after an update. There may even have been a bug in the first place (like incorrect rounding, issuing rebates that shouldn't have been issued, incomplete sync of the prices table from the main server to the cash register, ...). Once you fix it all the previously issued invoices would show a different price. Which means you "lost" your copy of the invoice. Authorities don't like that. Credit card companies don't like it, if the customer disputes the charge and you show them an invoice with a different amount. Your bookkeeper doesn't like it, if a lot of payments don't match the invoices exactly, ...
Edit: Example for rounding: Two people split a pizza for 19,99$. Version 1.0 creates two invoices with 10,00$ each. Version 2.0 creates one invoice with 9,99$ and a second one with 10,00$. Then the authorities pass a law that rounding prices must always floor them. So Version 3.0 creates two invoices for 9,99$.
Alternatively you could go "all in" and create some form of versioning system, where you store the version number of the product
Do you keep the code for every historical tax law in your country?
In some jurisdictions you don't just want to put the pie through the POS system, you have to for both tax reasons and to make sure your employees don't ring up their friends on "faked" coupons.
The rest of the article is really nice as well and reflects with my personal experiences in bartending... indeed having experience in hospitality jobs is a major plus for anyone working in IT or design, simply because you learn to value first hand how important performance and good UX is at some of the highest-stress jobs there are.
(Just in case you're one of today's lucky 10,000.)
It’s something I wouldn’t have expected to happen regularly before I worked there and I surmise it happens everywhere.
Temporarily embarrassed millionaires eat my ass.
So that "eh, it's not that slow" and "It's only extra click" will bother you to no end when you have to constantly waste time on it.
"POS." Brenda's bubbly demeanor was reflected in a little dance that she did while saying each letter in an almost singsong pattern.
"You ..." Regan stops fighting his instincts, takes off his glasses, bows his head, and pinches his nose. "All of you understand that we can't call it that."
The rest of the engineers stood silently and without movement. They have to have planned it this way. He should have known something was up from the moment he walked in here.
"Why's that?" Brenda tilts her head to the side.
"Because it stands for piece of ..."
"Point of sale." Brenda blurts out before Regan can finish.
Regan slowly puts his glasses back on. "Is the POS going to be completed by the deadline?" He forces the words out through a clenched jaw.
Brenda remains still with wide eyes and a frozen smile on her face. The rest of the room nods that the deadline will be met.
"Then fine." Regan leaves; they can make the deadline then they can have their stupid little name.
The hotel is sold now and I’m wondering if I’ll ever work in such a challenging and multifaceted environment again.
It doesn't just affect the regulations, it also means their entire mental model of how the regulated will behave can be wrong.
That said, I personally agree with that approach. It's the practical vs academic argument: the ideal is both. Anecdotally, the most productive dev on my team was hired from a customer of ours where he personally used and integrated with our software.
If developers had experience at retail locations… strike that - if persons responsible for software purchases had experience at locations, this probably would have been avoided.
The article also does not mention communicating time-to-ready back as an issue. Or may be I’ve missed it - too many details already…