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.

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?

In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.

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.

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.