About the author: Author: Joel Spolsky is New York City, a small software company Fog Creek Software founder. He graduated from Yale University, once in Microsoft, Viacom, Juno, Software Designers and Manages. "Have you ever heard of SEMA? This is a very deepest system that measures a software development group. Don't move, wait! Don't press that link! For you six years, you can't figure it out. So I myself Just put a set of measuring systems, believe in you, this system, you can master it in three minutes. You can read the medical school below the medical school (translation: US Medical College, you want to read dead!).
(Note: SEMA: SOFTWARE ENGINEERING Measurement and analyysis) joel Measurement rule: 1. Do you use a source file management system? 2. Can you build the entire system from the source code to the CD image file? 3. Do you do it once every day? 4. Do you have a software BUG management system? 5. Do you always solve the software bug known in the existing program before writing a new program? 6. Does your product development schedule reflect the latest developments? 7. Have you have a detailed manual for software development? 8. Do your programmers work in a quiet environment? 9. Do you use the best tools you can buy in the existing market? 10. Do you have a full-time software tester? 11. Do you make a program when you recruit people? 12. Do you just catch some people to try your software?
"Joel Measurement Law" is good, just answer the above questions according to it, then count the question "Yes", then add it, then you can, don't need to write a program written every day. The average number of rows or insects, and the like. But our ugly words, don't use the "Joel Measurement" to calculate whether your nuclear power plant management program is reliable.
If you have 12 points, it is the best, I have to go to 11 points, but if I have to get 10 points or less than 10 points, you may have a very serious problem. The harsh reality is: Most software development companies can only get 2 to 3 points. If these companies can't get first aid, they can be mysterious, because companies like Microsoft have never been 12 points.
Of course, a company success has not only dependent on the above criteria. For example, let a well-managed software company develop a software that is not necessary, and the software developed can only be no one. Or in turn, a part of the software is not reached, and it is not allowed to still make a great software to change the world. But I tell you that if you don't consider other factors, you only need to reach the above 12 guidelines, your team is a strict team that can be on time. ------------------------------------- -------------------------------
1. Do you use a source file management system? I have used commercial source file management systems, I have also used free systems, such as CVS, tell you, CVS is very easy. But if you don't have a source file management system, you are exhausted and can't let your programmer live: they can't know what someone else is changed, and the wrong source file is not resumed. .
There is also a great advantage of using the source file management system. Because each programmer puts the source file from the source file management system, it is hard to lose the source file, at least I still have never heard of that.
2. Can you build the entire system from the source code to the CD image file? The question is: How many steps do you have to do from your latest source code to the final file that can be handed out? A good team should have a batch program to finish all work, as extracting the source file, followed by different language versions (English, Chinese version), and various compilation switches (#IFDef ) Condo, join into an executable file, mark the version number, package into a CD image file or send it directly to the website, and so on. If these steps are not finished, it may be wrong. And when you are very close to the product, you may have an eager to solve the last few insects, then give up as soon as possible. If you need to do 20 steps at this time, you can make the final file, you will definitely be a hurry, then make some mistakes that are very unforgettable. For this reason, the previous company I work is rewinding INSTALLSHIELD using Wise: We must need to completely automate our batch program, in the night, by the NT Scheduler boot to make the final file, Wise can't be started by NT Scheduler And installshield can, we can only throw Wise away. (Wise's guy guarantees that their next-generation products must be automatically running in the night)
3. Do you do it once every day? Have you encountered such a thing: A programmer accidentally puts the source code of the problem into the source file management system, and the result is not possible. For example, he established a new source file but forgot to put it in the source file management system, and he was highly happy to hit the machine, because the entire compile in his machine is very good. But others have done it because it doesn't work, but I have to go home.
This is very bad, but it is very common. If you use the final file over the day, you can make this kind of thing not to cause too much harm. In a big team, you must ensure that the source code with the problem is corrected in time, it is best to make the final document every afternoon (such as lunch). Before lunch, everyone puts the changed source file in the source file management system as much as possible, after lunch, everyone is back, if the final file has been made, good! At this time, everyone will take the latest source file from the source file management system and then work. If the final file makes an error, the error is correct, and others can then work with the original origin of the original.
In the Microsoft Excel development group I have done before, we have a provision: who has made the final file production error, whoever be punished to monitor the final document production process after monitoring until the next, resulting in the final file production error People will take responsibility. This can not only urge everyone to make the final file production error, but also allow everyone to have the opportunity to understand the final file production process.
If you want more to understand this topic, you can read another article Daily Builds Are Your Friend.
4. Do you have a software insect management system? No matter where you have any excuses, as long as you write the program, even if you are just a group of groups, if you don't have a systemic management software tool, the quality you write must have a good quality. Many programmers feel that they can remember their software. no way! I have never remember more than 2 to 3 software insects. And the next morning, I was busy buying this, and the software insects that I can't easily remember. You absolutely need a system to manage the insects of your.
There are fewer software insect management system features. But at least the following information: How to repeat the detailed steps of the software insects (inseparable) should be what is the situation (insects), how is it to be responsible for insecticidality? If you think the software insects The system is too trouble, it can be simplified, establish a table with the above 5 columns to use it.
If you want more to understand this topic, you can read another article. Painless bug tracking.
5. Do you always solve the insects known in the existing program before writing a new program? The first edition of Microsoft Windows Word was considered to be a "Death Tour" project. It seems that I will never do it, always timeout. Everyone works crazy, but also can't complete the task. The entire project is dragged again, everyone feels that the pressure is very stressed. Finally, I finally finished this ghost project, Microsoft sent the whole group to Cancun, Mexico, let everyone sit down and think about it.
Everyone realizes that the project manager is too strong for programmers to pay on time, everyone can only hurry, and the procedures written will be. Since the development plan of the project manager does not consider insecticidal time, everyone can only push the mandaic task, and the more you get more. There is a programmer responsible for writing a calculation font height. For the illustration, it is actually written "Return 12;" He expects a quality inspector in the future to find that this process is reported to report him again. The development plan of the project manager has tried to have a list of locked programs, and the so-called program functionality above will become a software insect. At the project summary, we call this working method as "absolute inferior road". In order to avoid this mistake, Microsoft has developed "zero defect strategy." Many programmers laughed at this strategy, and they feel that managers seem to be relying on administrative orders to improve product quality. In fact, the true meaning of "zero defect strategy" is: At any time, we must grasp the problems in existing programs as the primary problem, and then write new programs. Why do you do this?
Generally speaking, you can't insect insects in time, the higher the price of insecticidality (time and money). For example, when you write a program, you went wrong with a word, and the compiler immediately told you that you easily correct it. You just wrote a problem when you first rule, you can solve it soon, because you still remember the program you just wrote. If you discover a problem when you run your program, this program is written in a few days, you may need to toss for a while, okay, you still remember, so you will not spend too long. But if you discovered a problem in a program you wrote before you wrote, it's more difficult to solve because you have forgotten a lot of details. At this time, you are not allowed to kill the insects in others, because this guy goes to the Caribbean Aruba. At this time, it is difficult to solve this pile of problems. You must be careful, very systematically engaged, and you can hardly know how long you can solve the problem. There is also a worse, your program has been handed over to the user's hands, and then discovers the problem, then you will wait for the pocket.
Summarize, it is a step: the sooner, the easier solve.
There is another reason that the problem is found in the program that you can easily estimate the time to solve it. For example, if I ask you to write a program to order a list, how long you can give me a relatively exact estimate. If your program, after Internet Explorer 5.5 installation, work is not working. I asked how long you have to solve this problem, you may be estimated that you don't know why it has caused this problem. You may have to spend three days to solve, or it is possible to spend two minutes.
This example tells us that if there are many insects in your development, there is no timely resolution in time, then your development plan is definitely unreliable. In turn, if you have solved the known insects, what you want to do is just writing a new program, then your development plan will be more accurate. Solve known insects, so there is a benefit: You can quickly counterattack competitors. Some people call this "Let the products in the development can be given to the user." If your competitors launched a new feature to take your customers away, you can exercise new products immediately, and immediately deliver new products, because you don't have a lot of accumulation problems to be resolved. 6. Does your product development schedule reflect the latest developments? Why do we need to develop a schedule? If your program is very important to the company's business, the company must know when your program can write. The programmer in the world has a common problem, that is, they all can't figure out how they can write the procedures you want. They will only have a manager: "When I do it!"
Unfortunately, the program is finished, and it is far away. As a company, there are many things to do before issuing products: When is it a product demonstration? When will I participate in the exhibition? When is advertising? and many more. All this also rely on the development schedule of the product.
Dessed the product development schedule, there is a very critical benefit: it is forced that you only make the features you do, you can get the function you want, otherwise these things that can be wrapped. live. Please see featuritis.
Ding the product development schedule, according to it, it is not difficult to do, please see my article. Painless Software Schedules, this article tells you a good way to develop product development schedules.
7. Have you have a detailed manual for software development? The detailed manual of writing software development is like embroidery: everyone knows is a good thing, but no one is willing to do it.
I don't know why, maybe because most programmers are born, I don't like writing articles. As a result, the programmers in the development group, Ning can be used to communicate, nor will they write articles to express themselves. They like to write the program, not what detail.
In the previous design process of the product, if you find some problems, you can easily in the specification. Once entered the stage of writing, solving the cost of the problem is much higher, not just the cost of time, but also has a feeling of feelings, because no one is willing to throw it away. So there is always some resistance to solve problems at this time.
There is no product development detailed manual to start writing procedures, often leading to a mess to write a mess, and the left drag left cannot be delivered. I think this is the problem encountered by Netscape. The first four versions of the program worse, and the management person made a stupid decision: throw it away, rewrite it. Later, they made the same mistake when developing Mozilla. The product is more chaotic, completely out of control, spent a few years to enter the internal testing phase.
My most proud theory is: If the programmer accepts some training in writing, if they will change, they may change the bad habits of the instructions, and the poor examples mentioned above are likely Less occur.
Another way to solve the problem is to hire some of the project director, full-time write product development detailed manual.
No matter which method is adopted, there is only one way: before you don't have a product development detailed manual, you will never write procedures. If you want to know more about this topic, you can read my four articles.
8. Do your programmers work in a quiet environment? When you make your think tanks in quiet, spacious, uninterrupted, they often live faster, this is an indisputable fact. There is a classic Software development management book PeopleWare (person) explains this problem very well. The problem is that we all know that it is best not to interrupt the ideas of these thinks, so that they have been in their best, so they can work all the best, and they will work full of their roles. Writers, programmers, scientists, and even basketball players have their best.
The problem is that it is not easy to enter this best state. I think the average will take 15 minutes to enter the best state to achieve the highest work efficiency. Sometimes, when you are tired or have been highly efficient, you will be difficult to enter this state, you have to do something to send time, or go online, play games.
The problem is more, you are easy to bother to be disturbed by a variety of things, being taken out of your best: noise, phone, lunch, drink coffee, being buddy, etc. If a colleague asks you a question, spend a minute, but you are taken out of your best working condition, returning to this state takes half an hour. Your work efficiency is therefore greatly affected. If you make you work in a noisy big room (the guy who gave the website also like this), the salesman on the side called big shout in the phone, you will be difficult to live, because you can't enter you. Best working status.
As a programmer, it is more difficult to enter the best working condition. You must first put all the details in your mind, any interference may let you forget something. When you returned back, I found out something I can't remember (as you have just used the local variable name, or where you have just written, you have to look at the procedures just written, recall, slowly Back to your best working status.
Let's do a simple calculation. Suppose a programmer is bothering, even if he only has to spend 15 minutes to return to the best working status (statistics show this). We have two programmers: Jeff and fool, sitting in a big office. I can't think of any function to make a Unicode string copy. He can spend 30 seconds to check, or spend 15 seconds asked Jeff. Because he sat next to Jeff, he chose to ask Jeff. Jeff was buddy, delayed him for 15 minutes, saving fools for 15 seconds.
Now, we have separated them with walls and doors, let them two in different offices, fools can't think of any function name, check it to spend 30 seconds; ask Jeff, spend 45 seconds Because he wants to stand up and go on and ask (for this programmer, this is not a simple thing, see why they do it). So he chose himself to check. The fools lost for 30 seconds, but Jeff lost 15 minutes. Haha!
9. Do you use the best tools you can buy in the existing market? I am afraid that I can write a compilant language. I am not having a few things that I can't just catch a computer. If you are used to compile time more than a few seconds, you should change the latest fastest computer. Because if the compile time is more than 15 seconds, the programmer will impatient, turn to the Internet to see some things, such as the onion, can't get good, it is a few hours.
When adjusting the picture interface software, the computer with only one display is not only inconvenient, sometimes it is even impossible. It is convenient to use two computers with two displays. Programmers often want to draw some icons or toolbar pictures. Most programmers do not have a good graphic editor. Draw icon with Microsoft's "brush" software is simply joke, but in fact, everyone is still doing this.
In my previous job, the system administrator sent me a day to automatically warned, saying that I used more than 220 megabits on the server. I told him that according to the price of the hard disk, it is far lower than the price of this space than the price of the toilet I use. Let me take a 10 minutes to clean my documents is definitely a lot of waste of my work efficiency.
The first-class development group is never tossing its programmer. The tool will make people feel uncomfortable, and a little accumulation will make the programmers called to be boring, and a programmer that is a lot of hardships will definitely be a higher power programmer.
Add another sentence, to make your programmer happy, the best way is to buy some of the latest best tool software. Use this method to make them work for you, which can be much cheaper than using high salary.
10. Do you have a full-time software tester? If there is no full-time tester in your development group, or there is not enough tester (two to three programmers should match a tester), then your product must be a problem. I want to save money on the tester, it is definitely wrong. I really don't understand why so many people can't play this account.
I have another article to tell this, see Top Five Reasons you don't have testers.
11. Do you make a program when you recruit people? I asked you, let you take a magician, do you even see how his magic is playing? of course not! You hold a wedding banquet, please ask a chef, do you have a good food that you don't want to do it? I don't want it.
The strange thing is that there is such a thing almost every day: when a programmer is interviewed, the resume is beautiful, talking about the heat and asking a few simple questions (such as CreateDialog () and Dialogbox () What is the difference? Question, check the help file know it), people will come back. You really shouldn't care about this person doesn't remember the side of the side corners of these writers, but he can go out! Worse, many questions are to know, don't know, I don't know if I want to die.
Can't go on this! When interview, please be sure to write a program. In my article, Guerrilla Guide to Interviewing, I have a lot of good suggestions.
12. Do you just catch some people to try your software? The meaning of this sentence is to let you take a few people from the people walking through the walk, let them try your software. If you catch five people to use your software, you might find 95% of your programs that are not convenient to use.
To let users buy your software, you have to design your user interface. This is actually not difficult. You can read my FREE ONLINE BOOK ON UI Design to play the foundation. The key to the user interface design is if you let a few people go with your software (five or six people may be enough), you may soon find the biggest problem. Want to know why, please read Jakob Nielsen's Article. As long as you stick to someone to try your software, you can design your user interface is getting better and better.
-------------------------------------------------- ------------------------------
The Joel Test Software Development Successful 12 Four Practices: 1. Use this law to measure your software development group, tell me your score, let me go to the head.
2. If you are the manager of the development group, use this rule to make your group increase efficiency. If you come up with you, you can don't bother your programmer, concentrate on can't let the company's managers come to your programmers.
3. If you are looking for a programmer, ask your future boss, he can get a bit, if the score is low, you must be sure that you have enough power to change this, otherwise, it is best to hide Far, otherwise, you will be very uncomfortable there.
4. If you are an investor, you are deciding whether to invest in a software company, or your software is deciding whether to merge another software company, the rule can help you make a decision. -------------------------------------------------- ------------------------------ Thanks to the lost Rainbow to all the reference documents
