Author: Xu Xiaobin (Xiaobin)

More than two hundred years ago, there was a great philosopher in Scotland, his name was Adam Smith. Today, people know more about him as an economist, and they all believe that he discovered the magical economic law of the "invisible hand" and his famous "The Wealth of Nations". However, in addition to this book, Smith also published another great work - "The Theory of Moral Sentiments", which is a rare philosophical and literary masterpiece. It is worth mentioning that I think this book can help us understand various problems encountered in contemporary software engineering, and can also help us explore some solutions to such problems.

1. Empathy

The word "empathy" (or "empathy") is popular in modern society. This word is expressed in English as _empathy_. For example, we saw a pair of lovers reunited after a long absence on the street. Let us smile; and when we see someone helpless because of a serious illness, we also feel sad from the bottom of our hearts.

Of course, we empathize with the happiness, sadness, and anger of others, not only because of the emotions shown by this person, but also because we understand his motivation for expressing emotions, and his motivation is reasonable. For example, if someone was accidentally bumped, and angrily took out a knife to stab the person who hit him, then we would never empathize with the anger; but if someone's wife and daughter were Rape, and he took out a knife in anger to stab the criminal who hurt his family. We can all understand and approve of this anger.

Although people have the ability to empathize, the degree of happiness and sadness that can be experienced by others is often very weak compared to their own personal experience. The helplessness and loneliness of a critically ill person, even if a stranger observes on the spot for a long time, can experience the helplessness, probably less than eleven; the ecstasy of a lottery winner, the happiness experience that others can have is also very weak Yes, some may even feel jealous.

As the recipients and performers of emotions, when our emotions such as happiness, sadness, and anger are recognized by the people around us, our happiness will double, our sadness can be alleviated, and our anger can also be recognized. It is justified, and then it is vented.

In Smith's view, the reward and punishment mechanism of society is developed based on the principle of empathy among people in society. When a person, out of good motives, does some behaviors and makes others feel comfortable and happy, then the bystanders can empathize with the comfort and happiness of the beneficiary, and understand the good motives of the beneficiary, then Will agree to reward the benefactor; when a person, out of bad motives, does some behavior and causes others to reap pain and sorrow, then the bystanders will be able to empathize with the victim's pain, and will not agree with the perpetrator's bad behavior motivation, then agree to punish the perpetrator.

Examples of rewards include: a young man passing by a small river sees a child drowning in the water, and out of the motive of saving others, he implements a rescue act. In the end, the child is saved, and the child’s family escapes bad luck. We, as bystanders, will all agree. Give rewards to this young man; in terms of punishment, all crime cases are examples, for example, someone on the side of the road sees the mobile phone in the store, in order to satisfy his own desire, commits the act of stealing, causing damage to the owner of the store, then as a bystander Those of us who steal will agree to punish the thief.

2. Ethics and software development

Based on empathy, people gradually form a consensus on rewards and punishments. Smith believes that the so-called morality is such a consensus (or rules), when the society follows these consensus, the whole society will prosper. And those who cannot form a good consensus, or when the consensus cannot be followed by the society, then the development of the society will go wrong and gradually decline. Smith wrote a century earlier than Darwin, but here we can see the shadow of evolution, that is, for nature (or God), a society that can evolve morality can make this society better adapt to nature and prosper .

In society, when people get along with each other, they should not only consider their own emotions and ignore the joys and sorrows of others. When people consider their own feelings, they must also learn to consider the feelings of others and act in ways that benefit others, so that the entire society can prosper.

Let's go back to the matter of software development. Similarly, a developer cannot only think about himself or the machine. He must learn to consider the feelings of other developers and act in ways that benefit other developers, so that the entire R&D organization can prosper. Many developers mistakenly believe that as long as the software can run, it has nothing to do with the machine and has nothing to do with other people; but everyone only needs to think about how much code they have read and maintained in the past year. The system handed over by others will understand how wrong this idea is. No developer writes software from scratch. In large organizations, developers rely on the intermediate products of other developers to work on a daily basis, and they are also constantly producing intermediate products. These intermediate products include:

Documentation: Describes how the system is designed and describes how the API is used. When the research and development work depends on an existing system, it is necessary to understand the design of the existing system, especially when the system needs to be modified, it is necessary to understand the core model of the design.

Code: Whether using services (and clients) provided by others, using middleware frameworks, or taking over legacy systems. New R&D work requires a deep understanding of these codes. Whether these codes are easy to understand, introduce unnecessary dependencies, and have sufficient test coverage (so they are easy to modify) will greatly affect the efficiency of R&D.

Services: The upper-level business will depend on a large number of lower-level services, especially in the testing phase. The quality and stability of the lower-level services will have a great impact on the efficiency of the testing work. Some lower-level services, such as caching and messaging, are now usually provided by the cloud, and the quality of these services is often relatively high.

When the software intermediate products we use in our daily research and development work are of very high quality, we will sincerely feel gratitude and admiration for the authors of these intermediate products; Then there will be disgust and contempt for the author of the intermediate product from the heart.

And when everyone in the organization, as the author of the intermediate product, can always consider the quality of these documents, codes and services when producing and delivering documents, codes and services, it will have a significant impact on other developers. Then restrain your own behavior, demand yourself with higher quality standards, and expect to gain approval and gratitude from users of intermediate products, rather than disgust and contempt, then this organization has formed a good software development ethics.

3. Postel's Law

There is a perhaps less well-known design principle in computing: Postel's Law (also known as the Robustness principle):

> Be conservative in what you do, be liberal in what you accept from others.

This principle was first described by Jon Postel in the TCP protocol. When computers communicate through the protocol, for the content sent by other computers to themselves, various abnormal and irregular situations must be considered, that is, various abnormalities must be actively digested. Complexity; when you send content to other computers, you must have a strict Spec and strictly abide by the Spec.

Although the scope of Postel's Law is system design, I think that to form an efficient R&D team, the collaboration between people should also follow the same principle. As the author of software intermediate products, each R&D should be responsible for their own products. Provide clear Specs and strictly follow them. Only by "be conservative in what you do", then the efficiency of the R&D work at the top level can be maintained (or even improved), otherwise, the R&D work at the top is like installing light bulbs on a rickety ladder , its low efficiency can be imagined.

4. Ineffectiveness of Software R&D Ethics

In the previous article, I tried to explain that the quality of software intermediate products (including documents, codes and services) is crucial to the overall efficiency of the R&D organization; good software development ethics, or sometimes it is considered a good engineer culture, is Everyone has formed a consensus culture that is proud of delivering high-quality software intermediate products and ashamed of delivering low-quality software intermediate products.

However, in reality, we often see that many organizations fail to form this consensus culture. On the contrary, the system has no clear design documents, does not do code review in order to quickly launch the code, the system does not fully test, the code does not have unit test coverage, and the client provided by others adds a lot of irrelevant dependencies. All kinds of phenomena are common and can be used There are too many bamboos to describe.

When R&D encounters this kind of moral failure of software R&D, they often feel frustrated, powerless or even angry. Some people feel that the R&D environment is harsh, the team is unattractive, and the leadership is incompetent; others think that the work is like this, and although it is not ideal, they accept it silently and get used to it. Trying to change an unsatisfactory status quo, but failing to leave; or becoming numb to the status quo and becoming accustomed to it, seems to be the most common result.

If we think again about Smith's theory of moral formation, we can understand why software development ethics in organizations fail, and the direct reasons for this failure are:

1. The act of producing high-quality software intermediates is not rewarded as it should be.

2. The behavior of producing low-quality software intermediate products is not punished as it should be.

When we discuss software quality with any R&D TL, no TL will tell you that software quality is not important. But we all understand that the key to a matter is not what that person says, but how that person does it. How to do it is specifically reflected in: when the priority of quality and other factors conflicts, how will the TL make a choice; when TL evaluates and promotes the team, whether to use R&D quality as a core assessment index.

In organizations and teams where software development ethics fails, we see without exception: when quality and time conflict, priority is placed on time, and quality is sacrificed; when quality and functional scope conflict At the same time, the priority was put on the expansion of the functional scope, and the quality was sacrificed; when doing performance evaluation, the contribution of R&D in quality was not seriously assessed. Quality contribution is often overlooked when evaluating comprehensively from the perspectives of ability and quality contribution.

I used to think that the problem of software quality and R&D efficiency was a technical problem, because advanced technology was not understood and applied; but I believe everyone can understand my point of view. The core of R&D efficiency is not a technical issue, but a sociological issue, a human issue.

5. What should I do?

Since it is a human problem, we must start with changing human behavior. Here, we must first make quality information transparent, in fact, to allow quality-related behaviors to get due evaluation. Transparency is a prerequisite for reasonable evaluation.

Whether it is agile software development methodology or lean methodology, they all emphasize Build Quality In. This sentence means that quality is built in every process detail, and only the quality of the final software product or the quality of the result is considered. , is not acceptable. Once the process quality is ignored, a lot of rework and a lot of bug fixes will seriously affect the speed of product delivery.

Most organizations today are very concerned about the quality of results, the most typical is the availability of services, customer complaints and so on. This is not a problem in itself, but it is disappointing that few organizations seem to maintain sufficient attention to Build Quality In, the quality of the process, and this information is not clearly and transparently displayed. Therefore, it is necessary to make the process quality transparent. In the software development process, it specifically includes:

The code is fully open: so that the code submitted by each R&D can be seen by others (git blame is a very useful command), and the quality of the code is naturally clear at a glance;
Development documents are fully open (version records are also required): so that the design and thinking of each R&D can be seen by others;
The implementation of the Code Review mechanism allows the code to be carefully reviewed by colleagues before it enters the trunk;
CI Dashboard: Whether there is enough automated unit test coverage, etc., is also transparently displayed.

The transparency of quality information is only the first step, and the second step is to link the transparency of information with the incentive mechanism. This is like, assuming that we can see cars running red lights on the road during the day, but in fact running red lights will not be deducted and fined, then there will always be many people who will continue to run red lights; another example is that we see someone on the road. We all know that he has done the right thing when helping an old man who has fallen to the ground, but when the old man blackmails him instead of thanking him, and no one comes forward to help him prove it, no matter how noble this person is, he will not continue to perform good deeds.

Therefore, the organization must include the software quality contribution of R&D personnel into the core assessment criteria when evaluating performance. But at this time, the question arises again. Is the supervisor capable of evaluating the R&D quality of each R&D team? Or, does the supervisor care about the R&D quality of each R&D?

The first point I want to express is: One of the core responsibilities of a supervisor should be to care about the quality of R&D, because this determines the efficiency of R&D of the organization. A supervisor who does not care about this is incompetent.

The second point I want to express is: the supervisor may not be able to comprehensively evaluate the R&D quality of each R&D of the team, because after some teams become larger, the supervisor will be powerless to grasp the details, but at this time he can do two things. things:

Transparent, transparent, transparent: Make quality information across teams, and across teams, visible to all.
Introduce the EIA mechanism: Let those R&D students with senior technical skills and excellent quality participate in the evaluation together in the team or across teams.

It is one of the core responsibilities of managers to continuously stimulate the behavior that the organization needs and oppose or even punish the behavior that is harmful to the organization. As a manager of a software R&D team, one must be able to deeply understand behaviors that are beneficial and harmful to software R&D, and then establish a long-term mechanism in the team. Ultimately, an environment where research and development is full of happiness and can fully release one's creativity is established. Such an organization must also be full of competitiveness in business.

The above is what Adam Smith inspired me, which I call " the moral sentiment of software development ".

The Moral Sentiment of Software Development

1. Empathy

2. Ethics and software development

3. Postel's Law

4. Ineffectiveness of Software R&D Ethics

5. What should I do?

further reading

Guess you like