Home > Work > Joel on Software
1 " The Joel Test1. Do you use source control?2. Can you make a build in one step?3. Do you make daily builds?4. Do you have a bug database?5. Do you fix bugs before writing new code?6. Do you have an up-to-date schedule?7. Do you have a spec?8. Do programmers have quiet working conditions?9. Do you use the best tools money can buy?10. Do you have testers?11. Do new candidates write code during their interview?12. Do you do hallway usability testing? "
― Joel Spolsky , Joel on Software
2 " Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I'm behind schedule, I feel doomed and depressed and unmotivated. When I'm working ahead of schedule, I'm cheerful and productive. The schedule is not the place to play psychological games. "
3 " The confidence you get from knowing about every crash, anywhere in the world, is crucial to delivering a high-quality product that needs to be used in the wild. In the consumer software business, you can't rely on your customers to tell you about crashes—many of them may not be technical enough, and most of them won't bother to take time off of their own important work to give you a useful crash report unless you make it completely automatic. "
4 " We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds.There's a subtle reason why programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: They are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:It's harder to read code than to write it. "
5 " Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for. "
6 " In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix. "
7 " Where was I. Oh yeah. Sometimes it is not worth fixing a bug. Here's another bug that's not worth fixing: If you have a bug that totally crashes your program when you open gigantic files, but it only happens to your single user who has OS/2 and who, for all you know, doesn't even use large files. Well, don't fix it. Worse things have happened at sea. Similarly, I've generally given up caring about people with 16-color screens or people running off-the-shelf Windows 95 with no upgrades in 7 years. People like that don't spend much money on packaged software products. Trust me. "