–1 books
Amazon, the online ‘everything store’, is famous for business experiments and relentless customer focus. Jeff Bezos, the key man behind Amazon’s huge success, explained the core strategy in an interview with the Washington Post in 2013. ‘We’ve had three big ideas at Amazon that we’ve stuck with for 18 years, and they’re the reason we’re successful. Put the customer first. Invent. And be patient.’ Inventing led to lots of experiments that got killed, most famously the Kindle Fire phone. Customers didn’t seem to find that particularly interesting, no matter how patient Amazon was. On the other hand, quick experimentation led to a ton of fantastic discoveries, such as the behaviour-based search, which brought the company millions of dollars. Yet, even with its focus on customers being the first item in the immortal strategy, Amazon still decided to kill one particular feature that customers found incredibly useful. Being able to order –1 books.
In an interview with Richard Brandt, the author of the book One Click, Bezos said, ‘We found that customers could order a negative quantity of books! And we would credit their credit card with the price and, I assume, wait around for them to ship the books.’ (In the book Amazon Hacks, the discovery of this feature is credited to Jonathan Leblang, one of the early Amazon customers who joined the online store as a developer in 1999 and still works there.) This was obviously a great customer-centric feature. It’s also a fantastic example of how software quality is not something that can be measured on a simple scale. For Amazon, this was obviously bad. But for users, negative quantity actually brought positive quality.
Of course, trusting users to enter anything is always going to lead to problems. When I started working professionally as a developer, one of my first assignments was to figure out how some users were able to obtain huge discounts in an online store. With a bit of logging, a colleague and I discovered that the shopping cart was submitting prices from the web browser, and the back-end blindly trusted it. People with a bit of HTML knowledge could just edit the page and set their own price for anything. Luckily, the whole thing would fall apart if the prices were negative.
Although every few months someone uploads a new video to YouTube showing how to apply a similar trick to smaller web stores (search for ’tamper data shopping’), as an industry we’ve generally learned to validate user inputs. Still, the negative quantity problem keeps happening. For example, the Red Hat Cloud Installer was affected by such a bug in 2016, where entering a negative quantity for the number of subscriptions activated all possible subscriptions. And it’s not just shopping carts that suffer from this problem. The popular virtualisation container management software Kubernetes allowed users to request a negative amount of memory or CPU power, which would then cause other containers to be placed into hosts where they couldn’t fit.
The reason why these problems keep happening is people might think they’re managing conceptual values such as quantity, but computers only care about numbers. Some conceptual values might not make sense in real life, such as negative quantity, so they are easy to overlook. Computers will happily translate them into numbers, though.
With order management systems the problem is even trickier, because negative quantity sometimes actually makes sense. For example, negative inventory might be a consequence of selling too much. This is far from a software bug – it might actually mean that the business is doing better than expected. It’s often much better to allow the inventory to go slightly negative and order more supplies than to reject a sale.
When the same concept makes sense for one part of a large system but is meaningless in another, edge cases often lead to bad assumptions and software problems. Customer service staff might try putting in negative orders to signal returns from customers. That leads to some intriguing conversations between developers and users on whether something is an issue or a feature, such as the comment ‘This is not a bug, because it’s a negative receipt not a return’ on the IBM Maximo Asset Management support site.
Negative quantities are a great way to play parts of a system against each other, because people often make different assumptions about them, especially if there is a workflow in which steps can be reversed. For example, the Intuit Quick Books Point of Sale software had a bug that would break purchase orders because one part of the process supported negative quantities, but another part just ignored them. Users were able to enter items received against a purchase order, then reverse it (for example, to undo a bad entry), then book the items again, and the purchase order would end up in a broken state. Reversals would try to remove items by submitting a negative quantity, but the entry system didn’t allow negative quantities, so that part just got ignored.
Trusting users to enter correct information led to so many problems in the early days of Internet that most software developers today actually do a good job validating inputs, and preventing silly problems. However, as an industry we still have to learn the lesson of similarly distrusting computers, as the next few stories show.