11 Learn Task Decomposition From Elon Musk

Lesson 11: Learn Task Decomposition from Elon Musk #

Hello, I’m Zheng Ye.

This time, let’s start with a grand topic: how many civilizations similar to ours exist in the Milky Way. I think that even though the main readers of this column are programmers, who are generally a highly intelligent group, most people wouldn’t know where to start when faced with such a question.

Allow me to provide some popular science knowledge and introduce the Drake Equation, which was proposed by American astronomer Frank Drake in the 1960s. This equation is used to estimate the “number of advanced extraterrestrial civilizations in the Milky Way that could potentially make contact with us”.

Now, I will present the Drake Equation. It doesn’t matter if you don’t understand it at all, because I have no intention of explaining the details. Let’s all experience it together.

Drake Equation

I don’t know what you think after seeing the Drake Equation, but for scientists, the greatest achievement of the Drake Equation is that: it decomposes a previously vague problem into several answerable questions.

With the advancement of observation methods, our understanding of the universe is increasing. Most of the values in the equation can be estimated. With these factors, people can estimate the number of civilizations in the Milky Way that can communicate with us.

Although different estimations may vary greatly, and so far we have not been able to find any extraterrestrial civilization to contact, this equation has given us a direction, a means to try to solve the problem.

Well, I don’t intend to turn this column into a popular science one. The reason I am explaining the Drake Equation is because it embodies an important idea: task decomposition.

Through task decomposition, a complex problem, even one that seems completely clueless, gradually finds a direction towards the answer. And “task decomposition” is the topic of our second module in the column.

Task Decomposition by Musk #

If you are unfamiliar with the Drake Equation, let’s take a look at how an IT professional uses the concept of task decomposition to solve problems.

We all know Elon Musk, the founder of Tesla, an electric car company, and SpaceX, a space exploration company. SpaceX has a goal of sending one million people to Mars.

The U.S. government has calculated that it would cost $10 billion to send one person to Mars with existing technology. So if we calculate the cost of achieving Musk’s goal of sending one million people to Mars, it would be $10 trillion. What does this mean? This amount of money is equivalent to 500 years of U.S. GDP, which is too expensive, even for the U.S. government.

How did Musk solve this problem? He changed his goal and planned to reduce the cost per person to $500,000. In other words, someone who wants to immigrate to Mars could sell their house on Earth to raise the money. Originally, it would cost $10 billion, but now it needs to be reduced by a factor of 20,000.

Of course, reducing it by a factor of 20,000 is still a distant goal. So here’s the main point we’re focusing on: Musk’s second step is to break down the factor of 20,000 into 20 × 10 × 100. This is a simple mathematical problem and the direction of Musk’s three key efforts.

Let’s start with “20”: The current Mars spacecraft can only carry 5 people at a time, so Musk plans to build bigger rockets that can carry 100 people at a time. This would reduce the cost by a factor of 20. If you follow the news, you will see that SpaceX is indeed making efforts in this direction.

Now let’s look at “10”: Musk believes that his company, being private, is more efficient and can reduce costs to one-tenth. They are also working towards this goal, and SpaceX’s costs have already been reduced to one-fifth of its peers.

What about the last “100”? It refers to the reusability of rockets. If this goal can be achieved, the cost of launching rockets would only be the cost of fuel. This is also why we frequently see news about SpaceX test flying rockets.

By looking at these factors, don’t you think Musk’s goal is not as unrealistic as it initially sounded? By decomposing a grand goal into smaller tasks, Musk is able to push forward what initially seemed like an unachievable target.

Task Decomposition in Software Development #

Alright, I’m sharing these two examples with you just to warm up and show that the solutions humans come up with for problem-solving are quite similar. When faced with a complex problem, one of our main approaches to problem-solving is to break it down.

We are not very good at answering a big problem, but we excel at answering smaller ones. So, when we learn to decompose a problem, we take a big step towards solving it.

The most familiar example of decomposition is probably using it in algorithms, such as merge sort. We divide the elements to be sorted into two sub-sets of roughly the same size. Then, we sort each sub-set separately, and finally merge the two sorted sub-sets together.

When it comes to technology, we feel much more secure. It turns out that regardless of whether we are searching for aliens or working on Elon Musk’s famous space exploration program, the approaches we use to solve problems are quite similar! And it’s true.

So, what are the challenges of solving problems using this approach? Provide an executable decomposition.

In the first two examples, when we first heard about the problems to be solved, I guess you were just as clueless as I was. But once we know the result of the decomposition, we immediately get the feeling of “a glimmer of hope in the darkness”. You might think, if I had come up with this answer, I could have built a SpaceX too.

However, when it comes to merge sort, you might feel a bit disdainful because it’s a student-level problem that doesn’t deserve much brainpower to consider. Because you already know the answer to merge sort, you will subconsciously underestimate it.

Task decomposition is such an interesting idea. Once the decomposition result is obtained and executable steps are taken, the subsequent work, even if not smooth sailing, is much smoother than before because the scale of the problem has become smaller.

In our daily work, we encounter many problems that are neither as grand as the first two examples nor as small as merge sort. However, many times, we forget to apply the concept of task decomposition to our work, which causes a lot of trouble.

Let’s take an example: There is a classic joke about programmers: “The job is already 80% done, but the remaining 20% will take the same amount of time as the first 80%.”

One important reason for the significant difference in our estimates lies in not decomposing the tasks well, so we don’t really know how much work needs to be done.

In the article “Why Should We Reason Before Taking Action?”, I mentioned sandbox simulations, which is also a good example. The process of sandbox simulation is a process of task decomposition. If you start working without proper decomposition, you’ll likely miss some tasks. You’ll find that in order to do the work completely, you still have to do the tasks you missed, one way or another.

Contrary to many practices, task decomposition is a process that is difficult to understand but relatively easy to act upon. Knowing how to decompose is difficult, but once you know, the action becomes relatively easier.

Under the theme of “task decomposition,” I will also introduce you to some practices that will let you know that the underlying idea of these best practices is task decomposition. Even if you are not familiar with these practices, you need to know that in more scenarios, breaking down tasks before taking action is a wise approach.

You may say, “Task decomposition is not difficult to understand, and I do decompose tasks in the process of problem-solving.” But still, “I’m not doing so well in life.” This brings us to the difficult part I mentioned earlier, which many people may overlook: executability.

The definition of executability varies for each person. For Musk, he decomposes 20,000 into 20x10x100, and the remaining tasks become executable for him. However, if you work at SpaceX, you must answer how each part is executed.

Similarly, let’s say we are creating a web page. If you are an experienced frontend engineer, you might even think that this task does not need to be decomposed; at most, it’s just an additional task of retrieving web resources.

But if I were a beginner, I would have to decompose the task into several steps: writing HTML based on content, writing page styles based on page prototypes, writing page logic based on interaction effects, and so on.

The difference in executability lies in whether you can clearly know how to solve the problem.

For Musk, his solution might be to start a company and find experts in the field to help him achieve his goal. For your daily work, you need to have a clear understanding of each specific step. If you can’t, it means the task needs further decomposition.

For example, if you need to store information, assuming you are using a relational database, for most people, the task decomposition is at an executable level. But if your project uses a new type of database, such as a graph database, your task decomposition might include learning the model of this database and then designing a storage scheme based on the model.

However, in actual work, most people overestimate their own granularity of work and underestimate the degree of task decomposition. In other words, if you haven’t practiced task decomposition, most of the tasks you decompose will have larger granularity.

Only when you break tasks down into very small pieces can you have a clearer understanding of your execution ability. True experts have strong decomposition skills. This difference is like observing an object using your eyes while the expert uses a microscope. To you, it seems like the expert is performing micro-operations. We’ll discuss this topic in detail further on.

Once the tasks are decomposed into small parts, adjustments become easier. Many people say that plans cannot keep up with changes, and the real reason is that the granularity of the plan is too large and cannot be adjusted.

From the waterfall model of the past to today’s iterative model, it is essentially reducing the granularity of delivery at once. Adjusting the plan every few weeks eliminates the situation of “the plan cannot keep up with the changes” because my plan keeps changing.

Today, the software industry advocates embracing change, and task decomposition is the prerequisite for embracing change.

Summary #

We started with exploring aliens and Musk’s Mars exploration, introducing the application of task decomposition in various aspects of human society, and introducing the basic solution of divide and conquer to complex problems. Then, I told you about a common application of this idea in the field of software development, the divide and conquer algorithm.

Although we are familiar with this idea, we do not apply it well in our daily work, which also leaves a lot of room for improvement for most people’s work. The difficulty of applying this idea lies in providing an executable decomposition.

On the one hand, for complex tasks, providing a decomposition is a huge challenge; on the other hand, facing daily work, what people are more likely to overlook is that the decomposed tasks should be executable. Everyone has different understandings of executability, as long as you know clearly how the next task should be done, the task decomposition can come to an end.

Most people have insufficient understanding of the granularity of executability, underestimating the degree of task decomposition. To achieve good decomposition, you need to reach the level of “micro-operations”. With tasks decomposed into small units, we can easily complete a development cycle, which makes it possible to adjust the plan. The software industry advocates embracing change, and task decomposition is a prerequisite for embracing change.

If there’s only one thing you remember from today’s content, please remember: Before starting to work on a task, please decompose it first.

Finally, I would like you to think about how you have solved problems in your actual work by relying on task decomposition. Feel free to write down your thoughts in the comments.

Thank you for reading, and if you found this article helpful, feel free to share it with your friends.