Author: Brother Dong
introduction
Should our time be used to improve software quality, or focus on releasing more valuable features? This seems to be an eternal topic in software development.
- What exactly is quality? What are the qualities of quality?
- What is the relationship between quality and speed? The two are the pros and cons of the same coin. Is it impossible to have both?
- What is the relationship between quality and cost? What does quality mean?
- Also, what about quality and innovation? Does focus on quality stifle innovation?
What is the relationship between technical debt and quality? (Whether technical debt is necessary and whether it is good or bad is not the content of this section, we will discuss this topic in a separate chapter)
What is quality?
Let's talk about the first question first, what is quality. After clarifying the definition, we can discuss the relationship between quality and other matters.
There are many aspects in daily development that are related to software quality: for example, whether the user interface can easily guide users to complete the tasks that need to be completed; another example is the reliability of the software; and whether the architecture is highly cohesive and low-coupling, so that developers can easily modify and publish; and whether the code is clear, easy to read and easy to maintain.
There seem to be a lot of things that can be counted as software quality, so what exactly is quality?
Baidu Encyclopedia query quality, a total of 9 terms, related to software, there are several entries such as management concepts, philosophical definitions, engineering terms, and product terms:
- In the concept of management, the definition of quality is: the degree to which a set of inherent characteristics of an object meet the requirements.
- In quality engineering terms, quality is "the overall characteristics and characteristics of a product or service based on its ability to satisfy stated or implied needs".
- Quality Product Terminology proposes that "product quality is the applicability of the product, that is, the degree to which the product can successfully meet the needs of users when it is used."
- In the philosophical definition of quality, "time, space, and quality are collectively called the three elements of the universe, and quality is the original element of the three elements. Without quality, there is no space, and without space, there is no time. If we adopt the poetic description of Lao Tzu's Tao Te Ching, then there are: protoplasm, quality generates space, space generates time, and time generates all things." (Quality in the philosophical definition is not the same concept as the software quality we discussed, but the three elements of time, space, and quality can actually be used for reference in the software development process, which we will mention later.)
The entry of management in Baidu Encyclopedia is more related to the software quality we are talking about, but it seems that various quality management masters have different understandings of quality:
- Dr. JM Juran, a well-known quality management expert in the United States, put forward that product quality is the applicability of products from the perspective of customers. That is, the degree to which the product successfully meets the user's needs when it is used. The basic requirement of users for products is applicability, and applicability properly expresses the connotation of quality.
- Crosby, an American quality management expert, once summarized quality as "the degree to which a product meets the specified requirements" from the perspective of the producer;
- American quality management master Drucker believes that "quality is to meet needs";
- Feigenbaum, the founder of total quality control, believes that product or service quality refers to the synthesis of various characteristics in marketing, design, manufacturing, and maintenance.
From the definitions of the masters, we can conclude two perspectives to observe the quality of products or software:
- Internal quality: As a process indicator, it focuses more on the internal product function development process, such as the number of defects, code coverage, UT coverage, etc., which is the "producer's perspective" mentioned by Crosby.
- External quality: As a result indicator, focus on whether the functional and non-functional requirements of users are truly met. While meeting the basic demands of users, whether reliability and user experience exceed user expectations is also Juran and Drucker’s point of view.
If software development is to produce products that are valuable to customers, then in order to allow customers to obtain more value continuously, we need to build quality. External quality is directly related to customer recognition of value, and internal quality is for faster, more and more continuous delivery of value.
Internal quality is relatively controllable for producers, and it is also the main body of quality built-in and quality assurance that we often discuss. External quality is perceived by customers/users (this chapter does not distinguish between customers and users, collectively referred to as users). The products we deliver are controllable, but users' expectations of quality are uncontrollable. External quality is the foundation of the existence of product value, and a product without user approval has no meaning in existence behind closed doors. Internal quality should be reflected, and will eventually be reflected in external quality. It is a guarantee factor for external quality and cannot be ignored.
Does internal quality matter?
Users and customers can often see what makes a software product high external quality, but cannot distinguish between high and low internal quality. Users can judge whether they are willing to pay more for more features, easier user interface, because they can evaluate whether these are enough to worth the extra money. But users cannot see the modular structure inside the software, let alone judge whether it is good or bad.
Why pay more for something that doesn't work? So does internal quality really matter? The answer is of course important.
Internal quality and external quality are two aspects of a transaction, external quality is the result, and internal quality is the foundation.
Quality is built-in, Build In Quality, but ultimately needs to be reflected by external quality. If the process guarantee of internal quality affects the result appeal of external quality, and there is a conflict between the two, it is putting the cart before the horse. External quality is visible and perceivable by real users, while internal is the guarantee of external quality, usually called Quality Assurance.
There are two types of external quality for customers, one is satisfied customers will be satisfied, and the other is not satisfied customers will be dissatisfied. Simply speaking, the first category is what we usually call functional requirements; while the second category is what we usually call NFR non-functional requirements. When stability, ease of use, security, performance, etc. cannot be met, customers will be dissatisfied. The second category is actually closely related to the internal quality we talked about, and in fact also affects the external quality.
A common analogy of internal quality is technical debt. Whether it is easy to add features, the additional cost is like paying interest, and clearing obstacles that hinder delivery is like paying back the principal. The benefit of the technical debt metaphor is that it makes it easier to look at internal quality from an economic perspective, as with external quality, we can understand the value of internal quality and the interest that needs to be paid if (more or less) it is missing.
Neglecting internal quality can lead to a rapid accumulation of debt that slows down feature development. Debt cannot be avoided, but through practices such as refactoring, internal quality can be maintained and debt piles kept to a minimum, allowing teams to add features with less effort, time, and cost.
Implementing software development in increasingly complex systems is difficult and failure/failure is inevitable. But technical debt is inevitable, and even the best teams will have bugs in their software. The difference is that good teams not only create far less new debt, but also keep paying down enough historical debt so that they can continue to add features at a rapid pace.
The secret to high performing teams is:
- Mainline development ensures a tight submission and release rhythm, short branches, and small batches of submissions; large batches and low-frequency changes will bring risks to the deployment process. Once a failure/fault occurs, it is very difficult to find the root cause of the problem and restore services. To make matters worse, the deployment can also trigger a cascade of other failures throughout the system, and the time it takes to fully recover from these secondary failures is staggering.
- Continuous integration, in order to minimize integration troubles caused by cross-team collaboration;
- Take the time to create automated tests, test automation has a huge impact on continuous delivery, especially in combination with continuous integration, so that problems can be found quickly and spend less time fixing bugs and releasing live;
- Frequent refactoring to eliminate excess "fat" before it accumulates enough to impede action;
- Through continuous delivery, on-demand delivery to the production environment or customers;
- Take delivery quality and fast feedback on system deployment as the first priority;
- Continuous optimization and improvement.
Products in different stages have different quality requirements
Quality is time-sensitive
Quality is not a fixed concept, it is dynamic, changing and developing with time. The quality will be constantly changing in different periods, constantly enriched, perfected and deepened.
Quality is time-sensitive, it will vary with time, place, and objects of use, and it will be constantly updated and enriched with the development of society and technological progress. Customer needs and expectations are constantly changing and, therefore, quality requirements need to be constantly adjusted.
The process of people using products will put forward certain requirements on product quality, and these requirements are often affected by factors such as time of use, place of use, objects of use, social environment and market competition. Changes in external factors will cause people to have different quality requirements for the same product.
3X model of Kent Beck
During Kent Beck's work at Facebook, he witnessed FB's product and R&D model, which can be said to have subverted his concept of development and quality to a certain extent. Therefore, Kent proposed the 3X model as shown in the figure below.
How is the quality of the innovation phase assessed? Products lacking users and markets are the biggest waste and the biggest quality problem. In the early exploration stage of the product, what is needed is to quickly obtain market feedback, rather than launch a comprehensive product. At this time, the quality measurement should be the speed of feedback and response, rather than stability, ease of use, etc.
In the rapid expansion stage of intermediate products, what is needed is to be able to support the exponential growth of products. At this time, delivery speed, performance, scalability, etc. are the performance of quality.
When it comes to the harvesting stage, what is needed is to maximize the value of the extracted product in a stable manner. At this time, stability, efficiency, safety and other quality factors need to be evaluated.
The quality of external and internal quality directly affects the popularity of products in the market, but in general, the quality focus is determined by the market and external factors, and is not generally measured by a bunch of internal indicators.
Different product stages have different definitions and requirements for quality, as well as different tolerances for quality and risks of failure. We should consider the marginal benefit of quality, that is, the relationship between marginal investment and marginal revenue. Every penny invested should get at least one penny back year-on-year, instead of blindly pursuing high quality and missing market opportunities.
Different customer groups have different definitions of quality
The general view is that the higher the product quality, the better, and the higher the quality, the higher the value, but in fact, this view is not necessarily correct. High-quality products are not necessarily popular in the market. In fact, different audiences have different definitions of quality.
A product needs to have its matching market and crowd, which is described in detail in Trout's "Positioning" theory. Similar to product positioning, there is also a positioning for the extent to which product quality should be controlled, that is, product quality positioning.
Quality is relative. Different customer groups may have different functional requirements for the same product, and may also have different requirements for the same function of the same product. Different needs have different quality requirements. Only products that meet the needs can be considered as good quality products.
The rapid rise of Pinduoduo in recent years is an excellent case. As early as when Pinduoduo was well-known, JD.com conducted research on it, and concluded that it was insufficient. After reviewing Pinduoduo after it was listed, it was discovered that e-commerce giants like JD.com had lost their eyes, and Pinduoduo’s users valued product quality the most. However, Pinduoduo users have a completely different definition of quality than JD.com users. For example, high-quality toilet paper is "three-layered and does not melt when exposed to water", while JD.com users' high-quality paper is "environmentally friendly and bleach-free."
Quality positioning, like product positioning, needs to take into account different markets, different customer groups, acceptance and popularity of product value (including quality), and determine product quality positioning according to actual market demand. The "high quality" in your mind may not be the same as that in other people's minds.
Can't have both quality and speed?
Fast delivery leads to better external quality
Often, business pressures and reasons for departmental performance reviews draw attention to delivering business value. And quality is often easily overlooked until problems arise.
It should be noted that we do not want to make a function to meet customer needs, but to understand what the customer's purpose and intention are. What customers want is not a faster horse or a faster car, but to get from A to B on time. If the distance is thousands of kilometers, an airplane is suitable; if it is hundreds of kilometers, a car is good; if it is tens of kilometers, a car is good; if it is a few kilometers, a bicycle is enough. Therefore, the needs of customers are not generalized, and corresponding products must be provided according to the real purpose.
People often regard quality assurance and quick response to customer needs as a pair of contradictions, and lack the concept of balancing opportunities and risks with customers.
The customer's intention is gradually becoming clear through communication and exploration, which requires us to quickly obtain feedback, constantly clarify, and constantly adjust the product direction through methods and technical means. The customer's purpose is the direction of the product, which is a moving target, and agility is to try to hit the moving target in a curvilinear manner through fast delivery, fast feedback, and fast adjustment.
Therefore, the fast feedback brought by fast delivery is directly related to external quality. Without feedback from external customers, any function or performance is just fishing in the water. Speed can help to better meet the real demands of customers, especially in such an era of UKA.
In the long run, quality is the guarantee of speed
At the same time, writing good software requires some extra effort, which does come at some cost in the short term. However, as discussed in the Technical Debt chapter, internal quality can also be deliberately sacrificed in order to achieve greater speed, if it is beneficial.
Of course, what follows is the lack of code readability, scalability, stability, ease of use, etc., and will be attached to every new function delivery in the future. 1.01^100≈2.705, 0.99^100≈0.366, so in the short term, the internal quality consumes more resources (manpower, material resources, time), but in the long run, it will be an exponential feedback.
Therefore, in the short term, deliberately sacrificing internal quality needs to be able to bring greater economic value, and it needs to outperform the interest on technical debt. But in the long run, the fundamental role of internal quality is to reduce the cost of future changes. Better internal quality makes adding new features easier and therefore faster and cheaper, so internal quality actually brings external benefits as well. High intrinsic quality allows us to deploy 10 times a day and add new features every week, while low intrinsic quality keeps us stuck in red tape. Although it may lag in the early days, soon high-intrinsic-quality software is much more powerful than low-intrinsic-quality products, and all customers will choose the application with more features, even if it costs more (in fact, the price can be lower, because fewer resources are invested).
Improving internal quality is about reducing productivity loss in the long run. This can be seen from Martin Fowler's time-function-quality diagram. With poor internal quality, initial progress was fast, but over time it became increasingly difficult to add new features. Even small changes require programmers to modify a wide range of code; code that is difficult to understand and has a high probability of accidentally breaking when changed, resulting in excessive testing time and additional defects that need to be fixed.
It can also be seen from the schematic that there is a time when low intrinsic mass is more efficient than high intrinsic mass. During this period, there is some kind of trade-off between quality and cost. The question is how long is the period before the two lines cross? According to Martin's illustration, low-quality code can significantly slow down delivery within a few weeks, so trading quality for speed is only suitable for extremely short deadlines.
Speed meets quality
The trade-off (tradeoff) between throughput and stability is a common industry practice, especially in government or highly regulated fields, where organizations prefer to adopt conservative software development and delivery strategies. They assured that releasing code infrequently was an effective strategy. Because then more time can be spent on deployment, testing and QA, and the possibility of failure/failure will be minimized.
In the dual-mode IT model, we discussed whether the division of the steady-state model and the sensitive-state model is applicable to the current IT transformation, and further extended the differences and connections between IT transformation and digital transformation. Jez Humble's point of view is that the dual-mode model is a false proposition, as can be seen from the "DevOps Status Report". The report pointed out that the efficiency of software R&D has a huge impact on the retail industry, followed by financial services. For retail and finance, two industries that we usually think of as very different, the problem is no longer to choose conservative or to pursue excellence. Efficiency is not a question of TO BE OR NOT TO BE, but a must. After all, barbarians have broken into the door and entered the hall.
In fact, both speed and stability can be achieved. The best high-performance organizations can always achieve excellent levels of throughput and stability at the same time, rather than choosing between the two or sacrificing one. According to DORA's "DevOps Status Report", high-performance organizations can achieve both speed and quality. Through built-in quality, automation, and continuous feedback, while enhancing quality, they do not lose short-term speed.
"Elite software teams update production code multiple times a day, pushing code changes from development to production in less than an hour. When they do, their change failure rates are significantly lower than slower organizations, so they can recover from mistakes more quickly."
"We don't have time to write high-quality code, because it takes too long." Peeping effect, scarcity thinking, only staring at those options with higher short-term returns, it is easy to ignore investing in things that are more efficient in the long run.
Quality is free? An economic account for quality
Quality is free, but never free
Crosby's "Quality is Free" is a classic management book, "Quality is not only free, but it is also a real cash cow. Since the work is done right at the beginning, every penny saved without rework will be included in the "profit" column of the accounting statement."
Quality can never be obtained for free, and requires a lot of manpower and material resources. However, the pursuit of quality is the activity with the highest ROI of input and output. The pursuit of quality is speed-multiplier and has a weighting effect in the long run.
Quality is economical
Because the needs of customers are the expression of product value, high quality and low price reflect people's value orientation, and value for money means that quality is economical.
The three elements of time, space and quality in the definition of quality philosophy, the concept of "no quality, no space, no space, no time", can also be applied to software development. The traditional project management triangle of requirements, time, and resources, with implicit quality factors. Requirements are fixed, and resources and time are considered to be variable, but in fact this is not the case, so quality is often sacrificed passively, and developers are actually passively sacrificing quality. In agile development, this model has become an inverted triangle. We admit that resources and time are always limited, so the demand is negotiable, and the demand also reflects the customer's requirements for external quality, which is also related to internal quality, so the quality requirements can change with time, but we are proactive in this process. (Of course, we also need to take the initiative to make up for the short-term quality sacrifice.)
What is suitable is the best, too much is too much, too fast speed and excessive pursuit of quality are also wasteful. Taking SLA as an example, the pursuit of upgrading from 99% to 99.99% requires 10 times or even 100 times of capital and time investment, but for customers, the perception may not be 100 times the improvement, and it may be less than 10%.
Therefore, it is not wise to blindly pursue high quality. Quality is not only related to speed, but also closely related to the risk of error probability. If the result is within the acceptable range, the risk of slightly lower quality can be fully borne.
The attitude of German and Japanese companies to quality from the case of Huawei
Taking Huawei as an example, "In Huawei's view, innovation should be learned from American companies, and quality should be learned from German and Japanese companies." In the process of forming Huawei's "big quality", benchmarking with German and Japanese companies plays a key role.
The characteristics of German enterprises are based on quality standards, using informatization, automation, and intelligence as means, integrating into the whole process of product realization, and committing to building a quality management system that does not depend on people. Germany emphasizes quality standards, paying special attention to the construction of rules, processes and management systems; about 90% of the industry standards issued by Germany are used as models or directly adopted by countries in Europe and other continents. The German quality theory shaped the first half of Huawei's quality evolution process, that is, the quality management system built with processes and standards.
The characteristic of Japanese companies is that they focus on lean production theory to reduce waste and improve efficiency. They believe that poor quality is a waste and a high cost. Japanese companies focus on the quality improvement of "points", pay high attention to the "human" factor, and emphasize employees' autonomy, initiative and continuous improvement. This also helps Huawei gradually form a quality culture of continuous improvement.
Huawei believes that the foundation of a high-quality enterprise is a quality culture. Tools, processes, and methods are "techniques"; culture is "way".
In addition to the eternal theme of customer-centricity, Mr. Ren talked about "quality culture" most, and the focus on quality is precisely the cornerstone of Huawei's continuous innovation in Mr. Ren's view.
The Impact of Digitalization on Quality Workers
As a quality personnel, you have to think about digitalization for the future career development of QA. Digital transformation has a great impact on QA's working methods. In the past, due to the opacity of data, QA was required to provide visibility as a policeman. Since data cannot be automatically obtained and there is no automatic evaluation model, the project team also needs QA to help analyze quality or give quality method guidance. If fully digitized, most of the current QA work can be eliminated.
But in fact, as long as product development is a process, and the natural law of ensuring a good result by building a good process remains unchanged, product development requires quality management, and professionals are required to build a quality management system.
It’s just that in the process of digital transformation, the enabling method of the quality management system has changed. QA should conduct in-depth business analysis of quality issues, summarize excellent practices, extract requirements and methods, embed them into workflows as tools, track their execution effects, and continue to improve. QA has changed from personal services to providing services through quality tools. engineer.
References
- "Is quality software worth the price?" - Martin Fowler
- Baidu Encyclopedia
- "From Accident to Inevitability"