Hiring a developer or a team of developers for a simple task like building an app becomes cumbersome when the hired people are too motivated — they end up solving problems that did not exist in the first place. These are called imaginary problems — more fun to solve than the real ones but no one asked to solve them in the first place.

For example, when asked to build a simple UI with recommendation systems integrated with a couple of extra features like Facebook streaming, an over-ambitious developer would integrate an algorithm that generates transcripts, some AI features or challenges not required by anyone. 

In a bid to create something amazing to brag about in their portfolio, such developers sidestep their focus on designing the most basic features of the required app. They end up creating something very complicated, over optimising it, which ultimately takes more time than expected and are riddled with glitches. It may look like they are at fault, however, they cannot be solely blamed for this. The problem wouldn’t have existed if the manager laid out a step-by-step plan from the beginning and kept a check on and guided every step of building the goal they have. 

For the experts, a lot of it just stems out of boredom. It’s true that programmers want to get paid and have fun at the same time but they end up creating more problems when they build something beyond the need of the client, resulting in the root of bad and unwanted software, as narrated by George Hosu, in his five year old blog. 

To side with the developers, Hosu explains that it is indeed more fun to solve imaginary problems than the real ones. That is probably also why it is difficult to find programmers who would do a simple job for you that does not require much challenge and creativity — not everyone wants to do it. This is because the world of software engineering and programming has incentivised people to solve problems that oftentimes don’t even exist.

A user on HackerNews, explains that companies would not want to hire a developer who simply puts, “did the task that I was assigned without any creativity” in their resume. They have to invent and create something new to stand out from the crowd.

In the end, the one who ends up bearing the brunt of it is the person who hired the overly creative and brave developer who wants to create something new. For the managers, they don’t get rewarded for managing a lean team who can do the job, but all the extra features that the team can input in the project. Neither the developer nor the hirer can be blamed for this. 

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

Unless everyone involved has their incentives aligned, we would end up solving imaginary problems. At the same time, there is actually a good side to this. We end up producing more solutions than are actually required, end up solving problems that did not even exist in anyone’s vision. Hosu said, “Give a somewhat intelligent person too many boring tasks that are impossible to automate and you will eventually drive him mad.” 

It’s true for every profession and not just programming. A user narrates in the Reddit discussion about how it is very similar to a graphic designer. “I would end up creating the same designs for the client, until I got bored, and started experimenting with my own style.” What ends up happening in such situations is delayed delivery. To deliver something out of the box, oftentimes, developers end up delivering that is something that is not required. To solve an imaginary problem, they end up creating another problem.

“The amount of imaginary problems a software engineer can create for themselves is a function of their imagination and the difficulty of understanding the real problems they’re supposed to solve.”

Everyone wants to go off and build shiny things instead of solving real problems. “I have to find enough shiny problems that actually need solving to balance out the daily grind,” explained one of the team leads of a project.

A lot of times, developers should be convinced to do less. Because oftentimes, you end up making an over engineered solution to a simple problem that requires a boringly obvious solution. A developer should have fun while building something, but it shouldn’t come at the cost of deviating from the initial simple goal of the project.