Have you noticed that in various enterprises, there are always a few inspiring slogans, among which “get it right the first time” is definitely a high-frequency term. Every time I saw it in the past, I would think: this company is too dogmatic, what era is it? With zero tolerance for failure, how can we innovate? Isn’t the main theme of this era learning from mistakes, responding quickly, and iterating quickly?
However, my experiences in the embedded field over the past year have made me rethink that “getting it right the first time” is not only a pursuit of work efficiency but also a strict requirement for quality control. This concept is particularly prominent in the field of embedded product development.
Compared to web systems, embedded products have their uniqueness. They are a close integration of hardware and software, not easy to upgrade, and once released, the cost of solving problems is extraordinarily high, with even more serious consequences. Therefore, “getting it right the first time” is a reasonable and necessary goal.
But how can we achieve getting it right the first time? Let’s discuss it from four principles.
Not doing is better
In life, we often say, “not doing is better.” In work, I want to share this principle with you, as it remains true. Simply put: no code, no bugs.
I am not saying that everyone should stop working, but before clarifying the requirements, do not rush to start. Think about it, sketching or writing documents is much easier than directly writing code, right? And the cost is much lower. If you make a mistake, you can redraw or rewrite, but if it’s written in code, that’s a bug.
You need to learn to refuse unclear requirements. When a request comes in, you should consider whether it is valuable or reasonable. If the other party cannot clarify the value or provide a reason, you should refuse. Tell them not to waste your time and the company’s money.
You must require clear requirements. When the business side proposes technical plans or requests, the BA (Business Analyst) must analyze the details of this request. A vague request cannot be processed, and developers should also refuse. This is your right. Once you take it on and there is a bug, it becomes your fault.
But you might ask, what if some requirements are vague from the start and can only be explored during the process? What should we do?
Remember, not doing is better; not writing code means no bugs! Ask yourself, if the requirements are vague, can your code be vague? Show me some vague code. Computers can only distinguish between 0 and 1; they do not handle vagueness.
So even if the requirements are vague, you cannot write vague code. If you have written code, you have likely turned something vague into something definite, which means you probably wrote a bug.
The correct approach is that requirements must be clear and cannot be vague. If you are in the product’s early exploratory stage, then the BA should propose hypotheses for verification. Once a hypothesis is made, the requirements become clear. We assume this is the case, develop the code accordingly, validate it first, and continuously iterate to find better answers.
This method of clarifying requirements through hypotheses is called trial and error. If you write non-vague code based on vague requirements, that’s a bug. You should understand the difference between the two.
Less doing means fewer mistakes
Now that we have refused unnecessary work and clarified vague requirements, what remains is what must be done. The second principle I want to share with you is that less doing means fewer mistakes.
How to achieve this? Do not rush to start writing code; otherwise, you may have to go back and forth, taking many detours to get it right. I will give you a three-step method to help you take fewer detours, write less code, and make fewer mistakes.
Step one, mentally run through it. First, simulate the entire implementation process in your mind, similar to a virtual simulation. You need to think clearly about the input and output at each step and what the processing process is. This step is crucial as it ensures you truly understand the requirements and can identify potential problems and difficulties in advance.
Step two, sketch it out on paper. Draw a sketch of the process you just simulated in your mind. This process not only helps organize your thoughts but also aids in communication and discussion with others. Remember, you must draw it out. Sometimes you think you have understood, but when you draw it, you realize you haven’t thought it through.
Step three, ask someone about it. After the first two steps, you should have a clear understanding of the requirements and the implementation plan. At this point, you need to ask someone about it. This person should ideally be experienced; they can provide suggestions on your plan and point out things you might not have noticed that could affect the original functionality. Even if the other person lacks experience, you should still ask someone. Because while you explain, you may discover some issues yourself.
After this three-step preparation and verification, you can confidently start writing code. At this point, you will be calm when facing complex problems, and the probability of making mistakes will significantly decrease.
Let machines do more work
After all this groundwork, you might think that working well means only writing code is true work. In fact, the code you write is incredibly valuable. The value of the product is realized through your lines of code. The groundwork is to enable you to write good code.
Now you are finally happily writing code. You need to think about how to do less work and let machines do more work. After all, not doing is better, and less doing means fewer mistakes.
Let’s not talk about using AI to help you write code for now. Think about what tasks in your development process can be handed over to machines?
Development work can be divided into three main parts: reading code, writing code, and debugging and verification. Verification is both boring and time-consuming for you. You set breakpoints, checking if the variables are what you expect, and if the logic jumps correctly. This work is repetitive, and sometimes you look up to find that everyone around you has left, and the day has quickly passed without you pinpointing the problem.
Verification is the easiest part to hand over to machines. You can easily write verification code (test code) to check if the program’s output is correct and if it meets your expectations. This is a one-time effort. You only need to write the verification code once; it will tirelessly run repeatedly. You can completely trust it to help you with the verification work. Furthermore, you can even write the verification code first and then the business code, which is the test-driven development (TDD) in extreme programming.
Machines can also help you with other tasks; you can let them handle all repetitive tasks. So this third principle, “let machines do more work,” can also be called “automate everything that can be automated.”
For example, the building and deployment of your software, everything that can be automated should be done by machines. Because humans are prone to making mistakes.
Correct mistakes early, waste less
The first three principles focus on doing less work, but as long as you do work, mistakes may occur. So the final principle is “correct mistakes early, waste less,” which means how to discover mistakes as soon as possible and reduce waste.
For product development, the biggest waste is rework. Rework due to incorrect functionality or quality issues damages the brand and increases costs.
The later the problem is discovered, the higher the cost. Therefore, we must use all means to correct mistakes as early as possible. Extreme programming provides a great reference mechanism:
-
Minute and hourly feedback: through pair programming, automated testing, and pipelines.
-
Daily feedback: daily stand-ups, acceptance testing for each requirement.
-
Weekly feedback: showcase for each iteration.
-
Monthly feedback: feedback after version releases.
If we can establish a multi-dimensional feedback mechanism like that in extreme programming, from minutes to months, we will be able to detect problems early and correct mistakes, significantly improving work quality and reducing unnecessary waste.
Conclusion
Product quality is the lifeline of an enterprise! Due to the unique characteristics of embedded products, pursuing “getting it right the first time” is the goal of every developer. By following the four principles and corresponding practices introduced in this article, and establishing a multi-dimensional feedback mechanism, you can maximize quality improvement and resource utilization.Source: Unknown.
-END-
6 Advanced Application Scenarios of Function Pointers
Should you stop learning microcontrollers just because others advise against it?
Sora is here, are you anxious? What impact does it have on technical engineers?