ACT II: THE MACHINE — How the system works (or doesn't)
There's no case... no problem or situation that can't be reduced to its most basic expression, its most fundamental definition... no discipline escapes this.
Every process shares an indispensable requirement for its objective: requirements documentation.
Theory says that's where every process begins, and because of this characteristic, it's a fundamental stage that, if omitted, generates inconsistent results at best.
And yet... this process is undervalued and treated as a complete triviality in small and large companies alike. As in all aspects of life, there are always reasons—some valid, some not. What's impossible to ignore is that it always happens the same way. Definitions, requirements, scope—they're scarce when they exist at all.
It's not even a matter of industry or subject matter. Job profiles, work instructions, business requirements, budgets, contracts, etc... they all seem like a joke.
More than once I wonder if the professors I had actually practise what they teach, or if they simply describe what should be done without explaining why in reality you probably can't do even half of what they just explained.
I also wonder whether theories have become obsolete and we need to tear down those models to establish new ones. What's evident is that someone is making a mistake—either in the theory or in the implementation.
Naturally, the absence of documented requirements doesn't guarantee failure. If there's one thing companies permanently demonstrate, it's the capacity to exist while ignoring every theoretical model—examples abound.
What does generate a lot of unease in me is how something that's supposed to be a pillar, a foundation, a cornerstone, can be omitted so frequently and treated so lightly—knowing, moreover, that the rest of the process is built upon this base.
Note: Perhaps for another post is the topic of those companies that have all this documentation purely from the need to obtain quality certifications. Quality has been deformed from a management model into a market requirement; the result has been the prostitution of the term... it's become Chuco.
The Taleb Connection
Two years before The Bed of Procrustes came out in English, this article noted that quality certifications had prostituted the term quality. Two years after, Taleb wrote this:
"Academia is to knowledge what prostitution is to love; close enough on the surface but, to the nonsucker, not exactly the same thing." — Nassim Nicholas Taleb, The Bed of Procrustes (2010)
The structure is the same one the article is naming. A standard exists because someone needed a way to certify that the work was being done. The certification then becomes the goal, the documentation gets produced to satisfy the auditor, and the actual purpose — that anyone reading the documents could understand and repeat the work — quietly leaves the building. Surface preserved, substance gone.
The deeper book-title concept is also load-bearing: the Procrustean bed is the move of cutting reality to fit the model. Job profiles, work instructions, scopes, budgets — when they "seem like a joke," it's because they were drafted to fit a template that needs a tick, not the actual shape of the work the team has to do.
Foundations are foundations only if the people building them suffer when they're wrong. When the cost of skipping requirements is paid downstream — by the workers dealing with undefined scope, by the clients paying for half-built features — the people drafting (or not drafting) the foundation have no skin in the game. The rest of the building wobbles, and they're already on the next project.
This article was translated from the 2012 Spanish original and revised in 2026 through human-AI collaboration—clarifying transitions and adding connections to Nassim Taleb's framework.