Translation: CAI Xuedan

Welcome to visit netease Cloud Community to learn more about Netease’s technical product operation experience.


There are many factors that can be catalysts for bad software: from the tools being used, to team communication, to the personal interest the developer has in driving its success, to the testing method.


I think there is a major problem here, one that can be the root cause of almost all software becoming bad software: the imaginary problem.


Most complex or broken software is not designed to be overly complex or dysfunctional, it is simply designed to do a lot more than it was intended to do.


Let’s say you’re a podcast host and you want to customize a site that can sell your advertising products, make money without third party involvement, and most importantly, offer podcasts, videos, and blogs to your audience.

  • The requirements of your small Web application might look something like this:

  • Short load times on the North American network, live streaming and downloading of blog streams.

  • 99.99% of users will not crash or get stuck for at least the first 15 minutes, and preferably never.

  • If you have the time, integrate well with Google Ads and other third-party AD providers.

  • Dynamically link to the latest products in your Own Zazzle store and, if possible, advise users based on what they consume.

  • Integration with Facebook Live Player. It would be nice to have an alternative solution that doesn’t require Facebook streaming.

You give these requirements to a team of contractors, and you talk to them for a while, and everyone seems to get the message. Then, two months later, when they come back with the minimum working product (MVP), your face turns red. You realize you just wasted $15,000 on a piece of junk, and you want your money back.


Because the screen freezes the first time you open the app. You ask them how they choose the types of ads they’re allowed to run on their site, and they point to a custom page (UI) that’s ugly and hard to understand. Half of Zazzle merchandise links are broken or missing images, and Facebook live streams are delayed!


But the developer team is confused by your anger — and rightly so, from their perspective — because they’re coming back to you after the hell they’ve been through.

They put their heart and soul into creating this app, which has some amazing features:

  • The most advanced recommendation system

  • An algorithm that generates copies of all streams in real time

  • The first screen load time can be less than 200ms on networks worldwide

  • Streaming protocols and clients were almost all built from scratch because they didn’t want to rely on Facebook live

  • The service lets you easily consolidate more than 20 AD deals


The problem is that you want your core product to have a bunch of extra features if they’re easy to implement. But the development team hears something different, they hear challenges that they can overcome… And a bunch of boring, basic features that they don’t even want to test or care about.


Even worse, you don’t talk to these developers directly — you’re playing a game of voice over the phone. You talk to a salesman, he and a middle management held a meeting, the manager wrote some business practices to PM, PM to write the technical specifications to the team leader or an engineer, in the end, the man and his team began to design the product, everyone in the process of design is more or less also added some its own distortion.


Even worse, you don’t talk to these developers directly — you’re playing a game of voice over the phone. You talk to a salesman, he and a middle management held a meeting, the manager wrote some business practices to PM, PM to write the technical specifications to the team leader or an engineer, in the end, the man and his team began to design the product, everyone in the process of design is more or less also added some its own distortion.


Most programmers want to get paid and have fun at the same time. Of course, the definition of “fun” is different for everyone, but for many engineers, it comes down to solving interesting and challenging problems that are solvable.




Give a moderately intelligent person too many boring tasks that can’t be automated, and you’ll end up driving him crazy. Over billions of years of evolution, however, the human brain is remarkably gifted at staying sane. Just as victims of childhood hardship or abuse can find escape in fantasy books, victims of entrepreneurship or freelance Web development can find relief in solving imaginary problems. The number of problems a software engineer can imagine depends on their imagination and also on the difficulty of the real problem they should be solving.


It should be noted that this problem is not unique to developers; management, sales, human resources, logistics support, legal, and even accounting departments have their own ways of creating imaginary problems. When they are not required or formalized to attend meetings, they try to involve themselves more in decision-making. They overemphasize a small issue related to their role, or recruit a larger team to illustrate their importance.


When a problem becomes stupid, a wise man will always find a solution.


But many of these imaginary problems aren’t just the result of bored developers; they can also be the result of long communication chains.


When I first started working with freelance clients, I was generous. Our email conversation chain has gone on for more than 100 times, just discussing trivial details about the internal MVP. I had people change every requirement of the project in a week. I asked users questions like, “Is this an ICO? “Or” Can we add some ARTIFICIAL intelligence here?”


Granted, most customers are more savvy than that, but even so, they often lack the knowledge needed to express or construct some requirements. That’s fine, as part of my career as a “computer guy,” my job is to help people figure out what they want to do and what they don’t need based on their use cases. But when you’re communicating several layers away from the customer, it’s much more difficult to determine what’s needed.


Requirements change because someone misunderstands an intent, or because someone is trying to cope with the above boring requirements


Most companies like to have a sales person pitch to potential customers, negotiate prices, and outline possible features. They also have one person dedicated to discussing more in-depth needs and details with the customer, which is usually another salesperson with a slightly different job title. Then there’s the chain of command within the technical team, the various levels of management, and maybe some other hierarchies.


When a list of customer requirements goes from person to person, even if those people have the best ideas, something inevitably gets lost in the layers of translation. Sometimes the change is because the original requirements didn’t make sense, or sometimes the requirements need to be redefined. The salesperson might tell the customer, “We can do this on blockchain for an extra £39,999. But it makes everyone who encounters a need want to know what the definition of “doing on blockchain” is.


Many times requirements change because someone misunderstands an intent, or because someone is trying to cope with the above boring requirements, trying to make his work or his team’s work more interesting and impressive.


So through all this, the original need — the real problem has been dissolved in the process — is lost. They’re replaced by imaginary questions and holes, and you’ll find that a lot of people are ready to fill those holes with their imaginary problems, because the problems they really need to solve are boring, and filling those holes gives them a way to deal with that boredom.


Overcomplexity and natural selection


Imaginary problems often exist for a darker reason: they can help a team or company grow, or even become an integral part of its functionality.

People who are trained, picked and compensated to find complex solutions are often not motivated to implement simplified solutions. — Nassim Nicholas Taleb


Have you heard of those three Web engineers? They discovered that secure online banking was actually an easy problem to solve, developed some perfect banking software from scratch, used functional design methodology and memory security language, and then started migrating major banks to their amazing infrastructure.


Maybe you haven’t heard of them because they don’t exist. However, there are many teams of thousands of developers who cannot grasp a simple concept like “rollback” and keep creating banking software.


The storage and transfer of numbers is not a particularly difficult problem. Retrieving the entire Internet and producing relevant results for natural language queries in a short time is a problem, but a few smart people have managed to solve it.


But the problem with online banking is that the bank’s own ecosystem has become very good at maintaining its own hierarchy of profits, and its leaders are corrupt leeches who prey on society — but the leaders in the organization are only a symptom of their members.


I don’t think most bank employees are evil or malicious. On the contrary, they are usually friendly guys who feed, shelter and educate their families, but their main motivation is not to fix the banking software, but to save their jobs. For some, losing a job in today’s economy is no laughing matter; In banking, being too talkative or aggressive can easily expose yourself before a disciplinary committee.


So banking systems remain the same – not because they are efficient, but because of inertia. This form of inertia is intended to solve imaginary problems in order to avoid solving real ones. When real problems are identified, they threaten the work of others. Focusing on these real problems can lead to sackings or, at particularly egregious “institutions” such as Goldman Sachs, to strange suicides by sending a few life-destroying brown envelopes to the FBI.


It’s hard to get a man to know something when his salary depends on what he doesn’t know about it! – – Upton Sinclair


Top managers ignore the fact that 90 percent of their top managers’ time is spent in “client meetings” involving tropical islands and millions of dollars in “other expenses” budgets. In return, these top managers turn a blind eye to the corruption of their superiors.


Upper management ignores middle managers who buy wacky offices and hire themselves three secretaries and a dozen interns because middle management encourages them to live in a Wall Street fantasy.


Middle management also ignores the fact that line management spends their time on powerpoint presentations about “improving our Agile methods” rather than cutting costs, because line management doesn’t complain about their fantasies of dictatorial power.


The production line management ignored the team lead and architect talking about “the next generation interface between our systems using JRPC and our microservices using Hibernate and Spring”, so it should have taken them less than a day to process those damn MySQL queries. Because the team leaders don’t seem to notice that their superiors can’t even use Excel properly and only come to the office every few weeks.


Instead of complaining about their developers, the team leaders looked at the explanation of the slow queries mentioned earlier and, for the tenth time that year, redesigned the UI with a new JavaScript framework. Because the developers don’t seem to notice that their leaders don’t actually write any code other than DOT diagrams.


It’s a vicious cycle of solving imaginary problems, never realizing that stealing another 30 million won’t make his father fall in love with his CEO, To UE interns who didn’t realize that using the angular-Material-Bootstrap 19.13.5 redesign of the “Submit” button would not make them store passwords in clear text (as part of an authorized cookie) disappear.


But everyone needs to keep solving imaginary problems, because if they stop creating and solving them, if they start focusing on real problems, they may realize that the system is broken. They probably realize that Debra has been sitting in that corner staring at uptime charts for internal server clusters for 10 years, even though the company moved to AWS five years ago. They probably realize that 99 percent of their job is to perpetuate the work of others. This is a difficult truth to accept — and, DARE I say, impossible for most people. As a result, most people find a way to cope.


Original: https://medium.com/s/story/imaginary-problems-d4f2921bd1b8


Free access to verification code, content security, SMS, live on demand experience package and cloud server packages

For more information about netease’s technology, products and operating experience, please click here.


Spark provides more flexible capabilities for data analysis and processing