Please don't let programmers grope in the dark

I don’t know if you have ever played strategy games like Warcraft, X-COM, Civilization, and Red Alert.

These games use the so-called "fog of war". When you first enter the game, each player's map is shrouded in darkness, and the only way to move forward is to keep groping. As we continue to move, the map becomes more and more visible.

[[130979]]

The disadvantage of this strategy is that the player cannot see the dangers, obstacles and opportunities around him. Every success requires a little bit of luck.

Does this situation feel familiar to you?

The “fog of war” perfectly describes the situation that developers work in. They are always asked to solve a specific piece of code, but they are not told about the relevant tasks, which means they are left to grope in the dark.

It is necessary for developers to see the "whole game map". Having a clear grasp of the overall situation will help them make the right decisions. Here are the questions they need to know:

Why was this feature created? What benefits does it provide to customers?

What kind of development process did the code around this feature go through?

What other parts of the application will this feature affect?

Will this impact other parts of the business?

How will we measure the success (or failure) of this project?

When developers have mastered the entire framework, they can start working in a targeted manner. Their careful consideration and careful planning will greatly contribute to the success of the project.

There is also a huge incentive effect. Joe Stump summarizes:

Developers often have to figure out the issues behind the tasks themselves, which means they may not really think through the ideas for a given object.

But if responsible, developers will immerse themselves in thinking about this issue, because their work, in particular, depends more on business success.

For example, if I'm a backend developer and you tell me to implement some API endpoints, I need to think about why you need these endpoints.

This highlights the importance of understanding the purpose and mission behind each project:

Purpose: Why are we doing this?

Task: What is the goal? How much is considered completed?

By understanding the purpose and mission, developers become valuable partners in the planning process. They can foresee potential landmines that could be costly to you. In a magazine article, Paul Boag describes the dangers of excluding developers from relevant meetings:

During the heyday of Digg, there was a meeting between Daniel Burka (Digg's chief designer) and Joe Stump (its main developer) regarding a Digg button. Daniel wanted to change its design because from his point of view, the change was minor. But for Joe, he found that this small design would have a big impact on the performance of the site, forcing Digg to upgrade its processing power and server architecture just for such a button.

What you can do

First of all, we should participate responsibly in product, support and engineering planning meetings.

After the meeting, we can create the relevant specification documents needed next.

Managers are not generals and developers are not soldiers

Sometimes, managers act as if the project is a top secret and only provide some "need to know basics."

But this kind of protection doesn’t lead to better code, more popular projects, or increased sales. Don’t leave developers groping in the dark; invite them to participate in overall strategic discussions.