Home > Author > Joel Spolsky
1 " Listen to your customers, not your competitors. "
― Joel Spolsky
2 " Usability, fundamentally, is a matter of bringing a bit of human rights into the world of computer-human interaction. It's a way to let our ideals shine through in our software, no matter how mundane the software is. You may think that you're stuck in a boring, drab IT department making mind-numbing inventory software that only five lonely people will ever use. But you have daily opportunities to show respect for humanity even with the most mundane software. "
― Joel Spolsky , User Interface Design for Programmers
3 " In any case, even if a usability test resolves a dispute, it doesn't do it in any kind of a statistically valid way. Unless you test thousands of people from all walks of life under all kinds of conditions, something that not even Microsoft can afford to do, you are not actually getting statistically meaningful results. Remember, the real strength of usability tests is in finding truffles—finding the broken bits so you can fix them. Actually looking at the results as if they were statistics is just not justified. "
4 " I've grown to think that keeping your desk clean is actually probably a sign that you're not being effective. "
― Joel Spolsky , More Joel on Software: Further Thoughts on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
5 " 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
6 " 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. "
7 " 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. "
8 " 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. "
9 " 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. "
10 " In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix. "
11 " 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. "
12 " If you can’t understand the spec for a new technology, don’t worry: nobody else will understand it either, and the technology won’t be that important. "
13 " An idea isn't worth that much. It's the execution of the idea that has value. If you can't convince one other person that this is something to devote your life to, then it's not worth it. "
14 " When you're designing for extremes with software, the three most important "extremes" to remember are: 1. Design for people who can't read. 2. Design for people who can't use a mouse. 3. Design for people who have such bad memories they would forget their own name if it weren't embossed on their American Express "
