FAQs: How to Break Down a Technical Task You Don’t Understand? #
Hello, I’m Zheng Ye.
In the “Task Breakdown” module, I focused on testing and explained the principle of task breakdown. I also introduced some best practices to help you better understand the importance of task breakdown and how to break down tasks.
Most students agree with the principle of task breakdown, but they have raised their own questions about specific application scenarios.
In today’s Q&A session, I have selected several typical questions for in-depth discussion.
Question 1: How should I decompose tasks when facing unfamiliar technologies? #
In the article “11 | Learning Task Decomposition from Elon Musk”, a student named pyhhou mentioned:
I would love to hear the teacher’s opinion on how to better decompose tasks in a project that I am not familiar with and is full of unknowns.
And in the article “15 | Practice Together: A Step-by-Step Guide to Task Decomposition”, another student named shniu asked:
I would like to ask the teacher how to decompose tasks for exploratory or research-based requirements.
This is a very good question. In this module, when discussing task decomposition in development, I have been talking about specific technologies that are familiar, such as databases, REST services, etc. Because these are the most common and fundamental capabilities in development, if you can’t even decompose familiar technologies well, it will be even more difficult for unfamiliar ones.
So what if you are unfamiliar with a technology? The answer is simple: turn it into a familiar technology. Once it becomes a familiar technology, you can apply the decomposition strategies for familiar technologies that you have learned in this module.
I know that this answer may not be satisfactory to you. In fact, your real question is, how do you turn it into a familiar technology?
My answer is, do a technology Spike. I use the term “Spike” here because I haven’t found a perfect translation for it. The original meaning of Spike is a gentle sting, and some people translate it as research, but I think that’s too heavy.
The key point of Spike is to try it quickly and it is different from research. Since it is about quick experimentation, it should be completed within a certain period of time, for example, five person-days, which means one week for one person. If it takes longer, it is no longer considered a Spike. For some simple technologies, one day is enough for a Spike.
The key point here is that you need to do a technology Spike. The purpose of Spike is to eliminate uncertainty and let the project manager know that a technology is required that no one in the team understands, and it will take time to figure it out.
The project manager is more concerned about uncertainty than you are. By presenting the problem to him clearly, the project manager can understand it. What he fears the most is that you suddenly tell him halfway through the project that the project timeline needs to be extended.
By dealing with the issues upfront and exposing them as early as possible is exactly what we will discuss in the next module.
So, the next question becomes: how do you do a technology Spike?
Here, I assume that you have gained some subjective understanding of the technology through various channels, such as news websites, technical blogs, or instructions from superiors, and at least you know what this technology is used for.
Next, we need to start decomposing the tasks for a technology Spike.
First, quickly complete the example provided in the tutorial. Most technologies have a tutorial with which you can follow along, and it will usually take no more than half a day. The reason for quickly completing the example is to give you an intuitive understanding. At this point, your understanding of this technology will surpass that of news websites.
Secondly, we need to determine two things: the application scenarios of this technology in the project and our focus points.
Technologies are ultimately applied to projects. Following the “begin with the end in mind” principle, we should work towards the result. The entire Spike should be focused on the ultimate goal.
Many developers get excited when they come across a new technology and tend to read all the documentation. This approach is understandable when it comes to learning a technology, but our goal is to do a Spike, to try it quickly, and we don’t have that much time. We must focus on the results.
There are countless scenarios in a project. We need to select the most important one, and for that particular scenario, we need to choose the most essential features from the numerous features of the technology, instead of “casting a wide net”.
Furthermore, we need to pinpoint our focus points. For example, if we adopt a new cache middleware to improve performance, then performance is our focus point. If we use a new message queue to enhance throughput, then throughput is our focus point. We always have some assumptions when selecting a new technology, but do these assumptions really hold true? This is what we need to verify.
Whether it’s the scenario or the focus point, we need to think it through upfront to prevent divergence. When time is limited, we can only focus on the most important things, which is something I have been emphasizing in this column.
Once you have determined the scenarios and focus points, you should develop a prototype to validate your assumptions about the technology quickly. The main purpose of this prototype is to verify whether your understanding of this technology can meet your assumptions. Developing a prototype that only contains the core features is not difficult for most developers, so I won’t go into detail here.
When you have validated all your ideas, the technology will have changed from an unfamiliar one to a familiar one. This solves the problem we mentioned earlier. At this point, you can decide whether to adopt or abandon this technology.
However, I have one more point to remind you: when you decide to use this technology, please discard your prototype code.
You may say, “But I spent several days working hard on this code, and I have to just throw it away?” Yes, because it is a prototype and you need to redesign it for your project.
If you continue using the prototype, you may not go through the design process, and there will be a lot of code directly dependent on this technology, which is a cause for concern. All third-party technologies need to be isolated. This is what we will discuss in the “Automation” module.
Question 2: What should I do when the project is tight on time? #
In this module, I’ve spent a lot of time talking about testing. Many students recognize the value of testing, but have raised some common situations in development.
Xuanyuan mentioned:
“Many times, projects are tight on time, so often testing is done after development or completely skipped, focusing only on code review.” - —— “12 | Is testing also the responsibility of programmers?”
This is a very typical problem. When I used to do consulting, I often encountered many teams saying they didn’t have time to do testing because the project was tight on time.
There is a common misunderstanding here: confusing goals with the current situation. The goal is what we should do, but the current situation is what we are currently doing. We all know what the current situation is, but are you satisfied with it? If everyone is satisfied with the current situation, then there would be no exploration of better practices.
Assuming you are not busy now, do you know how to improve?
Unfortunately, many people cannot answer this question at all, because busyness is an excuse, an excuse not to think about improvement.
The reason I started this column is to explore some good practices in the industry.
Returning to this specific problem, we have talked in this column about starting with the end in mind. We need to have a goal, and the various practices introduced in the column can serve as references for setting goals. With this goal in mind, we can then consider how to improve in the context of our work.
Next, let’s discuss the specific improvement process using testing as an example. Using the thinking framework we discussed in the column, let’s say our current situation is that the team has not done much automated testing, and our goal is to have 100% test coverage for the business code. To achieve this goal, we need to decompose the task.
In this process, you will find that decomposition mainly needs to address two aspects: communication with people and automated processes.
Communication with people means reaching a consensus with the team. Regarding this, you can try to communicate the various best practices mentioned in the column, as well as the logic behind them, with the team. You can also share the column articles with them.
Next, let’s consider the improvement of automation. Because our current situation is lacking in testing, we cannot expect to achieve it in one step, but rather improve gradually. Below, I have outlined a specific improvement process:
- Integrate test coverage checks into the project and obtain the current test coverage.
- Include test coverage in continuous integration and set the current test coverage as the initial value. No code is allowed to be submitted if the test coverage is not up to standard.
- Increase the test coverage every week, for example by 5% or 10%, until reaching 100% test coverage.
This way, we have found a path from the current situation to the goal. Next, we need to implement it step by step, with team members gradually adding tests to the existing code.
Question 3: What should we do when multiple features are being developed at the same time? #
Nicole mentioned:
It is common for companies to have two requirements being developed simultaneously. How does the teacher’s team deal with the situation where different functionalities are not synchronized on the main branch? - — “Chapter 14 | Secrets of Master Programmers”
In the main branch development model, there are some common methods to solve the problem of parallel development of multiple features. Among them, Feature Toggle is the most commonly used one, which determines which feature is available externally by using switches.
Y024 also shared some additional information on this point.
Two articles about Feature Toggles: - 1. Feature Toggles (aka Feature Flags) - 2. Better Continuous Deployment with Feature Toggles
However, if user stories are well defined, you can quickly complete a complete business requirement. In fact, Feature Toggle is only a very temporary existence. But if you are working on a legacy system and a feature needs to span a long period, Feature Toggle becomes very useful.
Here is an additional commonly used technique related to the main branch development model. If you want to transform a legacy system, the traditional approach is to create a branch.
What can you do on a branch? You can consider using Branch by Abstraction. In short, before making any changes, extract an abstraction and turn the original implementation into an implementation of this abstraction. Then, the transformation process is to provide a new implementation for this abstraction. This approach requires a certain level of design ability, so it can be a challenge for many teams.
Alright, that’s it for today’s Q&A. Please think back, have you encountered similar problems in your work? And how did you solve them? Feel free to share your thoughts in the comments section.
Thank you for reading. If you found this article helpful, please feel free to share it with your friends.