This content originally appeared on HackerNoon and was authored by Fabrizio Marozzo
When people are forced to adapt to software, rather than the other way around
Some seemingly trivial moments reveal far more than we might expect. One of them happened to me while I was spending some time abroad. The hotel was very large, with hundreds of rooms and a breakfast hall serving a constant stream of guests every morning.
At the entrance, an employee simply asked for each guest’s room number. She checked on her computer that breakfast was included and, a few seconds later, a small printer sprang into action. It printed three almost identical receipts. One was handed to the guest. The other two went straight into the bin.
The same scene repeated itself dozens, then hundreds, of times every morning. What struck me was not so much the receipts as the bin itself. It had not been placed there by accident. It sat directly beneath the printer, almost as though it were part of the system. Someone had clearly watched the procedure for long enough to decide that the most practical solution was to make it easier to throw away the unnecessary paper.
At one point, I asked the employee why three receipts were printed when two of them were immediately discarded. Her answer came naturally.
“That’s just how the system works.”
Six words that, probably without meaning to, capture one of the most common problems in digital transformation. It was not the employee’s decision. It was not even the hotel’s decision. The software imposed the procedure, and people had simply learned to adapt.
Perhaps printing three copies made perfect sense when the system was first designed. One may have been intended for the kitchen, one for the cashier, and one for the guest. Over time, however, the workflow changed. The organisation changed. The software did not. Changing it was probably considered too expensive, and so, every day, hundreds of receipts continued to be printed only to be thrown away.
This is not just a story about a hotel. It is a story about all of us.
How often have we encountered procedures that make no sense? Mandatory fields with no obvious purpose. The same information was entered several times. Buttons that must be clicked in a precise order. Data is already stored in one system that must be manually entered into another. Pointless operations that nobody can properly explain. When we ask why, the answer is almost always the same.
“That’s how the software works.”
Over the past few decades, we have digitised almost every area of life: public administration, healthcare, schools, universities, businesses, banks, and hotels. In many cases, the benefits have been enormous. In others, however, we have simply turned old bureaucratic rigidities into digital ones.
The paradox is that software is supposed to adapt to human processes. Increasingly, it is people who are forced to adapt their work to software.
Anyone who has studied Software Engineering will recognise the problem. Developing a program represents only part of its overall cost. A significant share is linked to software maintenance and evolution [1]: fixing defects, updating the system, adapting it to organisational change, and adding new functionality.
This is why software should be designed to be easy to modify: well-documented, understandable, and modular. In practice, however, many systems have grown over decades, accumulating patches, exceptions, and layers of complexity. The result is that even a small change can become expensive and risky, and organizations are often reluctant to take responsibility for making it [2].
At that point, a clearly inefficient solution may become, at least in the short term, the cheaper option. It may cost less to throw away thousands of receipts every year than to change a single software function.
The receipts are only one example. The same phenomenon creates much larger forms of waste every day: hours of lost work, unnecessarily complicated procedures, duplicated data entry, and frustration for both employees and users.
This is why I am not convinced by the claim that digitalization itself is the problem. The problem is not that we use software. The problem is that software can become so difficult to change that the real world is forced to adapt to its limitations.
Today, however, something may be changing.
Generative artificial intelligence could have an impact on one of the most important costs in the software lifecycle: maintenance. Language models can already read and explain source code, produce documentation, and identify possible defects. They can also suggest changes, generate tests, and help developers understand systems built many years ago [3].
This does not mean that they will write perfect software. Nor does it mean that they will replace software engineers. It does mean, however, that they may reduce the cost and effort required to make the small changes that organisations currently postpone again and again.
The more interesting possibility concerns users themselves. Imagine an employee simply writing:
“Three receipts are printed for breakfast, but we only need one.”
The employee is not describing a technical solution. They are describing a problem in the same language they would use when speaking to a colleague. A system based on language models could interpret the request, identify the relevant part of the software, find a solution or propose a change, and support developers in implementing it.
Language models could make the dialogue between those who use software and those who build it far more direct.
That small bin beneath the printer will probably continue to fill with paper for some time. But as I looked at it, I saw more than waste. I saw the symbol of an approach to software design so rigid that people were forced to change their habits around it.
Perhaps the next major contribution of artificial intelligence will not be to make software do entirely new things. Perhaps it will be to help software adapt to people.
And perhaps, one day, someone will finally be able to remove that bin from beneath the printer.
References
[1] Hunt, B., Turner, B., and McRitchie, K. “Software Maintenance Implications on Cost and Schedule.” 2008 IEEE Aerospace Conference. IEEE, 2008.
[2] Curtis, B., Sappidi, J., and Szynkarski, A. “Estimating the Principal of an Application’s Technical Debt.” IEEE Software, 29(6), 2012, pp. 34–42.
[3] Hou, X., et al. “Large Language Models for Software Engineering: A Systematic Literature Review.” ACM Transactions on Software Engineering and Methodology, 33(8), 2024, pp. 1–79.
This content originally appeared on HackerNoon and was authored by Fabrizio Marozzo
Fabrizio Marozzo | Sciencx (2026-07-17T22:54:57+00:00) “That’s Just How the System Works”. Retrieved from https://www.scien.cx/2026/07/17/thats-just-how-the-system-works/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.