Source: The time of the program: 2015-03-12 10:21:07 read:3417
share to: 0[Guide] have you ever heard of SEMA? It's a rather esoteric system to test how good a software team is. No, wait! Do not hand the cheap to open this link! It will take you about six years to get to know this stuff. So I put forward my own, rather irresponsible, sloppy comment.
Have you ever heard of SEMA? It's a rather esoteric system to test how good a software team is. No, wait! Do not hand the cheap to open this link! It will take you about six years to get to know this stuff. So I put forward my own, a very irresponsible and reckless evaluation of a software team's quality test. The best part of this test is that it will only take you 3 minutes. You can save all the time and go to a medical school.
Joel Test
The Joel Test
The benefit of the Joel Test is that it's easy to quickly come up with "yes" or "no" for each of these issues. You don't have to go through the number of daily programming lines and average bugs per inflection point. If your team has a "yes", you get one point. What's disappointing about the Joel Test is that you really shouldn't use it to keep your nuclear power plant software safe.
Getting 12 points is perfect, and 11 points can also be tolerated, but scores of 10 points or less indicate that you have serious problems. In fact, most software companies are running at 2 points or 3 points, and they really need help because companies like Microsoft have been working with a 12-point perfect performance.
Of course, these are not the only factors that determine success or failure: especially when you have a great software team that is developing a product that no one wants, then people are really not going to accept the product. At the same time, a "sharpshooter" who did not do so could still produce an incredibly world-changing software. However, if you have done all 12 things in the same situation, you will have a team that can consistently complete the task.
Do you use source code control?I used the business source code management package, and I used CVS, it is free, let me tell you, CVS is very useful. But if you're not managing your source code, you're going to have to try and get the programmer to work. Programmers don't even know what people are doing. The mistakes made cannot be easily changed. Another benefit of the source control system is that the source code itself can be verified on every programmer's hard drive-I've never heard of a project that uses source-control to lose a lot of code.
Can you compile the program within one step?Through this test I would like to understand: from the latest source code to the rapid replication to the output can be compiled by how many steps? Another excellent team, there is a separate script, it can start from scratch to do a full review of the code, recompile each line of code, generate EXE files, in their various versions, programming languages and #ifdef macro definition combination, create the installation package and the final media –cdrom layout, download the site and so on.
If the process requires more than one step, it is prone to error. When you are nearing completion, you will want to quickly fix the "last" bug cycle, generate the final EXE file, etc. If compiling the code takes 20 steps to complete, run the Install compiler, ..., and so on, you'll freak out and cause you to make stupid mistakes.
For this reason, the last company I worked for was switched from "smart" mode to "Software installation package" mode: We asked for the installation process to run, using NT scheduling to automatically run from the script all night, and "clever" mode does not do this, so we abandoned this mode.
Do you compile code every day?When you use source control, sometimes programmers occasionally check out things that stop compiling. For example, they add a source file, everything compiles well on their machine, but they forget to add the source file to the code base. So they locked the machine and went home, more forgetful and happier. But the others were unable to continue their work, so they had to go home in a very unpleasant way.
Interrupting compilation is bad (and common), but it can help programmers compile code every day to ensure that there are no compiler interrupts without warning. In a large team, a good way to make sure that interrupts can be quickly repaired is to compile the code every afternoon, such as it can be done during lunch time. Everyone has to do as much code checking as possible before lunch. So when they get back from lunch, the compilation is done. If it can be used, it's great! Everyone checks the latest source code before continuing to work. If the compilation fails, you fix it, but everyone can continue to work on precompiled, non-disruptive versions of the source code.
In the Excel project group, we have a rule: who interrupts the compilation, and as a "penalty" for him, he is going to take care of the code compilation work temporarily before others interrupt the compilation. This is a good way to do non-disruptive builds, and it's a good way to get everyone involved in the compilation process to know the compiler principle.
Do you have a bug database?I don't care what you say. If you are developing code, even in a single person's team, without an organization listing all the known bugs in the code database, you will produce a low-quality code. Many programmers think they can put a lot of bud in their brains. That's nonsense. I can't remember two or three bugs at the same time, the next morning, or during the rush hour of writing code. You absolutely have to follow the bug formally.
But the database can be complex or simple. A minimal bug database must contain the following data for each bug:
If the complexity of bug tracking software is the only reason why you don't want to keep track of your bugs, use only the tables that contain the simple 5 elements in these critical areas and start using them.
Will you fix the bug before you write the new code?The first version of Microsoft Word on the Windows system is considered a "death March" item. I do not know when this project will be completed, it is constantly postponed. The whole project team worked in ridiculous time, and once again, again and again, the pressure of the project was incredible. When the nasty things finally shipped, a few years later, Microsoft sent the whole team to Cancun for vacation, they can calm down to do some serious self-reflection.
They realized that the project manager had been insisting on "scheduling" and that programmers were simply quick to complete the process of tapping the code, and because the bug fix phase was not part of the formal schedule, which led them to write down their bad code. There is no countdown to try to keep the bug out of the attack. On the contrary, a programmer is said to have written a code that calculates the line height of the text, simply writing "Renturn 12;" Then just start to wait for a bug report about his functionality that is always correct. The schedule is just a checklist of features that are about to become bugs. Afterwards, this is called the "infinite Defect method".
To solve this problem, Microsoft has generally adopted something called a "zero defect method". Many of the company's programmers giggle because it sounds like a management idea that can reduce the number of bugs by administrative decree. In fact, "zero defect" means that at any given time, the highest priority is to eliminate the bug, and then write the new code. Let me tell you why.
In general, the longer you wait for a bug to be fixed, the greater the cost of the bug (both in practice and in money).
For example, when you make a spelling or grammatical error that a compiler can catch, the cost of fixing it is negligible. When you first see a bug in the code you're trying to run, you can quickly get rid of it, because the code is very clear in your mind.
If you find a bug in the code a few days ago, you'll spend some time finding it, but when you reread the previously written code, you'll remember everything and then fix the bug in a reasonable amount of time.
But if you find a bug in the code a few months ago, you probably forgot most of the code, and it's hard to fix it. At this point you may be fixing bugs in someone else's code, and they may be on vacation in Aruba I., in which case fixing bugs is like science: you have to slow down, start working in a methodical and meticulous way, and you are not sure how long it will take to find a cure for the problem.
If you find a bug in the code you've already sold, you'll incur an incredible price to fix it.
This is one reason to fix the bug right away: because it takes less time. This is related to how long it will take before the new code is written, not the bug fixed. For example, if I want you to predict how long it will take to write a buy-to-order list, you can give me a good estimate. But if I want you to predict how long it will take to fix a bug that code won't work after installing Explorer 5.5, you can't guess, because you don't know what's causing the bug at all. It may take up to 3 days to track it, or just 3 minutes is enough.
This means that if you have a lot of bugs to fix, the schedule is unreliable. But if you fix all the known bugs and all the rest is new, your schedule will be more accurate.
Another important thing about controlling bugs to zero is that you can respond faster to competition. Some programmers think this will make the product ready for sale at any time. If your competitor introduces a new killer feature from your customers, you'll be able to do just that before you sell it, without having to fix a lot of bugs that are accumulating.
Do you have the latest schedule?The test brought us to the schedule. If your code is important to business, there are a lot of reasons to know how the code completion date is important to your business. Programmers are known for their stubbornness in setting up their schedules. "It's time to finish!" "They're going to scream at business people like that.
Unfortunately, this does not make everything better. Before selling the code, the company needs to make too many planned decisions: Software demos, fairs, ads, etc. The only way to do that is to have a schedule and keep it up to date.
Another crucial reason for having a schedule is that it forces you to decide what functions to do and then forces you to pick out the most insignificant features and cut them off, rather than being stuck in a long-term hesitation.
At the same time, following the schedule is not necessarily harsh.
Do you write code with specifications?Writing specifications like Floss, everyone agrees it's a good thing, but nobody does it.
I don't know why, but it's probably because most programmers hate to write documents. As a result, when a team of programmers is confronted with a difficult problem, they tend to use code to express their solution rather than document it. They prefer to write code rather than write a specification first.
In the design phase, when you find a problem, you can easily fix it by editing a few lines of text. Once you start writing code, the cost of fixing the problem is greatly increased, whether emotionally (people hate to throw away the code) or in time, so there is resistance to fixing the problem at this point. Software that is not built from the norm will usually end poorly and the schedule will not be controlled. This seems to have become a big problem in Netscape, and the first four versions of Netscape have slowly become a mess, and management foolishly decided to abandon the old code and start over again. Then they made the mistake again on Mozilla, creating a runaway monster and wasting years to get back to the initial stage.
My consistent claim is that the problem can be solved by sending programmers to a focused course on writing and turning them into similar writers. Another option is to hire smart program managers to write code specifications. In both cases, you should execute a simple rule that "no specification does not code out."
Does the programmer have a quiet working environment?A wide range of records shows that productivity can be increased by providing space, quiet, and privacy to knowledge workers. The classic software Management book, "Man Piece", is a widely documented productivity benefit from these aspects.
Here's the problem. We all know that knowledge workers work best with the "inspiration Flow", which is what we call "coming into the state" where they are focused on their work and completely out of the surroundings. Through absolute concentration, they forget the time and produce great code. This is the process by which they have finished their work. Writers, programmers, scientists, and even basketball players will tell you to get into the state.
The problem is that getting into the state is not that easy. When you try to think about it, it can take up to 15 minutes to start working at maximum productivity. Sometimes, if you are tired or have done a lot of creative work that day, you just can't get into the state, you'll spend the rest of the day fiddling with something, looking at the Web, or playing Tetris.
Another problem is that it's easy to get out of that state. Noise, come to the phone, go out for lunch, have to drive 5 minutes to Starbucks for coffee, and be disturbed by coworkers – especially when disturbed by coworkers – will pull you out of that state. If a colleague asks you a question that leads to a one-minute interruption, but this can be very tragic to get you out of the state, your phone for half an hour to become more efficient again, your overall productivity will encounter a lot of trouble. If you're in an environment where a caffeine-based internet company likes to create noisy barns, marketers screaming at the programmer's side of the phone, your productivity will fall sharply, because knowledge workers are interrupted again and again, and are never in the state.
This is even harder for programmers. Productivity relies on being able to juggle many small details in short-term memory at the same time. Any kind of interruption can lead to these details crashing down. When you start working again, you can't remember any details (such as the name of the local variable you just used, or the idea of a search algorithm you just came up with), you have to keep thinking about it, and it will slow you down until you become more productive again.
This has a simple algebraic operation. It can be said (with evidence) that if we interrupt a programmer, even if it's only a minute, we'll really lose 15 minutes of productivity. In this example, we assume that there are two programmers, Jeff and Mutt, in a standard adjoining open lattice. Mutt cannot remember the name of the Unicode version of the strcpy function. He can check it, it takes 30 seconds, or he can ask Jeff, which takes 15 seconds. Because he was sitting next to Jeff, he chose to ask Jeff directly. Jeff was distracted and lost 15 minutes of productivity (saving only 15 seconds of Mutt).
Now we have two of them divided into two offices separated by a door and a wall. If mutt forgets that function name, he can take 30 seconds to check it out, or spend 45 seconds asking Jeff, the process involves standing up (considering the average programmer's fitness this is not a simple task!). ）。 So he would choose to find out for himself. This mutt lost 30 seconds of productivity, but also saved Jeff 15 minutes. haha haha!
Do you use the best tools that money can buy?Using a home computer in a park to write code immediately in a compiled language is still one of the most impossible things to do. If your build process takes more than a few seconds, using the latest and most powerful computers will save you time, and when the compiler is running, the programmer will get bored, and this is when they switch to reading books, which will draw their attention and lose their productivity for a few hours.
Debugging GUI code with a single display is painful, and it's not impossible. If you're writing GUI code, two displays can make a lot of things easier.
Most programmers end up working with icons or toolbar bitmaps, but most of them do not have a usable bitmap editor. Trying to handle bitmaps with Microsoft Paint is a joke, but that's what most programmers do.
In my last job, the system administrator has been sending me automatic spam complaints that I used more than 220 megabytes of hard disk storage space on the server. I pointed out that the cost of these hard disk space was much lower than the cost of toilet paper I used, given the recent hard drive price. It took me 10 minutes to clean up my mailing list, which was a very absurd waste of my productivity.
Top development teams don't torture their programmers. Even the small setbacks caused by imperfect tools add up, making programmers grumpy and unpleasant. A grumpy programmer is not going to work.
Programmers are most likely to accept the coolest, newest things for bribes. It's a much cheaper way of getting them to work for you than to pay a competitive salary.
Do you have a test crew?If your team does not have a dedicated tester, at least two or three programmers should be equipped with a tester, you will write a lot of bugs in the product, or you spend money to let testers 30 knives per hour to do the work of 100 knives per hour of the programmer to do. The money saved by testers is an outrageous fake economy, and I just want to make more people realize that.
Does the person who is looking for a job write code during an interview?Would you hire a magician who hasn't seen his magic tricks? Of course not.
Would you hire a catering provider who hasn't tasted his food to serve your wedding? I doubt that.
However, day by day, programmers are hired through impressive resumes or because interviewers like to chat with them. Or they are asked a very thin question ("createdialog () and DialogBox () What is the difference?" "), these can be answered by reading the document. You don't care if they remember thousands of details about programming, you just care if they can write the code. Or, worse, they were asked, "Ah?" "The question: it's the kind of thing that you know the answer to seem simple, but if you don't know the answer, there's nothing to answer."
Please, don't do that in the future. Ask what you want to ask during the interview, but be sure to let the programmer write some code.
Would you do a corridor usability test?Corridor usability testing When you meet a passer-by in the hallway, you force him to try to use the code you just wrote. If you have done this to five people, you will learn the answers to the 95% practical questions you need to learn in your code.
Good user interface design is not as difficult as you think, if you want to let users like and buy your products this is very important.
But the most important thing about the user interface is that if you show your program to a lot of people (actually five or six is enough), you'll find the biggest problem people have. Even if your user interface design technology is not very good, as long as you force yourself to do the corridor usability test, there is no cost, and your user interface will be more and more better. Finish
12 ask yourself to do better programming
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
