As a software developer, you spend most of your time delivering code and then fixing bugs you introduced in your code. The Pareto principle is a great way to represent our day-to-day life:
But let’s face it, fixing bugs is not the best part of the job. After fixing it, you may wonder how you can prevent future occurrences from happening.
At Hokla, we design and build medical devices for our clients. Thus, quality management is at the heart of our work. That is why, we pay particular attention to the way we manage our bugs. We added an extra step in our bug management process: take a step back, analyse, and find a poka-yoke to kill the bug forever. A poka-yoke, what? Read this article and find out.
In two words, the key points of the Lean methodology:
The Lean methodology is a systematic approach to identify and eliminate waste within a process. It originated in the manufacturing industry and was developed by the Toyota Motor Corporation. It has since been applied to a variety of industries, including software development and healthcare.
The aim of the Lean methodology is to create a highly efficient and effective process that delivers maximum value to the customer with minimal waste. This is achieved through a focus on continuous improvement, collaboration, and the elimination of non-value-added activities.
Lean methodology has been widely adopted and adapted by organizations around the world, Facebook or Nike to name but two. It has proven its effectiveness in reducing waste and improving processes, leading to increased efficiency, higher quality, and lower costs. Its success has been demonstrated countless of times through its application. Here, it gives us tools to better manage our code quality.
So what’s a poka-yoke in all that ?
Poka-yoke is a Japanese term which means "mistake-proofing". It is a quality control technique used to eliminate or minimize the occurrence of errors in a manufacturing or business process.
The goal of poka-yoke is to make it impossible or very difficult for an operator to make a mistake, so that errors are prevented before they occur. It helps to create a safer and more efficient working environment.
A very simple example is the USB drive: how it is manufactured means that the user can only insert in one way.
What’s our bug process management ? Our bug process management puts into practice the methodology (when in doubt, always refer to the methodology :) ).
→ A bug is reported.
→ A developer investigates the bug and finds a way to fix it.
→ Afterwards, the real work begins. It’s time to shine: the developer does a QRQC.
What is a QRQC ?
QRQC stands for “Quick Response Quality Control”. It is a concept inspired by the Lean methodology. Briefly, the idea is to look at the reality of the field and to react quickly when an issue occurs. It combines two control response speeds:
a quick response, to put out the fire. a long term response, the one we want!
And now, let me explain how we took this concept and made it our own.
Let’s go through an example! To give you some context, I am working on an app which takes part in the digitalisation of clinical trials. A patient enrolled in a clinical trial uses the app to provide data to researchers.
Requirement: The example is specific to redux and redux saga . It is better to have knowledge on how redux and saga work. However, the article aims at going through the QRQC steps, so this is the most important thing to understand.
1) Problem
The app has two modes: one of them available only when the user is at the hospital, “hospitalMode”.
The problem we encountered is that the screen is flickering when the user leaves the hospital mode.
2) Code which introduced the defect
Saga allows to manage Redux side effects. Here, it is used to dispatch several actions to update the redux store when the user leaves the hospital mode. The way Redux is implemented, when an action is caught and a prop changed, it returns a copy of the whole store. Here, each action updates a different part of the store, which leads to multiple re-renders.
3) Code which fixes the defect
Redux documentation gives the solution which is to “batch” the actions to avoid unnecessary re-renders. With batching, the updates on the store are grouped and the updated store is only returned once. It can be done only if the actions are independent from one another.
4) What is the main reason why the defect occurred?
After each action, the redux state is updated and returned, leading the components to re-render. The successive updates cause the app to be in an invalid state → it is visible because of the screen style ⇒ the background color is different in the two modes, it switches back and forth between the two.
5) What is the incorrect gesture/conception that raised the issue?
Poor knowledge on redux sagas good practices and especially on how to update the redux store properly. (If you’re interested, the redux guide: Redux Good practices ).
6) What is the main reason why the defect had not been detected earlier?
It is not a functional error so it is hard to detect.
7) Countermeasures
A quick response is to train the software engineering team on redux saga good practices. Should we stop here ? Two months after the training, the bug will likely reoccur, why? Developers are humans, and humans make mistakes.
The long term solution we implemented is an ESLint rule. We created a rule which checks when two “yield put” are called next to each other. It informs with a warning the developer that they should batch actions if possible. This is a poka-yoke, that’s how you kill a bug forever!
Find our custom ESLint rules on the hokla-org GitHub!
Conclusion All in all, a QRQC is a framework which allows the developer to analyse bugs. The effectiveness of the method has been proven countless of time. Besides, if done correctly, a QRQC is useful to report and share your work to others.
Keep in mind that to implement a more sustainable solution, a great (and powerful) tool is to create your own custom ESLint rule. Even though, doing a technical training is highly recommended, it is not what will kill the bug forever.
What about you, are you ready to tackle bugs forever ?
If you want to learn about another lesson drawn from a QRQC, check out this article .
