But imaginary problems aren’t just the result of bored developers. They’re also the result of long chains of communication.

When I first began taking on freelance clients, I couldn’t afford to be particular. This means I’ve had email chains lasting for over a 100 exchanges, discussing insignificant details about internal MVPs. I’ve had people change every single requirement on a project within the span of a week. I’ve had clients ask questions such as “Could this be ICO-ed?” or “Can we add some A.I. in here?”

Granted, most clients are savvier than that, but, even still, they often lack a bit of the knowledge necessary to articulate or construct some of their requirements. That is fine, as part of my job as “the computer guy” is to help people figure out what they do and don’t need based on their use cases. But it can become much harder to determine what’s needed when there are a few layers between you and the client.

Requirements get changed because someone either misunderstood an intention or because someone was trying to cope with that aforementioned boredom

Most companies like having a sales guy who pitches potential customers, negotiates prices, and outlines possible features. They also have a people person to discuss more in-depth requirements and details with the customer, usually another sales guy, but with a slightly different title. Then there’s the internal chain of command, various levels of management, and possibly some hierarchy, within the technical team.

When a list of client requirements goes through so many people, even if those people have the best of intentions, some things will inevitably get lost in translation. Sometimes that change happens because the original requirement made no sense, or sometimes requirements need to be redefined. The sales guy might have told the client, “for only 39,999 extra we can do this on the Blockchain.” But that leaves everyone who encounters the requirements down the line wondering what the definition is of “doing it on the Blockchain.”

More often than not, requirements get changed because someone either misunderstood an intention or because someone was trying to cope with that aforementioned boredom, trying to make his job or the work of his team more interesting and impressive.

Through all of this, the original requirements — the real problems that have to be solved — get lost. They are replaced with imaginary problems and with voids, and you’ve got plenty of people ready and willing to fill those voids with their own imaginary problems, because the problems they have to solve are boring, and filling the voids gives them a way of coping.

Overcomplexity and natural selection

There can often be an even darker reason for the existence of imaginary problems: problems can help a team or a company grow, and can even become an integral part of its function.

“People who are bred, selected, and compensated to find complicated solutions do not have an incentive to implement simplified ones.”

— Nassim Nicholas Taleb

Have you ever heard about those three web engineers who figured out that secure online banking is actually quite an easy problem to solve? They developed some flawless banking software from scratch, using a functional design methodology and memory safe languages, then started migrating major banks to their amazing infrastructure.

Probably you haven’t heard of them, because they don’t exist. There are, however, plenty of teams of thousands of developers, who are unable to grasp simple concepts such “rollbacks,” perpetually creating banking software.

The storage and transfer of numbers is not a particularly hard problem. Indexing the whole content of the internet and providing relevant results to natural language queries, in sub second times, is a hard problem. But just a few smart guys managed to solve that problem.

The persistent problem for online banking is that the banking ecosystem has become really good at preserving its own money-grabbing hierarchy. Its leaders are corrupt leeches who prey on society — but the leaders in an organization are just a symptom of its members.

I wouldn’t suggest that most underling workers for banks are evil or malicious in any way. Far from it. They are usually friendly lads, working to provide food, shelter, and an education for their families. But their chief incentive is not to fix the banking software, it is to stay employed. Losing your job in today’s economy is no joking matter for some; in the banking industry, a big mouth or too much initiative is an easy way find yourself in front of a disciplinary committee.

So banking systems remain the same — not because the systems are efficient, but because of inertia. This inertia comes in the form of working on imaginary problems in order to avoid fixing real problems — real problems which, once pointed out, would threaten the jobs of other people. To focus on these real problems could lead to getting fired, or, in the case of some particularly nasty “institutions” like Goldman Sachs, getting a few life-ruining brown envelopes sent to a few FBI officers and prompting a strange suicide.

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it!”

— Upton Sinclair

The C-suite ignores the fact that their upper management workers spend 90 percent of their time on “client meetings” that involve tropical islands and million-dollar budgets for “other expenses.” Upper management, in return, turns a blind eye to corruption in C-suite.

Because middle management encourages them to live in their Wolf of Wall Street fantasies, upper management ignores middle managers who buy eccentric offices and hire themselves three secretaries and a dozen interns.

Because line management doesn’t complain about their dictatorial power fantasies, middle management ignores the fact that line managers, instead of cutting costs, spend their time working on PowerPoint presentations about “Improving our Agile Methodology.”

Because the team leaders don’t seem to notice the fact that their superiors can’t even use Excel properly and only hit the office every few weeks, line managers ignore the team leaders and architects talking about “next generation interfacing between our systems using JRPC and microserviceization using Hibernate and Spring” when they should be getting those bloody Mysql queries to take less than a day.

Because the developers don’t seem to notice that their leaders don’t really write any code except DOT diagrams, team leaders don’t complain about their developers, instead of looking at an EXPLAIN for the aforementioned slow query, re-designing the UI for the tenth time that year using a new JavaScript framework.

It’s a vicious cycle of solving imaginary problems, from the CEO who doesn’t realize that stealing another 30 million won’t make his dad love him to the user-experience intern who doesn’t realize that redesigning the “submit” button using Angular-Material-Bootstrap 19.13.5 won’t make the fact that they store passwords in plain text (and use them as part of the auth cookie) go away.

But everyone needs to keep solving the imaginary problems, because if they stop creating and solving these problems, if they start focusing on the real problems, they might realize the whole system is broken. They might realize Debra has been sitting in that corner, staring at uptime graphs of the internal server farm for 10 years, despite the fact that the company moved to AWS five years ago. They might realize 99 percent of their job is to perpetuate the existence of someone else’s job. And that’s a hard realization to digest—impossible for most, I dare say. So, instead, most find away of coping.