Agile questioning: Pair Programming and collective ownership of code

Q: Peer programming and responsibility sharing are all nonsense. The Code cannot be found by the author. developers have a sense of responsibility!

A: This question is based on the assumption that the developer's sense of responsibility comes from the accountability system, and developers will be careful to code it only with fear.

I don't know what your position is. You may be a middle-and high-level leader of a large and medium-sized enterprise. Maybe there are many people under your team, but you won't be respected by them. They only have "fear ".

Perhaps in the face of fear of death and the like, humans may blow out powerful forces and fear the medical and military systems. however, in daily life, people are more likely to exert their potential under the drive of honor rather than fear.

Pair hopes to gain mutual respect by displaying their own knowledge, and hopes to get the code quality appreciation when the code is rotated to other peers.

Yes, even if the code is not signed, the team still knows whose code is well written, because of the pair and rotation, because of the version control system.

However, you and the manager do not need to know which code was written or which developer introduced the bug that caused major losses. All the tasks are completed by the entire team.

In fact, what you really want to know is who is excellent, who needs improvement, or who is really not suitable. there are other methods that are better and more effective than code signatures and will not put the entire team in the shadows of fear.

Q: What method is that?

A: This involves the transformation of the overall evaluation system. for example, the team should be evaluated as a whole, customer feedback, profit, and loss should all be at the team level, sharing honor and disgrace.

The evaluation of each member in the team should be done by the team itself. After the rotation and pairing of members, there will be consensus on who is excellent, who needs improvement, and who is not suitable.

Q: Do you mean peer evaluation? Don't talk about it. I just need to make good interpersonal relationships and comment on what you like. Besides, especially Chinese people, they can't erase faces. How can they say bad things in person.

A: This is another idea change. You must reach a consensus through the team culture: peer evaluation helps you discover your own shortcomings and improve your performance, rather than blaming or degrading you. if you are not suitable, peer evaluation will make you more aware of this point, and strive to improve or select another path as soon as possible.

As for face-to-face problems, team culture is still needed. In teams that are adhering to "communication, feedback, and courage" and open-minded, face-to-face feedback is more acceptable.

On the other hand, we all have a mature mind. If a person is uncomfortable with people around us, is it really tolerable because of face problems?

Q: How to Pair Programming and share responsibility leads to such a huge stream? Should we subvert the company's assessment system?

A: Yes, Pair programming is the most controversial one in XP practice. There are not a few developers who oppose it, but the greater resistance comes from the boss's instinctive opposition.

Unfortunately, we live in the era of slogans. Maybe the leaders are used to shouting slogans, and never consider putting the slogans "to the ground" or paying close attention to the implementation of the slogans. Is "cooperation" a slogan that can be worn out by the ears? What are the specific actions? Pair programming is the most specific kind of cooperation.

Bosses question it more about efficiency. in fact, just as TDD increases the overall amount of code, but not the workload, Pair programming does not reduce the efficiency as it is intuition, but it's just a flaw in the dark, and it's nothing more than a bonus.

A few conventional ideas that cannot be understood without personal experience:

1. Don't employees always want to work like a donkey and don't be lazy? Why not let employees supervise each other? Someone is sitting next to you staring at your screen. Can you access the Internet, play games, and chat with your girlfriend? Work at dawn until dark

2. Aren't you always worried about the loss caused by employee job-hopping? Why not let the team clean up all his knowledge while he is still there?

3. Aren't you always worried that someone is writing bad code? Have you always thought that the Code review is not in the form of satisfactory results? Is there a more thorough form of code review than pairing/rotating?

4. Do you always want to learn from each other and complement each other? Isn't it always possible to achieve the effect of "the stinking pipeline Zhuge Liang?

5. Aren't you always worried that new employees will grow too slowly?

6. I don't always want the team to have a good atmosphere, help each other, and no one jumps from the building?

Q: Why should I tell others the experience I have accumulated over the years? I like the irreplaceable feeling.

A: Yes. In essence, this is a question of psychology and political science. I can't convince you either. But let's talk about some points.

1. If you solve a problem that someone else cannot solve, you will be recognized by the company. If you pass on your knowledge to the team, you will at least be recognized by the team.

2. Knowledge of solving known problems can be taught. however, when an unknown problem occurs, the accumulation for many years remains irreplaceable. even if the novice knows the general principle of solving the problem, it will take years of experience to truly use it.

3. If you really have wisdom, you don't have to worry about someone else's plagiarism. They can't plagiarize your thoughts.

If you just worry that credit will be stolen by others, well, I am very poor at both psychology and politics, and there is no way to do it. maybe you can insist that you do not like pairing, and the team should not force you to pair.

Q: Some veterans do not like pairing up, and they feel that it is not good for them to get a new employee. What should they do?

A: People are always willing to do one thing with the highest efficiency. Pair programming should also follow this principle, but it does not mean that they will give up the correct discipline without any effort.

Some people may dislike pairing by intuition, but they have never really tried it. If you want to find a way for team members to really spend some time trying and come to conclusions, your thoughts may change.

However, in the early stages of practice, it is necessary to have an agile coach. pairing involves the cooperation between people and the collision of character. people's problems are the most difficult problems. If you are not comfortable with each other, the negative effects of the pair will be exaggerated, such as disputes between each other and mutual incompatibility, or, they are always dominated by strong people. peaceful people are always forced to take decisions that they do not like and their consequences.

Agile coaches can discover the symptoms of these problems and help the team build good discipline and habits.

Q: As you mentioned earlier, pairing is continuous code review. However, if two new users are paired with each other, the code quality still cannot be guaranteed. I heard that new users are not encouraged to pair up. Is it true?

A: Nothing is true. It depends on your resources. it is naturally the most efficient to work with two experienced and well-known people to solve problems. the best practices in real life are numerous, and even people in the novels express their strong yearning for this form of cooperation: Lu Xiaofeng and Hua manlou Si Kong have picked stars, Chu Liuxiang and Hu tie Hua Ji bingyan, and the four famous arrests.

However, it is true that not everyone in the team is Chu Liuxiang. In fact, experienced people account for half of the total, so that every developer has an experienced person, which is already quite good.

New people are paired with each other, but they also have another effect. Although the short-term overall efficiency of the team may be short-term, the individual's growth may be, will leave some impressive lessons to play a role in the future career.

There are some mutually supportive practices to improve the efficiency of pairing new people, such as dedicated development space for the team. In fact, everyone is sitting in a room, experienced people can join the discussion whenever they hear that the discussion between pair is significantly different from the correct solution.

Q: What should I do if I don't want to interact with each other?

A: several practices:

1. More people are involved in the discussion and time window;

2. First, select one of them to view their opinions;

3. Don't choose a meal, that is, the compromise solution usually focuses on the disadvantages of the two solutions.

In fact, Pair programming has the greatest impact on developers. turn your focus from dealing with machines to dealing with people. pull you back from the virtual machine world to the real world. turn programmers back to "people" and practice communication between people.

Do not argue at work.

Q: What should I do when a strong person leads?

A: This problem can be quickly discovered by the entire team. the team needs to communicate with strong people to remind them that they should not maintain their own solutions when encountering problems. however, it is usually difficult to change the nature. In this case, if other members believe that their solutions have merits, they must insist on not giving up and expand the scope of the discussion, more people are involved in the discussion.

The project manager and the agile coach in the early stage need to pay special attention to such issues, because it may turn pairing into a false pair, but on the surface it is two people.

Q: Do I have to pair them? In the personal coding era, countless excellent software products are generated, and the author's thoughts and personality are better reflected.

A: The words "must" should only appear in several basic theorems. In other cases, they are usually wrong, and they will always give the attackers a handle, sometimes, even if you just say something is recommended for use, he can also understand that you are saying "must" use something

In at least two extreme cases, pairing is not mandatory:

1. Complex issues that require meditation in the initial stage can be divided into different actions. They have their own understandings, solutions, and time windows for further discussion. speech can also help in the process of thinking, but we all know that for some problems, words only disturb our thinking.

2. A bunch of trivial and technical work has to be done manually. It is only a test of patience. Naturally, you may wish to split the work into multiple parts, and the efficiency is definitely higher than that of pairing.

Q: A few developers discuss their respective issues at the same time. It's too noisy!

A: click it.

Q: we also need to discuss communication between pair so that people around us can detect deviations in time to save time. Should we keep a quiet voice or speak out loud?

A: quiet discussion

Q: If the code is collectively owned, an error occurs in a module. At this time, more than five developers have edited the code in this module. Who will modify the code?

A: The team needs to modify it. If you want to add new functions to a module, more than 5 developers have already edited the code of this module. Who will add it?

Q: I want to modify some code. I want to contact the original author to find out the idea, but I don't know who it is.

A: SVN praise/blame. What should happen more:

1. TDD: Once you change the unit test case, we will give you feedback.

2. Rotation and pairing programming, many people may be aware of that Code.

3. Simple design, code should not be too complex