R&D Efficiency Series - Whether Quality and Speed Can Be Satisfied丨IDCF
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.
Many aspects of daily development are related to software quality: for example, whether the user interface can easily guide users to complete the tasks that need to be done; another example is the reliability of the software; and whether the architecture is highly cohesive and low-coupling, so that developers can easily Modification and release; 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 fulfills 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 definition of quality philosophy, "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 will be no space, and without space, there will be no time. If we adopt the poetic description of Lao Tzu's Tao Te Ching, there will be :
Protoplasm, quality produces space, space produces time, time produces 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, in fact, can 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, more focus is placed on the product function R&D 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, it is Juran and Drucker’s goal to focus on whether the functional and non-functional requirements of users are truly met. While satisfying the basic demands of users, whether reliability and user experience exceed user expectations is also the goal of Juran and Drucker. 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 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 advantage of the metaphor of technical debt is that it makes it easier to look at internal quality from an economic perspective. Like external quality, we can understand the value of internal quality and what we need to pay if it (more or less) is missing Interest.
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 unavoidable, even the best teams will have bugs in their software, the difference is that good teams not only create much less new debt, but also keep paying back 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 batch submissions;
Large-volume, 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 the service.
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 benefits of quality, that is, the relationship between marginal investment and marginal revenue. Every penny invested should earn at least one cent year-on-year. The return of money, rather than 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 the conclusion it came to was that it was unfounded. It was not until Pinduoduo was listed that it was reviewed and found that e-commerce giants such as JD.com actually lost their eyes. , What Pinduoduo users value most is product quality. However, users of Pinduoduo have a completely different definition of quality than users of JD.com. For example, high-quality toilet paper is "three layers, which will not dissolve when exposed to water", while JD.com users' good paper is "environmental protection, no bleach". ".
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. It's about getting from point A to point 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 you may be lagging behind in the early days, soon the software with high intrinsic quality is much more powerful than the product with low intrinsic quality, and then all customers will choose the application with more functions, even if its price is higher (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 points 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 question is no longer to choose conservative or to pursue excellence. It's a question of TO BE OR NOT TO BE, but it must, after all, the barbarians have already broken in 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 errors faster."
"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" The classic book of management, "Quality is not only free, but it is also a real cash cow. Every penny saved because the work is done right in the first place and there is no rework , will be included in the "profit" column in the accounting statements. This view is deeply rooted in the hearts of the people, but it is easier said than done.
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. Quality requirements can change over 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. Take the service level agreement SLA as an example, the pursuit from 99% to 99.99% requires 10 times or even 100 times of capital and time investment, but for customers, the perception may not necessarily be a 100 times improvement, maybe 10 times The feeling of less than %.
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." 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 the way QA works. In the past, due to the opacity of data, QA was required to provide visibility as a police officer. Since data cannot be automatically obtained, 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 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 continuously improve them. QA From the personal service in the past to the provision of services through quality tools, the roadmap for digital transformation is IT first, then automation, followed by big data and AI technology. Applying these technologies to quality assurance and efficiency improvement requires someone to undertake Yes, if the quality robot is QA in the future, then we will be the engineers who make robots in the future.