Hard constraints on software development

When checking out at a supermarket, the cashier will give us a receipt. Sometimes we buy two or three of the same product, and the receipt will have only one line with a quantity of 3, but sometimes there are three lines with a quantity of 1. This phenomenon is very interesting. Why is it not uniform? And from my observation, the latter situation is obviously more common. It is obvious that the former method saves more paper, so why is it less used?

I once thought that it was because the cash register machine had poor performance and little memory, so it could only maintain simple array structures, not collections, and could not rescan the array for modification every time a product was added. But if you continue to observe, you will find that this statement is untenable - the performance of modern cash registers is good enough, and even the performance of mobile phones is improving by leaps and bounds. So what is the reason for doing this? Just when I was puzzled, a chance opportunity solved my doubts.

At that time, we were going to develop a goods receiving management system. In order to save paper and pursue the "beauty of the program", I decided to choose the "single-line multiple records" approach, that is, "1 line of record, quantity 3", because the hardware performance was more than enough. After the program was developed, there was no problem with the test, and everything went very smoothly. However, after the actual application, the colleagues in the warehouse were very dissatisfied with this point, and strongly required that each line correspond to only one piece of goods, and multiple records must be made for multiple pieces of the same goods. Well, it's a good opportunity to see the reason.

When I saw it on site, I immediately understood the problem of recording multiple items in one line. First of all, everyone is used to scanning one item at a time, and a line of records needs to be printed on the corresponding list to confirm that the scan is complete. Of course, we can say that other prompts are also OK, such as flashing the screen or making sounds. However, the list generated by the scan will also be used by the employees in the next process. When handling goods according to the list, he certainly hopes to directly cross out a line from the list for each item ordered; if this line corresponds to more than one item, he can only write the word "positive" next to it to count, which naturally greatly reduces efficiency (if you carefully observe the restaurant waiter's serving process, you will also find this point, but few people will order two servings of a dish).

This discovery touched me a lot. Probably because I have been working on "pure" software products for a long time, so although I have to consider dividing boundaries, separating responsibilities, and designing architectures, these are "soft" and there are no "hard" constraints: whether a function or a responsibility is placed here or there, there are certainly architectural considerations, but if it really needs to be modified, there will usually not be too big a problem, so even if you only consider it from the perspective of logic and beauty, there is no problem. The most typical message passing can be used for "push" or "pull", and there will be no big difference in general scenarios. However, many problems in the real world are not so simple. Limited to devices and scenarios, sometimes you can only "pull" but not "push". For example, some mobile devices are limited by power consumption, so "push" is of course better than "pull". In the face of such "hard" restrictions, if we only lock ourselves in the office and work behind closed doors, no matter how well the program is written or how beautiful the architecture is, it is not considered to have really solved the problem.

Don't think that only software is subject to "hard" constraints from the environment. Sometimes, the environment is also subject to "hard" constraints from the software. If you pay attention to the product manuals, you will often find that many products provide multi-language manuals. The text of the manual does not need to be too long, and the cost of the manual is many times higher if each language version is printed. In fact, the target market (target language) of the product is almost certain, so why waste the cost of making multi-language manuals?

It was not until I visited the production line in the factory that I really understood the reason: the software can be separated and combined freely, but the production line cannot. According to the actual situation, the production management system used by most processing plants can only support "single raw material list, single process, and single product production". If the products sold to different destination markets are the same in body but different in instructions, the production management system cannot separate the link of "putting in instructions" as a variable and insert it into the "template" of the production process to achieve "same body production process but different instructions for packaging". Even if the production system can support it, the production line cannot be arranged in this way because the station combination of the entire line is fixed. Yes, advanced production management systems and production lines can support this "template + variable" model, but the cost of implementing it is too high.

Therefore, if we don't use multilingual manuals, we can only equip different markets with different production processes (hard copies). If one process needs to be changed, all production processes need to be changed, which is too costly. So we can only settle for the second best option, which is to spend a little more money and print the most variable - the manual - in multiple languages. Although it seems wasteful, it is the most economical and convenient way.

This kind of question seems simple, but I still think it is worth talking about it because I find that with the development of the Internet, especially the mobile Internet, software is increasingly involved in all aspects of life, and is increasingly subject to the "hard" constraints of reality. In the past, software development was more like an independent discipline, so everyone had to learn how to "use software", and software developers enjoyed the power to "change it" at will. But now, since software is "soft", it should be like water, without a fixed form, but can penetrate into every corner of the real world - in many cases, the value of software is no longer determined by advanced technology or complex architecture, but whether it can get along with reality in harmony. As software developers, we need to repeatedly ask ourselves what problems we want to solve and what restrictions we will be subject to, and then propose solutions that go straight to the core of the problem. In this regard, I have also encountered examples that impressed me.

At the receiving station for express parcels, what the receiver needs to do is weigh the parcel and scan the barcode on it. The electronic scale and the scanner are already connected to the computer, and the cursor will move automatically under normal procedures without manual intervention. But sometimes abnormal situations occur, and operations such as cancellation, rollback, and confirmation are still required. According to the common solution idea, a keyboard or at least a small keyboard is necessary. As a result, not only is an extra device equipped, but the operator also needs to transfer both hands to operate multiple devices. Later, a member of my team came up with a very clever solution: common operations such as cancellation, rollback, and confirmation are agreed upon as an operation code, which is printed out as a barcode and posted on the operating table. The operator can complete all the work without leaving the scanner: scanning this barcode is to cancel; scanning that barcode is to roll back; scanning another barcode is to confirm...

I must admit that although I have been engaged in software development for many years and have solved many problems, when faced with this problem, the solution I thought of was "how to simplify keyboard operation". It was not until I saw the QR code scanning solution that it suddenly dawned on me - it turns out that software can be done this way!

Well, software should be able to do this in the future.
Link to this article: http://www.cocoachina.com/programmer/20150228/11184.html