08 Why is it said to analyze before taking action? #

Hello, I’m Zheng Ye.

After the previous lessons, I believe you already have your own understanding of the principle of “starting with the end in mind.” You know that when you receive a task, the first thing to do is not to immediately dive into hard work, but to learn how to think and identify the real goal. Once the goal is clear, can we start executing right away?

Before rushing to provide an answer, let’s start today’s content with a technical task.

A Technical Task #

You are currently working at a company that is doing well. With the continuous development of the business, the relational database that was originally used is becoming increasingly unable to meet the rapid changes. As a result, the project leader has entrusted you with the task of conducting a technical evaluation and migrating part of the business to a more suitable storage solution.

After careful research and consideration, you have proposed your suggestion to the project leader, “Let’s choose MongoDB.” Due to the trust placed in you, the project leader unconditionally agreed to your suggestion, giving you a great sense of achievement.

While you were still in the midst of your joy, the project leader entrusted you with an even more important task - to come up with an alternative plan. Alternative plan? You couldn’t believe your ears and muttered to yourself, “Can’t I just write the content that is currently stored in the database to MongoDB? I will simply replace one table at a time. Do I really need to list out which table to replace on which day?”

The project leader, who had just admired you greatly, suddenly had a serious expression. “Is rewriting the tables the only thing that needs to be done?” he asked. You looked at him in bewilderment, thinking, “What else?”

“What about the deployment plan?” the project leader asked.

“But I haven’t written a single line of code yet,” you innocently replied to the project leader.

“I know you haven’t written the code, let’s just assume that the code is already written and see what the deployment process looks like.”

“Isn’t it just a matter of releasing a new version?” you still didn’t understand what the project leader was trying to say.

“Can you be sure that the new version of the code is correct?”

Although you have been programming for many years, as an experienced programmer, you suddenly felt a bit hesitant upon hearing this. “No,” you admitted honestly.

“Once an error occurs, we can just roll back to the previous version, right?” you still had a conventional approach to handling errors.

“But the data has already been written to a different storage, which will affect the queries, won’t it?” the project leader hit the nail on the head.

“If we adopt a dual-write approach during this stage, even if the new code has problems, the old storage system with the existing code will still be functioning properly, and we will have a chance to roll back.” You quickly came up with a solution, feeling confident that we wouldn’t be afraid of encountering any problems.

“Exactly,” the project leader agreed with your approach, looking like he knew he made the right choice. “I asked you to come up with a deployment plan precisely to think about the details.”

Finally, you understood the project leader’s good intentions and stopped being careless. Soon, you presented a more detailed deployment plan.

You showed the plan to the project leader, feeling confident that you had been careful and taken one step at a time without any issues. However, as the project leader looked at your deployment plan, his brows gradually furrowed, and you realized that he was still not satisfied, although you didn’t know what was missing.

“What about the existing data?” the project leader asked another question. You suddenly realized that it was indeed a problem. “Without the existing data, once a query involves the existing data, the result will be incorrect. So, there should also be a data migration task for the existing data,” you awkwardly chuckled.

The project leader smiled and looked at you. “Alright, from my perspective, it’s almost there. You can think about it more carefully. Then, let’s schedule a development task!”

You would definitely not disappoint the project leader’s trust, so you quickly organized the development tasks.

Looking at the scheduled tasks, you suddenly felt puzzled. You initially just wanted to write a component for reading and writing to the new database, but now there are so many additional tasks. In addition, you wonder why the project leader always manages to find so many issues.

A Personal Review #

You recalled a similar scene in a previous job, where the person in charge also let you independently arrange tasks. Usually, you initially received a simple answer, and from your state of mind at the time, you felt a sense of achievement.

However, the subsequent story was not so wonderful. Various problems often occurred during deployment, and you and your colleagues were busy dealing with various exceptions. The scene of solving problems under immense pressure at that time is still fresh in your memory. When you finished solving the problem and left the company, the sky had already turned pale.

It seems that since joining the current company, there have been fewer scenes of frantic scrambling. You began to carefully reflect on the actions of the person in charge. From the perspective of giving everyone an opportunity, this person is indeed good. They always let a person independently handle a task. However, they ask everyone to show them the results of task decomposition first.

After receiving the development list from anyone on the team, they would ask a series of questions, and most of the time, they would ask questions that leave people speechless. To be honest, every time they persistently questioned you, you felt uncomfortable, just like today.

Originally, the task seemed simple to you, but after a series of questions from them, it turned into a long list of work, and suddenly there was much more to do. After all, who doesn’t want to do less work!

However, you have to admit that after joining this company, you have become more composed in your work. You know that regardless of the task at hand, the basic elements are the same, but the difference lies in whether you are busy beforehand or afterwards. And now, this company falls into the category of being busy beforehand. So, you have started comparing the busy content during deployments at your previous company with the questions the person in charge asks every time.

After organizing your thoughts in this way, you finally realized that the questions the person in charge asks are actually all related to the deployment process. This includes the current question as well, such as what to do when there’s a problem during deployment or how to handle live data, and so on.

You suddenly realized a key point: the questions the person in charge asks are actually always similar. Whether it’s you or someone else, they will be concerned about what the deployment process is like and will provide a deployment plan. Even if we haven’t written a single line of code, they still make us assume what steps should be taken if everything is ready.

You finally understand that the reason why previous projects were chaotic was because at that time, you only considered the functionality and never thought about the deployment. And most of the problems occurred during the deployment process. You remembered when you attended a community event last time, and one of the experts mentioned the phrase “the last mile”.

Thinking of this, you quickly searched the internet for “the last mile”. This phrase refers to completing a task, which is the final and most crucial step. You suddenly realized that “the last mile” has already been applied in many fields, and the person in charge is looking at what will happen from the perspective of “the last mile”.

Hmm, you learned a trick, and from now on, you can also find problems from the perspective of “the last mile”. With the deductive ability you already possess, it seems easier to come up with a more satisfactory task list.

After figuring out this problem, you reorganized your thoughts and outlined your own problem-solving plan.

• Start from the perspective of the desired outcome to see what factors need to be considered for the final deployment.
• Deduce a step-by-step deployment plan, using the previously considered factors as evaluation metrics.
• Based on the deduced deployment plan, summarize the tasks that need to be done.

However, what excites you even more is that you now have a new perspective for problem-solving, allowing yourself to elevate to the level of a senior software engineer.

The Road to Results #

Alright, this little story has come to an end. As users of our column, you may already know that the message conveyed by this story is still “beginning with the end in mind”. We have always emphasized the importance of seeing results, but the path to those results is even more crucial.

There is no shortage of people with lofty ideals in this world. Most people can envision a grand future, but very few actually achieve the corresponding results. The majority are simply lost among the masses.

Having a grand ideal is a goal, but reaching that goal requires taking one step at a time. Tang Sanzang’s goal was to obtain the scriptures, yet it still took him more than ten years to reach the Great Thunderclap Monastery. Tang Sanzang had a great advantage in his journey to the West—he had a clear path to reach his goal. He set out from Chang’an and made his way towards the West.

In contrast, our work often involves a clear goal but a vague path. Therefore, different people have different ways of handling this. Some people move forward without a plan and then figure it out later, while others first deduce the path and see how far they can go.

The differences brought about by these two paths in our software development process have been illustrated in the previous story. One approach leads to enjoyment in the early stages but chaos later on, while the other approach involves careful consideration upfront and then proceeds smoothly throughout. Personally, I advocate for the latter approach.

Perhaps you’ve already noticed that this is what we referred to as the first creation or intellectual creation in the opening of the “beginning with the end in mind” theme. If you don’t remember, you can review it in “02 | Beginning with the End in Mind: How to Make Your Efforts Worthwhile?”.

In fact, people have long been adept at using this way of thinking. In the military, it is referred to as sand table war gaming or sand table simulation. The military uses sand table simulations to reveal problems in strategic and tactical aspects of warfare. This concept has also been borrowed by the business world to train managers at all levels.

This concept is not difficult to understand, and we can easily apply it to many aspects of our work. For example:

• Before developing a product, consider how to promote it, through what means, and to what kind of people.
• Before making technological improvements, consider the process of deployment and prepare contingency plans for potential issues.
• Before designing a product feature, consider who will provide the data and what the complete process looks like.

The last example is also a common occurrence in software development. Many product managers only focus on how the user interface interacts without considering where the data comes from. The result is that the product, which was made with great effort, cannot be fully executed because there is no data source.

Often, all we lack is a little bit of deducing before we start working, so we often rely on our own wit to deal with everything that may happen.

I hope that through today’s sharing, you can break free from the cycle of chaos and make your work more relaxed.

Summary Moment #

Even if we have determined our work goals, we still need to visualize the implementation steps before getting started, completing a mental creation, which is the first creation or intellectual creation. This kind of thinking is called sand table deduction in the military and is widely applied in many fields.

In the software development process, we assume that the software is ready and then consider what needs to be done after it is ready, such as how to go live, how to promote, and so on. This deduction process helps us discover the shortcomings of our preliminary preparations and further enrich our work plan. In order to avoid stumbling at the “last mile,” preliminary deduction is indispensable and is also a prerequisite for bringing the team into an orderly state.

If you remember only one thing from today’s content, please remember this: Before starting something, visualize the implementation steps first.

Finally, I want to ask you to think about what improvements you can discover by visualizing what you are doing. Feel free to write down your thoughts in the comments section.

Thank you for reading. If you find this article helpful, please feel free to share it with your friends.