[Add to favorites] 12 rules for successful software development -- Joel Spolsky

Author profile:
Author: Joel Spolsky is the founder of Fog Creek Software, a small software company in New York City. He graduated from Yale University and worked as a software designer and manager at Microsoft, Viacom, and Juno.

"Have you heard of Sema? This is a profound system that measures the quality of a software development group. Wait! Don't press that link! You don't know about this for six years. So I just collected a measurement system. Believe it or not, this system can be mastered in just three minutes. You can save the time to go to medical school !).

(Note: Sema: Software Engineering Measurement and Analysis)

Joel rules:
1. Do you need a source file management system?
2. Can you build the entire system from the source code to the CD image file in one step?
3. Do you perform the process from the system source code to the CD image every day?
4. Do you have a Software Bug Management System?
5. Do you always solve known software bugs in existing programs before writing new programs?
6. Does your product development schedule reflect the latest development progress?
7. Do you have a detailed instruction for software development?
8. Do your programmers work in a quiet environment?
9. Do you use the best tools available in the market?
10. Do you have a full-time software tester?
11. Do you want to write a program during the interview?
12. Do you need to try out your software by anyone?

The "Joel rules of measurement" is good. You only need to answer the above questions one by one, and then calculate the question "yes" as one point. Then, you can add it, you do not need to calculate the number of program lines or the average number of program worms written every day. However, in the end, we should not use the Joel rule to determine whether your nuclear power plant management program is reliable.

If you get 12 points, it's the best. If you get 11 points but you get 10 points or less, you may have serious problems. The harsh reality is that most software development companies only score 2 to 3 points. If they do not get the first aid, they will become mysterious, because companies like Microsoft have never scored less than 12 points.

Of course, the success of a company is not only dependent on the above standards. For example, if a software company with excellent management needs to develop a software without human requirement, then the software developed can only be left unattended. Or, in turn, a group of software vendors cannot meet the above standards, and may be able to develop a great software that changes the world. But I tell you, if you do not consider other factors, as long as you can meet the above 12 rules, your team is a well-disciplined team that can deliver on time ."

--------------------------------------------------------------------------------

1. Do you need a source file management system?
I have used a commercial source file management system, and I have also used a free system, such as CVS. Tell you, CVS is quite useful. However, if you do not use the source file management system at all, you are exhausted and cannot make your programmers work: they cannot know what source files are being modified by others, and the wrong source files cannot be recovered.

Another major benefit of using the source file management system is that, since every programmer puts the source file from the source file management system into his own hard disk, there will be almost no loss of the source file, at least I have never heard of it.

2. Can you build the entire system from the source code to the CD image file in one step?
The question is: How many steps do you have to do from the beginning of your latest source code to the creation of the final file that can be handed in? A good team should have a batch processing program to finish all the work in one step, like extracting the source file, which is in accordance with the requirements of different language versions (English and Chinese ), compile with various compilation switches (# ifdef), connect to executable files, mark the version number, package it into a CD image file, or directly send it to the website.

If these steps are not completed in one step, human errors may occur. And when you are very close to the end of product development, you may be eager to solve the last few bugs and submit them as soon as possible. If you need to do 20 steps to generate the final file at this time, you will surely be in a hurry and then make some mistakes that should not be made.
 
For this reason, the previous company I work for switched from wise to InstallShield: we must make our batch processing programs fully automated at night, the final file is made by NT scheduler startup. Wise cannot be started by NT scheduler and InstallShield can. We can only discard wise. (The wise guys assured me that their next-generation products must run automatically at night)

3. Do you perform the process from the system source code to the CD image every day?
Have you ever encountered such a problem: a programmer accidentally put faulty source code into the source file management system, resulting in the final file being unable to be made. For example, he built a new source file but forgot to put it into the source file management system. Then he happily locks the machine back home, because the entire compilation on his machine is good. But other people can't work, so they have to go home in a stuffy manner.

This is a very bad situation where the final file cannot be made, but it is very common. If the final file is made every day during the day, this will not cause too much harm. In a large team, to ensure that the faulty source code is corrected in a timely manner, it is best to create the final file every afternoon (such as lunch. Before lunch, everyone tries their best to put the changed source file in the source file management system. After lunch, everyone will come back. If the final file has been made, okay! At this time, you will retrieve the latest source files from the source file management system and then work. If an error occurs in the final file creation, the error will be corrected immediately, and others can continue to work with the original source program without any problems.

In the Microsoft Excel Development team that I have previously worked on, we have a rule: whoever makes the final file wrong will be fined to monitor the final file production process in the future, until the next person who makes the final file wrong takes over. In this way, we can not only urge everyone to make mistakes in the final file production, but also give everyone the opportunity to understand the final file production process.

To learn more about this topic, read my other article daily builds are your friend.

4. Do you have a software worm Management System?
No matter what excuses you have, as long as you write programs, even if you are only a group of people, if you do not have a systematic tool for managing software worms, the quality of the programs you write will not be high. Many Programmers think they can remember their software bugs. No! I can't remember more than two or three software bugs. In addition, when I got up the next morning, I was busy buying the software to buy it. I forgot about the software bugs that I remember. You absolutely need a system to manage your worms.

The software worm management system has fewer functions. However, you must manage at least the following information:
 
Detailed steps for repeated software bugs
What should I do under normal circumstances (no insects )?
What is the current situation (with insects )?
Who is responsible for Insecticide?
Is the problem solved?

If you think it is too troublesome to use the software pest management system, you can simply create a table with more than five columns.

If you want to learn more about this topic, read my other article painless bug tracking.

5. Do you always solve known bugs in existing programs before writing new programs?
The first development project of Microsoft Windows Word was once considered a "death Journey" project. It seems that it will never be done, and it will always time out. Everyone is crazy at work, but they cannot do anything. The whole project was delayed, and everyone felt that the pressure was too high. Finally, after finishing the ghost project, Microsoft sent the entire group to Cancun in Mexico for a vacation. Let's sit down and think about it.

We realized that the project manager was too eager to ask programmers to deliver jobs on time. As a result, everyone had to rush to work, and there were hundreds of program faults. Because the project manager's development plan does not take the time for the insects into consideration, you can only push back the insects task, and the result insects accumulate more and more. There is a programmer responsible for writing a program to calculate the font height. For the sake of fast graphics, he wrote a line "Return 12. He expected future QC personnel to report the problem and correct it again. The Project Manager's Development Plan has actually become a list of program writing functions, and the so-called program functions listed above will become software bugs sooner or later. At the project summary meeting, we called this work method "absolutely inferior ".
 
To avoid making this mistake again, Microsoft has developed a "zero defect strategy ". Many programmers laugh at this strategy and think managers seem to rely on administrative commands to improve product quality. In fact, the true meaning of the "zero defect strategy" is: at any time, we should take solving the problems in the existing programs as the primary issue, and then write new programs.
 
Why?

Generally, the less time you get rid of the virus, the higher the cost of the virus (time and money. For example, when you write a program with a wrong word, the compiler immediately tells you that you can easily correct it. The program you just wrote found a problem during the first run, and you can solve it quickly, because you still remember the program you just wrote. If you find a problem when running your program, but this program was written a few days ago, you may have to wait for a while, so it won't take too long. But if you find the problem in the program you wrote a few months ago, it will be more difficult to solve, because you have forgotten many details. At this time, you may not be busy killing worms in other people's programs, because this guy has been on vacation to the Caribbean island of Araba. At this time, it is no less difficult to solve this pile of problems than to engage in cutting-edge scientific research. You must be careful and systematic, and it is difficult to know how long you can solve the problem. Even worse, your program has been handed in to the user to find out the problem, then you are waiting for your pockets.

To sum up, the sooner the problem is solved, the easier it is to solve.

Another reason is that you can easily estimate the time to solve the problem in a newly written program. For example, if I ask you how long it takes to write a program to sort a list, you can give me a definite estimate. If your program is not working properly after Internet Explorer 5.5 is installed. I'm afraid you cannot determine how long it will take to solve this problem, because you have no idea what causes it. It may take three days for you to solve the problem, or two minutes.

This example tells us that your development plan is definitely not reliable if many insects are not solved in time during your development process. In turn, if you have solved all known bugs and want to write new programs, your development plan will be more accurate.

Solving all known insects has another benefit: You can quickly fight back against competitors. Some people call this "to keep the products under development in a State that can be handed over to users at any time ". If your competitor wants to take your customers away from a new feature, you can immediately add this feature to your product and deliver the new product to users immediately, because you don't have a lot of accumulated problems to solve.

6. Does your product development schedule reflect the latest development progress?
Why do we need to develop schedules? If your program is important to the company's business, the company must know when your program will be written. Programmers all over the world have a common problem, that is, they don't know when to write the program they want to write. They will only yell at the management staff: "I will do it when I do it !"

Unfortunately, the program is finished, and the process is far from complete. As a company, there are a lot of things to do before releasing products: when to do product demonstration? When will I attend the exhibition? When do I advertise? And so on. All of this depends on the product development schedule.

There is also a key benefit in setting the product development schedule: it forces you to only do the functions you want to do and get rid of the functions that you want to do, otherwise, these things that can be or don't need may enclose you. See featuritis.

Setting the product development schedule and developing according to it is not difficult. Please refer to my other article painless software schedules, which tells you a good way to develop the product development schedule.

7. Do you have a detailed instruction for software development?
Writing a detailed instruction for software development is like embroidery: A human being is a good thing, but no one wants to do it.

I don't know why, maybe because most programmers do not like to write articles. The result is that programmers in an Development Group would rather communicate with programs than write articles to express themselves. They like to write programs instead of detailed instructions.

In the preliminary design process of the product, if you find some problems, you can easily put a few lines in the manual. Once a program is written, the cost of solving the problem will be much higher, not only at the cost of time, but also at the emotional cost, because no one wants to discard what they make. So there is always resistance to solving the problem at this time.

If you do not have a detailed instruction for product development, writing programs will often lead to a mess, and dragging left and right will not be able to be delivered. I think this is a problem with Netscape. The first four versions of the program became messy, and the management staff made a stupid decision: They threw away all the previous programs and re-wrote them. Later, they made the same mistake when developing Mozilla. It took several years for the product to enter the internal testing stage.

My best theory is: If programmers are trained to write articles, such as an intensive course in writing, they may change the bad habit of not writing instructions, however, the worst examples mentioned above may rarely happen.

Another way to solve the problem is to hire some competent project directors to write detailed product development instructions.

No matter which method is used, there is only one principle: no program can be written before there is a detailed instruction for product development.
 
To learn more about this topic, read four of my articles.

8. Do your programmers work in a quiet environment?
It is an indisputable fact that you allow your smart sac to work in a quiet, spacious, and non-disturbing environment, and they can often survive faster. The typical software development and management book peopleware (human parts) has clearly explained this issue.

The problem is that we all know that it is best not to interrupt the thinking of these smart sac people and keep them in their best state, so that they can concentrate on their work and give full play to their role. Writers, programmers, scientists, and even basketball players all have their best states.

The problem is that it is not easy to enter this optimal state. On average, I think it takes 15 minutes to get to the optimal state and achieve the highest work efficiency. Sometimes, when you are tired or have done a lot of work efficiently, it is difficult for you to enter this state, so you have to do some chores to pass the time, or access the Internet, play games and so on.

The problem is that you are easily disturbed by a variety of things and your best status is noise, phone calls, lunch, and coffee, I was disturbed by my colleagues, and so on. If a colleague asks you a question, it takes only one minute, but you are taken out of your optimal working status, it takes half an hour to return to this status. Your work efficiency is greatly affected. If you want to work in a noisy big room (the guys who engage in websites also like this), the salesman on the side will yell on the phone and you will have a hard time getting out of work, because you cannot enter your optimal working state.

As a programmer, it is more difficult to enter the optimal working state. First, you need to put all the details in your mind. Any interference can make you forget something. When you get back to work, you can't remember some things (such as the name of the local variable you just used or where your search program was written ), you have to look at the program you just wrote, recall it, and slowly return to your best working status.

Let's make a simple arithmetic. Suppose a programmer is disturbed, and it takes 15 minutes for him to return to the optimal working state (as shown in statistics) even if he has only one minute ). We have two programmers, Jeff and Yufu, who work in a big office area. You can't remember what function to use to copy Unicode strings. It takes him 30 seconds to check, or 15 seconds to ask Jeff. As he sat next to Jeff, he chose to ask Jeff. Jeff was disturbed and delayed for 15 minutes, saving him 15 seconds.

Now, we separate them with walls and doors, so that they can sit in different offices. It takes 30 seconds for Yufu to find out the function name; it takes 45 seconds to ask Jeff, because he has to stand up and go over and ask (this is not a simple task for these programmers. They can see why they are physically familiar ). So he chooses to check it by himself. Jeff lost 30 seconds, but Jeff lost 15 minutes. Haha!

9. Do you use the best tools available in the market?
Writing a program in a compiled language is probably one of the few tasks in the world that can't be done by a computer. If it takes more than a few seconds to compile, you should change to the latest and fastest computer. If the compilation time exceeds 15 seconds, the programmers will get impatient and go online to view irrelevant things, such as the onion, which may take several hours.

When debugging graphic interface software, it is inconvenient and sometimes impossible to use a computer with only one monitor. It is much easier to use a computer with two monitors.

Programmers often draw icons or toolbar diagrams. Most programmers do not have a good graphic editor. It is a joke to use Microsoft's "paint brush" software to draw icons, but in fact everyone is still doing this.

In my previous job, the system administrator sent me an automatic warning all day, saying that I used more than 220 MB of space on the server. I told him that according to the current hard drive price, the price above this space is much lower than the price of my toilet paper. It is absolutely a waste of work efficiency to let me spend 10 minutes cleaning my files.

First-class developers will never bother with it. Tool lagging behind will make people feel uncomfortable to use. A little bit of accumulation will make programmers get bitter, and a programmer who gets bitter will never be a high-consumption programmer.

To make your programmers happy, the best way is to buy them the latest and best tool software. Using this method can make them work for you, which is much cheaper than attracting them with high salaries.

10. Do you have a full-time software tester?
If you do not have a full-time tester in your development team, or you do not have enough testers (two or three programmers should have one tester), your product must be faulty. To save money on the tester is definitely wrong. I really don't understand why so many people cannot count on this account.

I have another article dedicated to this. Please refer to top five (wrong) reasons you don't have testers.

11. Do you want to write a program during the interview?
I asked you to ask you to recruit a magician. Do you want to take a look at his magic without looking at it? Of course not!
 
You hold a wedding banquet and want to invite a cook. Are you sure you don't even want him to cook the dishes that are delicious? I don't think so.

The strange thing is that this happened almost every day: when interviewing a programmer, his resume was well written and he talked about it with great enthusiasm and asked a few simple questions (such as createdialog () what is the difference with dialogbox? If this problem occurs, you can find the Help file. What you really need to care about is not whether this person remembers the things that write programs, but whether he can produce products! What's worse, many problems are the problems of knowing, not knowing, or wanting to die.

This is not the case! Make sure to write a program during the interview. In my article, guerrilla guide to interviewing. I have many good suggestions.

12. Do you need to try out your software by anyone?
The meaning of this sentence is to let you catch a few people from the path and let them try your software. If you capture five people to use your software, you may find out 95% of the inconvenient places in your program.

To allow users to buy your software, you must design your user interface. This is actually not difficult. You can read my free online book on UI design to lay the foundation.
 
The key to user interface design is that if you want several people to use your software (five or six people may be enough), you may soon find the biggest problem. For more information, see Jakob Nielsen's article. You can design your user interfaces better and better as long as you stick to trying your software.
 

--------------------------------------------------------------------------------

The Joel test software has been developed successfully. The 12 rule has four practical fields:

1. Use this rule to measure your software development team and tell me your score. Let me discuss it first.

2. If you are the development team manager, use this rule to make your group more efficient. If you get 12 points as soon as you get up, don't bother your programmers any more. Don't let the company's managers bother your programmers.

3. if you are looking for a job as a programmer, ask your boss about how many points he can earn. If the score is low, you must be sure that you have enough power to change everything after entering. Otherwise, you 'd better stay away. Otherwise, it will be hard for you to be there.

4. If you are an investor and are deciding whether to invest in a software company, or if your software company is deciding whether to merge with another software company, this rule can help you make decisions.

--------------------------------------------------------------------------------

Thanks to the lost rainbow for collecting all references