Don't make things simple.

"You have complicated things !" This is what many bosses like to say, and you may have heard of it. Yes, we should try our best to make things simpler, but the process of making things simpler must be simple. For example, it is difficult to invent a tool that is simpler than scissors. However, sometimes people like to adjust the locations of some adjectives to suit their "needs ". For example, we should try to make things change as simple as possible.

 

Here is a specific example: Code Review ).

 

Everyone who has done this should know that this is a very boring thing, especially if you need to persevere. This situation is even more obvious in teams that are not used to this process, because every participant will feel very painful in the short term, but will not find any effect. How do you implement this reform?

 

There is a very simple way to find someone to take charge of this thing: Well, it will be handed over to you. Specifically, this person may review others' code day by day, or urge everyone to do it day by day. This approach is actually convenient for yourself and suffering from others. It is easy for you to make such a decision, and the responsibility is pushed to the net, it is easy to report. However, the result must be as follows:

1. It is very painful to be responsible;

2. If you think someone cares about it, you don't care about it anymore, or at least you don't care about it;

3. It is difficult for others to cooperate;

4. At first, there was a "effect", and then there was no news, or it fell into a form;

5. Some people began to criticize the formal "Code Review", which was ineffective, wasted effort, and finally canceled.

If we try our best to think about this problem, we will find that the above "simple solution" psychological game design is basically wrong:

1. You have punished the person in charge;

2. What are the punishments for those who fail to complete the review or those who have completed the review;

3. What are the punishments for persons who have not set a review issue, or those who have not reviewed the issue.

 

Under such a game condition, the code writer will eventually not care about what he writes, but the reviewer will not care about the review. In the end, the owner will find that he is responsible for failing to perform the review, very painful. Some people will say that the good companies have not seen any of these Rules. Isn't they doing well? Well, I'm going to tell a very famous story. Maybe many people have heard of it:

 

In a big city with a lot of life pressure, people are very busy at work and often get off work very late. The Dean of a kindergarten was very upset because the parents had to pick up the children late all day, so the teachers had to stay late and get off work, so she had to pay a lot of overtime for these teachers. Despite their apologies, the teachers complained. So she thought of a simple way for the parents to pay the overtime fee and pay by time. The implementation of this policy immediately becomes messy: the parents think you should watch the children for me if I have paid for it, no matter how late I am. The teachers did not get any extra benefits, but they had to get off work late, so they began to protest. The Dean thought too, and the previous day was better, so he canceled the charge. It is strange that almost all the parents did not try to pick up as early as possible, and they did not feel embarrassed when they came to pick up. The reason is that the previously charged services are now free of charge. This shows that, even if the objective conditions are the same, different conclusions and results may occur if there are subjective differences.

 

There are no strict regulations on the companies that do well, because everyone is used to it, and it is a matter of course to take the code quality work well. If it is a company that did not even pay attention to this task, employees will surely think that this is an extra task that does not pay my salary and causes me to work overtime, so everyone is very negative. At this point, the task schedule for this code review needs to be designed:

1. Design a set of rewards and punishments rules;

2. Assign the owner the right to reward and punish in accordance with the rules;

3. Finally, identify the issue of code quality, that is, the issue of the person who writes the code, not the owner. If the code review is not executed according to the predefined rules, it is the issue of the reviewer.

 

What do you think?