As programmers, we often focus solely on the technical perspective, overlooking the knowledge of the business domain itself. Sometimes, a deeper understanding of the business can add significant value through programming and technology.
However, with business competition being fierce nowadays, merely providing better products and services isn’t enough to achieve success. It’s also crucial to disclose as little company information as possible, especially to competitors, in order to maintain a competitive advantage.
Imagine you’re developing a Point-Of-Sales System for a beverage shop that sells a variety of beverages. When customers order their drinks, they receive a printed receipt like this:
![Point-Of-Sales System]()
At first glance, the invoice seems well-designed. It’s neat, displaying the customer’s order information, the total price, and the Order No.
However, upon closer examination of Receipt No., one can deduce its format: YYYYMMDD, followed by a running number. For instance, if the Order No. is 003, subsequent orders would be labeled 004, 005, and so forth.
This might seem like a minor design choice, but it could inadvertently reveal crucial sales information to competitors about our beverage shop’s daily volume!
Let’s say I’m a competitor to your shop, “Power Tea.” Knowing that your shop closes at 9 pm every day, I might visit around 8:45 pm to buy a cup of tea and note the Order No. If today’s Order No. is 854, then I know I’m the 854th customer of the day. Repeating this tactic daily, for the price of just one cup of tea, I can gauge your shop’s daily customer volume! While each receipt’s total might vary, exposing daily customer numbers is a significant business risk.
Assuming the beverage shop owner has only been in business for a month and you aim to help her navigate the competitive market (so she might re-hire you for system upgrades as the business grows), what modifications to the Receipt No. would you suggest?
Random Incrementation
I believe ‘Random’ is the first word that come into mind to every programmer when we want to introduce chaos or uncertainty. One approach could be to randomize the Order No.: the first order might have an Order №101, while the second could jump to 107, and the third, unexpectedly, to 303! Taking it a step further, we could generate an alphanumeric Order No., with values like B45N02 or HJ888Y, which give no indication of total sales. A rival inspecting an Order No. such as HJ888Y would be left scratching their head, clueless about the shop’s sales.
Yet, while this might seem clever, we must consider the user experience. As mentioned earlier, we programmers must also grasp the nuances of the business we serve. Imagine a typical customer wanting a refreshing lemonade. Seeing their Order No. as 303 and the current serving Order No. as 107, they might panic, thinking they have to wait for 196 orders before theirs. Furthermore, an Order No. like HJ888Y provides no indication of the wait time from the current serving order B45N02.
Side Note: Utilizing alphanumeric values for Order No.s is an effective strategy for obscuring sales. However, this is most suitable in situations where customers don’t use the Order No. to determine service or product queue, such as with online sales or flight tickets.
Random Start
A more refined approach is to use a random starting point. For instance, today we might begin with the running number 1000, and tomorrow with 2800. This can befuddle our rivals without confusing our customers, who rely on the Order No. while awaiting their beverages.
This method works well, until one day our rival find out our trick, and he came to our shop TWICE a day. First day of the morning, to get the initial running number, and the end of the day, to get the final number. A simple subtraction later, and voilà! They can still deduce our total sales.
‘Cut Card’ Reshuffle
This method is akin to the Cut Card in Blackjack games. A Cut Card is a card with a distinctive color, randomly inserted into the deck of cards (normally by a player). Once the dealer reaches the Cut Card during gameplay, the deck must be reshuffled.
Similarly, we can generate a ‘Cut Number’ at random intervals; once this ‘Cut Number’ is reached, we regenerate starting from a new number until the next ‘Cut Number’ is reached. For instance, our Order No. might start at 1000 and stop at 4133, then recommence from 2000.
Yes, the customer that receive Order No, 2000 might confuse since the current serving number is 4133, but we can mitigate this confusion by introduce Current Serving No. and Next Serving No. to the receipt.
![‘Cut Card’ Reshuffle]()
Hide the Date in Order No
If it’s not essential, we can omit the date from the receipt. Customers typically require only the running number, not the specific date. Instead of using the YYYYMMDD format on the receipt, we can employ a unique code that changes daily. This would make it challenging for our rivals to determine the transaction date associated with Order No. like TEA-4133.
Promotion with Promote Code
The beverage shop can regularly host campaigns. These not only serve as a promotional tool to boost sales but also introduce a unique code to the current running number. For example, if a customer opts for our special Jumbo size tea offer, their Order No. would read JUMBO-1001. This disrupts the linear sequence sporadically, making it more challenging to ascertain the exact order count.
Internal vs. External Numbers
“The art of deception is to deceive yourself first, before you can deceive the enemy,” Sun Tzu.
Just kidding! Mr. Sun never made such a statement. However, we must ensure that we don’t first confuse ourselves in the process of trying to baffle our competitors with varied running numbers. A straightforward solution is to maintain two distinct sets of Order Nos.: one for external “deception” and another for internal reference.
![Internal vs. External Numbers]()
There are several intriguing methods to prevent the disclosure of total sales, though they might not be apt for our beverage shop scenario. One such method is the sharing of ‘Order No.’s. The shop would utilize a consistent running number for various tasks such as taking customer orders, generating internal purchase invoices, quotations, and so on. For example, CODE-102 could be for a customer purchasing a beverage, CODE-103 for an invoice related to sugar purchases, and CODE-104 could be a quotation number for buying a new table for the shop.
Conclusion
A career in software engineering demands proficiency in technical learning. However, at the end of the day, technology serves as an augmentation to the business, and the systems developed are designed for people. Understanding both the intricacies of business and the nuances of human behavior is, in my belief, a vital criterion that allows us to craft better, more user-friendly systems.