Coders: perfectionist is also a mistake

I have shared a series of articles from programmers to project managers. Here is just an excerpt.

1. polarization programmers

I believe that in the eyes of many people, programmers are meticulous, well-crafted, and well-rounded. Look, they sit in front of the computer for half a day. If they are not perfect people, who can sit on the bench like this?

However, in my opinion, the programmer is actually a serious polarization on the issue of "pursuing perfection. Some programmers really have high requirements on their own code. When programming, they pay great attention to the rigorous logic, low running efficiency, and elegant code. They often perform Code reconstruction and optimization. They are like Jiezi, a rural lazy, who keeps scanning all day. Where can they see code that is not pleasing to the eye? If they want to maintain a system, most of the time, he will be asked to refactor or rewrite the code of the entire system. They are real perfectionists.

Some people write code just to complete the task. They are responsible for their own functions, lack of planning and design processes, where to write where to think, and finally press F5, compiled through, ouye! They do not even want to add more buttons they have created, nor enter a phone number in an ID card number text box to test the problem. The most important thing is that they can finally deliver the problem to the manager, as for how many hidden issues in the code, let's talk about it later. This reminds me of what Joel, chief of the programmer's tribe, said: The program they wrote "looks like a breakfast for a dog. It's enough to eat a dog, why do we have to spend money to make food colorful?" We can even imagine whether their computer screens are full of dust, whether the keyboard seams are full of hair and food debris, and whether the icons on the computer desk are like colorful puzzles.

The latter type of programmers seem to have an absolute advantage in quantity. For a project manager who is not good at controlling the quality of the project, their code will eventually become a nightmare for the project. Once the system is put into operation, the insects will continuously emerge from the nostrils, mouth and ears like alien creatures in the American horror film.

The second kind of low-standard, casual practice of programmers is easy to recognize as a bad trend, and perfectionist is not like this, because we have been taught to pursue perfection since we were young, perfectionist is generally regarded as an excellent character and a goal that everyone should pursue.

However, although perfectionist sounds good, it is not suitable for projects, because the goal of the project is to complete the project at the minimum cost to satisfy all parties, rather than creating a perfect product, to prove the capabilities of an individual or a company. Obviously, perfectionist is more suitable for the cultivation of personal abilities, or a scientific research without deadline to produce results. In projects, perfectionist is also a mistake, although it is a beautiful mistake ".

Perfectionists and casual people, both programmers are not the best candidates for the project. They happen to be two opposite extremes. If they are responsible for the project, it is estimated that they are just like playing the saw, either under the ground or in the sky. However, the project cannot handle such a problem. People in the project must have the ability to balance themselves. They have a good grasp of the pursuit of perfection, so that the software functions can meet the customer's application needs, it does not have to spend too much energy. Unfortunately, there are not many such programmers, because it is not easy for programmers to grasp the degree.

2. Perfect is not equal to 100 points of Quality

The perfection in the programmer's mind is not the same as the perfection in the project manager's mind, because the two focus differently. Programmers focus on their own software functions and strive to achieve the best quality of software products. Therefore, the perfection of programmers is actually the perfection of quality.

In the eyes of the project manager, the entire project, including quality, progress, cost, scope, and risks, needs to be balanced, it is perfect to spend the least cost, the least time, the satisfaction of all parties, and the project acceptance. This is obviously not a perfect project because of the first-class product quality, delays in progress, and overspending costs.

In fact, modern quality management theory generally believes that quality is not the higher the better. In fact, the market has proved this countless times. Many people have scolded Microsoft for its poor products. It is said that Steve Jobs also scolded windows as a zombie, but Microsoft became the dominant software industry.

ISO9000's authoritative definition of quality is: the degree to which a set of inherent characteristics meet requirements. We can see that it is satisfying, not exceeding the limit. This is very important. Don't be less, but don't be more, it's a waste. What we need is not a quality of 100 points, or even a first-class quality, but a quality that meets the requirements.

There is a term in project management called "gold plating", that is, after the product meets the customer's requirements, do more work to make the product more perfect, in order to further improve customer satisfaction, this behavior is explicitly prohibited in PMBok. Software Quality: 100 points, not only a huge waste in the project, and almost an insurmountable goal, will only make the project overwhelmed, and finally fall into a disaster situation.

3. Being qualified is perfect.

There is nothing wrong with the pursuit of perfection, but if it goes up to the perfectionist, it will always be the best everywhere, but it may not necessarily meet the local restrictions at that time. A "most" word will kill people, because "there is no best, only better". If you blindly pursue better, the result may be like a monster falling into a tar pit and cannot extricate themselves. In such an era of efficiency, perfectionist may even cause loss of opportunities. Therefore, we need to maintain the pursuit of perfection, but we need to know how to weigh it and not fall into the trap of extreme perfectionist.

To be perfect or not to be perfectionist is essentially a matter of degree. The project should be balanced to avoid extremes. People who have studied the project management theory know that there is an "Tie triangle" in project management, that is, under certain project constraints, the cost, progress, and quality constitute three endpoints of the triangle, in order to keep the Triangle Area unchanged, any change to the endpoint will cause synchronization changes to the other two endpoints. In essence, this triangle is a balance and Restriction Relationship, while perfectionist simply emphasizes quality and ignores other factors. This is obviously an extreme behavior.

What is the "degree" of quality in the project? In fact, the word "qualified" is used. Being qualified means to be recognized, but it does not need to be paid at an excellent cost. Is it perfect for customers to recognize, make leaders happy, And make employees easy? It can be said that there is no best project, only qualified, qualified is perfect.

4. "70 points doctrine"

Since we were young teachers and books, we had to pursue perfection. We had to take an exam of 100 points, and 90 points were too low. Can we still get 70 points?

In fact, 70 points is not low. You need to know that the current college students' slogan is "Long live 60 points, waste more points, and invalidate less points ". Of course, such slogans are easy to be criticized for not thinking ahead, but there is a reasonable side to the existence of everything, and "60 minutes long live" is also a reason.

In terms of learning, I advocate perfectionist on the premise that I want to learn something that is personal interest, useful, and practical. Most of our university courses are basically contrary to each other. The purpose of attending classes and exams is not to take the subject, but to successfully obtain the diploma and degree certificate. In this case, it is easy to understand Long live 60 minutes. Why do you have to score 100 points? The time saved can be used to learn things you are more interested in.

To some extent, taking a project is also an exam: There are exam content (project scope), exam time (Progress requirements), and passing lines (quality requirements and acceptance criteria ). If the pass line of the Project is expressed by a score, it is also 60 points. Now that 60 points is enough, why did we propose 70 points? In fact, it is very easy, because it is too difficult to get a 60-point test. If it is not done well, it will fail. Therefore, I proposed the "70 points doctrine", a new doctrine that surpasses the perfectionist and strives to strike a balance between passing and perfection.

If the project is divided into 70 targets and a buffer is set properly, the project can be easily controlled. 70 points means that the customer's acceptance requirements have been met and can be put into normal use, but there may be some bugs that have a small impact. The efficiency of some pages needs to be improved, and some operations are not very satisfactory, general system scalability, code organization, and further optimization ...... Let them stay there for these imperfect places. After all, the customer has already felt that they have reached the goal. Why do they have to compete with themselves and reach 100 points? This is King! It only takes 7 minutes to eat, and 70 points to the project. "Long live 70 points "!