I don’t know if you’ve noticed, but when you walk into various companies, you can always see a few inspiring slogans, and “get things 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 they innovate? Isn’t the main theme of this era learning from mistakes, responding quickly, and iterating rapidly?
However, my experiences in the embedded field over the past year have led me to rethink and realize that “getting things 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 tight integration of software and hardware, difficult to upgrade, and once released, the cost of solving problems is exceptionally high, with more serious consequences. Therefore, “getting things right the first time” becomes a reasonable and necessary goal.
But how do we achieve getting things right the first time? Let’s discuss it through four principles.
In life, we often say, “It’s better not to do it.” In work, I’d like to pass this principle to you; it remains the truth. Simply put: no code, no bugs.
I’m not saying everyone should stop working, but before clarifying the requirements, don’t rush to take action. Think about it, sketching or writing documentation 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 as code, that’s called a bug.
You must learn to refuse requirements. When requirements come in, you need to think about whether they are valuable or reasonable. If the other party cannot clarify the value or provide a reason, then you should refuse. Tell them not to waste your time and the company’s money.
You need to demand clear requirements. When the business side proposes requirements, the BA (Business Analyst) should analyze the details of these requirements clearly; a one-sentence requirement is too vague to work with, and developers should refuse. This is your right. Once you take it on, if a bug appears, it’s your fault.
But you might ask, what if some requirements are vague in the early stages and can only be explored gradually during the process? What should we do then?
Remember, it’s better not to do it; if you don’t write code, there are no bugs! Ask yourself, if the requirements are vague, can the code be vague? Computers can only distinguish between 0s and 1s; they don’t handle ambiguity at all. Therefore, even if the requirements are vague, we cannot write vague code. If code is written under such circumstances, it inevitably turns ambiguous things into definite things, and that’s likely to result in a bug.
The correct approach is that requirements must be clear and not vague. If in the early stages of the product, during the exploratory phase, the BA should propose hypotheses and validate them. Once a hypothesis is proposed, the requirements become clear. We assume this is the case, and the code is developed accordingly, followed by validation and continuous iteration to gradually find better answers.
This method of clarifying requirements through hypotheses is called trial and error. Writing non-ambiguous code based on vague requirements is called a bug; you can feel the difference between the two.
Now that we’ve rejected unnecessary work and clarified vague requirements, what remains is what must be done. The next principle is to do less to make fewer mistakes.
How do we achieve this? Don’t rush to write code; otherwise, you may take many detours before getting it right. Here’s a three-step method to help you take fewer detours, write less code, and make fewer mistakes.
Step One: Run it through your mind. First, mentally rehearse the entire implementation process; this is similar to a virtual simulation run. Think clearly about what each step’s inputs and outputs are, and what the processing process is. This step is crucial; it ensures you truly understand the requirements and can identify potential problems and difficulties in advance.
Step Two: Draw it on paper. Sketch the process you rehearsed in your mind on paper. This process not only helps organize your thoughts but also facilitates communication and discussion with others. Remember, you must draw it out. Sometimes you think you’ve understood, but once you draw it out, you realize you haven’t.
Step Three: Ask someone. After the first two steps, you’ve thoroughly understood the requirements and clarified the implementation plan. Now, find someone to ask. This person should ideally be experienced; they can provide suggestions on your plan and point out aspects you may have overlooked that could affect the original functionality. Even if the other person lacks experience, you should still ask someone. Because while explaining, you might discover some issues yourself.
After this three-step preparation and validation, you can confidently start writing code. At this point, you’ll be calm when facing complex problems, and the probability of making mistakes will significantly decrease.
After all this groundwork, you might think that this isn’t really working; only writing code is real work. In fact, the code you write is incredibly valuable. The value of the product is realized through your lines of code. The previous groundwork is to ensure that you can write good code.
Now you can happily write code. At this time, you should think about how to do less work and let the machine do more work. After all, it’s better not to do it, and doing less means making fewer mistakes.
Let’s not even mention having AI help you write code for now. Think about what tasks during development can be delegated to machines?
Development work can be divided into three main categories: reading code, writing code, and debugging/validation.
Validation is both boring and time-consuming. You set breakpoints, check if the variables are what you expect, and whether the logic jumps correctly. This work is repetitive; sometimes you look up and find everyone around you has left, and a day passes quickly without you pinpointing the problem.
Validation is the easiest part to hand over to machines. You can write validation code (test code) to verify whether the program’s output is correct and whether it meets your expectations. This is a one-time effort. Once the validation code is written, it will tirelessly run repeatedly. You can confidently let it handle the validation work for you. Furthermore, you can even write the validation code first, then the business code; this is known as Test-Driven Development (TDD) in extreme programming.
Machines can also help you with other tasks; all repetitive tasks can be assigned to them. Thus, this third principle, “let the machine do more work,” is also known as automating everything that can be automated.
For example, your software’s building, deployment, and any tasks that can be automated should be handed over to machines. After all, humans are prone to making mistakes.
The first three principles focus on minimizing work, but once work is done, mistakes can occur. Therefore, the final principle is “early error correction, less waste,” focusing on how to detect errors as early as possible and reduce waste.
For product development, the greatest waste is rework. Reworking due to incorrect functionality or quality issues can damage the brand and increase costs.
The later a problem is discovered, the higher the cost. Therefore, we must use all means to correct errors as early as possible. Extreme programming provides a great reference mechanism:
-
Minute and hour-level feedback: through pair programming, automated testing, and pipelines
-
Day-level feedback: daily stand-ups, acceptance testing for each requirement
-
Week-level feedback: showcase for each iteration
-
Month-level feedback: feedback after version releases
（Image from the internet）
If we can establish a multi-dimensional feedback mechanism like extreme programming, from minute to month, we can timely detect problems and correct errors in the early stages, significantly improving work quality and reducing unnecessary waste.
Quality is the lifeline!
Due to the unique characteristics of embedded products, “getting things right the first time” is the pursuit of every developer. By implementing the four principles and establishing a multi-dimensional feedback mechanism as described in this article, you can maximize quality improvement and resource utilization.
