The Underlying Logic of Software R & D Effectiveness

Image Source: Genicsolutions

In the last two years, software development effectiveness has been viral. Still, whenever something is going viral, it is easy to lose your mind, and more people are led into a misunderstanding. It is like Agile and DevOps in the past, which put all the good things into their basket. Whether Agile and DevOps exist or not, many excellent practices have existed for a long time. Once upon a time, IBM RUP also wanted to dominate this area. Is it still there Today?

Over the past 20 years, how many Scrum Agile coaches have come one after another, but how effective is the implementation of Scrum Agile Development Mode in China? The effect is average. According to the survey data of last year and this year, only about 28% of organizations have implemented Scrum Agile Development Mode, and it is estimated that some are fake agile.

Before the software R&D effectiveness make people go crazy, I think it is necessary to talk to you about the underlying logic of software R&D Effectiveness, to see the essence of software R&D Effectiveness, to clarify the rights and wrongs of software R&D Effectiveness, which is conducive to improving the efficiency of software R & D and helping the software R & D team make a sound R & D plan for the future.

1. What is R&D Effectiveness?

What is R&D Effectiveness? Wikipedia defines "efficacy" as the ability of something to produce efficacy, which is often used in general education, medicine and pharmacology and can be ignored. Then look at Baidu's definition, which is reliable: efficacy refers to the practical, collective effect, that is, the efficiency and effectiveness of people in purposeful, organized activities, which reflects the correctness of the choice of activities' objectives carried out and the extent to which they are achieved.

PwC explains that "organizational effectiveness focuses on organizational efficiency, competitiveness, and employee contribution," and Google's GSM (Goals-Signals-Metrics) framework focuses on goal achievement and translates into five core elements of R&D effectiveness: code quality, engineer focus, intellectual complexity, speed, and speed, and satisfaction. Google's GSM (GoalsSignals-Metrics) framework focuses on goal achievement and translates into five core elements of R&D effectiveness: code quality, engineer attention, intellectual complexity, velocity and speed, and satisfaction.

It is meaningless to argue with each other when the concepts are different. R&D Effectiveness refers to the output of the R&D team that has actual value to the business. If we need to add restrictions, we can say that effectiveness is the per capita output of the R&D team that has actual value to the business per unit of time. At the same time, efficiency focuses on speed and productivity and lacks concern about the correctness of target selection and output value.

Suppose you consider that the business environment is changing relatively quickly. In that case, you also need to consider whether R&D can adapt to changes in the environment, keep up with the times, and maintain a stable and valuable delivery, that is, what we often call sustainable development or progress. This is related to R&D effectiveness but is a separate issue and is just one important factor that affects R&D effectiveness.

R & D efficiency emphasizes efficiency and effect, correctness, competitiveness, and contribution to enterprise benefits. There is no doubt that we pay great attention to R & D efficiency.

2. How to Implement R&D Effectiveness?

This requires a discussion of the underlying logic of R&D effectiveness, so what is the underlying logic?

Back to the previous definition, it is to have higher output, and the higher the output value, the better. The faster and more efficient the production to ensure the right goal, the better. You can continuously improve efficiency through built-in quality (such as reducing complexity and improving code quality), keeping employees highly focused, etc. In this way, we can conclude that the underlying logic of R & D efficiency is: do the right thing, do it correctly, and then pursue speed. But these three layers of logic all depend on people, who are the decisive factors. Therefore, the first logic of R & D effectiveness is to select the right people and cultivate them well.

Based on this logic, the implementation of R&D effectiveness can be divided into four levels.

• Selecting the right people and training them well, such as reviewing the company's recruitment process, training, and performance appraisal systems.
• Doing the right things, such as clarifying business strategy and defining issues, business needs, and user requirements.
• Doing things correctly: identifying/choosing the suitable development model and developing an effective organizational structure and process.
• Pursuing speed/efficiency, such as continuously improving the skills of R&D staff, developing/purchasing R&D platforms, building DevOps toolchains, and achieving a high degree of automation (including build, deployment, testing, and O&M).

There is one more step here than "Putting the Elephant in the Fridge," but luckily, it is still more accessible for people to remember and easier to implement. It's much better than a book I recently criticized, " 201 Principles of Software Development", which, as netizens say, if there are too many principles, there will be no principles. When you open the book, you will find that some of the principles do not make sense, such as：

• Principle 4 High-quality software is achievable (we've known this for a long time, but the reason we don't want to do it now is that it's too costly)
• Principle 8 communicating with customers/users (which team does not go to communicate with customers/users? An action does not fit the principle, and the principle should have a clear attitude that tells us what to do and what not to do, such as the need to communicate with customers/users face to face and maintain daily communication with customers/users)
• Principle 34 all software documents should be indexed (not necessarily. Today, there is a full-text search function or draw a mind map, as long as there are keywords, but not indexes)
• Principle 44 determining subsets
• ...

3. The Underlying Logic Layer 1: Solve the Problem of People

You are not impressed and even disagree with this point if I write that talents are the deciding factor for R & D effectiveness. So I have to say that people dig out requirements, people also do design, people also write code, people also do testing... The process is also developed by people, which also needs people to implement, tools also need people to develop and use, and directors and managers are also people ... At this point, you should recognize: The R& D effectiveness of the underlying logic of the first layer is to solve the problem of how the company selects the right talent and trains them well, right?

I listened to a live program discussing R & D efficiency online yesterday. There are two impressive points:

• Listeners are eager for metrics and want to know how to measure effectiveness;
• A guest said that some companies treat their employees as tools rather than human beings.

First, let's discuss the second point: some companies treat their employees as tools rather than human beings. They require employees to do as they are told and comply with the process and work discipline. This will lead to employees only working all day, lacking thinking, and no room for innovation and development. Secondly, some companies also have other problems, such as the recruitment process being too rough and simple, lack of induction training, and the performance appraisal only focusing on KPI indicators. They did not put "recruiting the right people" and "cultivating people" first.

The company can learn from Amazon if it wants to recruit the right talents. In the previous article, What Skills of Candidates Do the Amazon QA/ TEST Engineer Interviews? There is a detailed introduction. For example, it takes 5 to 6 links (not too many) to recruit a person. One of the links is quite remarkable: setting up a Bar raiser. Bar raisers are a group of evaluators who are elites in various positions. They have the right to vote on whether the candidates are hired or not to ensure that Amazon can recruit excellent talents. However, it is famous for domestic companies that different people decide each recruitment process. This is very easy for some unqualified people into the company/team. Because the hiring department is generally short of employees and then to recruit people, and often because the task is urgent for someone to do, they relax the standards, lower the requirements, and let unqualified people enter their team. Even some team leaders are afraid that people who are more powerful than themselves will come in and steal their positions, so the level of the recruited people will be lower than theirs.

We must pay close attention to cultivating good organizational culture and personnel skills (including talent planning and establishing a training system and curriculum, although 70% of them study at work), and we should never slacken off. One of Microsoft's visions is to help employees give full play to their potential. Microsoft has a set of good competency-building and evaluation systems, as shown in the following illustration.

4. The Underlying Logic Layer 2: Doing the Right Thing

Doing the right thing, that is, in the right direction, and what you do is valuable. It is equivalent to adding 1 in front of 000...000. We need to achieve the goal of adding more 0 in the 3rd layer and the 4th layer of R & D effectiveness, but without this 1, no matter how fast you do it and make continuous improvement, it is still 0. At the same time, If you do the right thing, you will reduce rework, improve efficiency and reduce costs.

Based on the correct understanding of software R & D, we know that development requirements are the source and input of R & D. Therefore, it is imperative "whether the development requirements are correctly defined." The higher the value of development requirements to customers, the higher the development efficiency, which is in line with our usual emphasis on prioritization of needs and planning our release plans according to this priority. However, the priority here does not depend on whether a single business person has a commanding personality or whether he asks you to finish things quickly, nor does it depend on which customer is speaking loudly aggressively or not, but depends on whether the customer/user's problems are solved in place and worthy of priority. If the R&D team is independent and the requirements come from the business department or the customer, there is no room for manoeuvring. Then at this logic layer, the R & D efficiency depends on the quality of architecture design and code, which means making the right architecture design and writing the correct code, that is, the built-in quality we often emphasize.

If you want to do the right thing, traditional fields have good practices and methods. But you may feel it is unsuitable for software R & D. No problem. There are also good practices in Software R & D. At least I think three practices are feasible and effective:

• ATDD (Acceptance Test Driven Development) clarifies requirements by specifying acceptance criteria for requirements, allowing business, product, R&D, testing, etc., to reach consensus.
• Amazon's reverse work method, as shown in the following illustration, has only three steps and is easy to remember and implement.
• The R&D process forms a closed loop, doing log analysis in real-time, getting timely feedback from customers, and sending it to the next iteration for input.

It's simpler and more accessible than telling you a set of requirements engineering. If you still can't do it right, you must learn requirements engineering.

（Amazon's reverse work method）

5. The Underlying Logic Layer 3: Doing Things in the Right Way

This goes back to point 1 of what was said earlier, "The listeners are eager for metrics and want to know how to measure effectiveness.

Many companies are like this listener. When they think about R & D effectiveness, the first thing they think about is to focus on R & D effectiveness measurement and hurry to determine measurement indicators. The second thing they think about is building an R & D effectiveness platform and a DevOps toolchain. They forget that "people are the decisive factor" and "clear business objectives first." Measurement and toolchains are both means, not goals. We need to be clear about what the business goals of R&D effectiveness are, and then we need to know what the obstacles are and where the problems are to achieve these goals, and then we can figure out how to remove the barriers and solve the problems.

Doing things right, as mentioned above, includes choosing a suitable development model, developing an effective process, etc. We should not use Scrum because others use it, but analyze the main problems in our own R&D (process), how to solve them, whether there is a ready-made framework to solve them, and whether they need to be improved or changed.

(Whether the method is correct, this picture can arouse your thinking)

Doing things correctly means solving problems with a systems engineering approach, good systematic thinking, structured thinking, and also going through the basic process of problem analysis and solution such as "goal setting - problem analysis - solution design - evaluation index establishment - multiple solution evaluation - choosing the best solution." If you want to study Guide to the Systems Engineering Body of Knowledge, there are 1100+ pages, and I guess you don't have time.

(System engineering method）

The method is superior to the tool, and the tool is the solidification of the method. We need to develop suitable methods before developing easy-to-use and efficient tools. For example, Google's R & D efficiency has only three primary technical measures:

• Using a monolithic repository (manage most of the company's codes);
• Using the efficient declarative definition, Bazel builds that support accurate testing;
• Trunk-based development.

Although the software system is very complex, it is often caused by our failure to do things correctly. If it is a legacy system and there is not much good way to do it, we can refactor it slowly, or if the old system does not move, we will rewrite a new one. In the future, we need to think all the time:

• High cohesion and low coupling.
• Design/programming for reliability.
• Design/programming for performance.
• Design for flexibility.
• Letting others understand code is more important than writing code.

Then there is always the right way to do things. Moreover, humans have 53 years of software engineering experience and lessons (although human beings have amnesia) and the accumulation of thousands of people working in software development. Many excellent practices can be tried, and most of the work has excellent practice references instead of relying on their inventions and creations, let alone constantly digging and filling holes.

6. The Underlying Logic Layer 4: Pursuing Speed/Efficiency

If you recruit the right people and train them well, you can almost do the right things and do things correctly.

If it doesn't work, some ideas and methods are mentioned above for reference. Achieving "doing the right thing, doing things correctly," the effectiveness has been very high. Of course, we are not satisfied. We need to improve the effectiveness of research and development continuously. At this time, the following three things need to be done：

• Implement R&D effectiveness metrics;
• Continuously improve the process, and the closed-loop feedback cycle becomes shorter and more accurate;
• We need to continue technological innovation or introduce new technologies (such as AI technology) and improve the R & D platform and DevOps toolchain, which may include the process of "curing, breaking, curing again, breaking again."

Suppose we use the language of the underlying logic. In that case, it can be summed up in one phrase - continuous reflection, continuous innovation, and continuous improvement - the goal is to ensure organizational consistency, do the right things consistently, do things right, and produce the flywheel effect.