Joel on Software - a summary: 2001.

This is a summary for the blog by Joel Spolsky, Joel on Software, volume 2001. The summary for the years 2000-2010 can be found on the Joel on Software summary index page.

---

Don't grow faster than you can find talented people. Some things need talent to do really well, but talent is hard to scale. Having the talent create rules for the untalented ("The Methodology") results in very low quality. -- Big Macs vs. The Naked Chef

Everything you ship to customers should be produced by the daily build process. -- Daily Builds Are Your Friend.

Never let people work on more than one thing at once. Programming is the kind of task where you have to keep a lot of things in your head at once. Therefore task switches take a really, really, really long time. -- Human Task Switches Considered Harmful

A company with a personal voice is attractive, because we are humans. -- Spring in Cambridge.

It makes no sense to optimize software by reducing the size of it, since storage is cheap, but programmer's aren't. -- Strategy Letter IV: Bloatware and the 80/20 Myth.

Architecture Astronauts add so many levels of abstraction that the resulting ideas are completely useless and incomprehensible. They throw bombastic whitepapers at problems that don't need to be solved. -- Don't Let Architecture Astronauts Scare You
If you want something to be The Next Great Thing it has to be more than architecture, it has to enable things that people really need. -- Are the Groove Designers Architecture Astronauts?

If your business plan includes projections from IT research firms, you better start planting tomatoes. -- Blogpost on 2001/04/18

Eating your own dog food can be disgusting, but that is precisely why you have to do it. -- What is the Work of Dogs in this Country?

If Microsoft were to concede the slightest point in an anti-trust case, hundreds of independent software companies would see this as their opportunity to enter Microsoft's markets. -- Michael E. Porter's Competitive Strategy
(Actually the point this article is trying to make is "you should analyze your competition and try to guess how they will react to your move", but I found the former sentence somewhat more appealing.)

Good software, like wine, takes time: probably ten years to become really good. Take this into account in your business model. -- Good Software Takes Ten Years. Get Used To it.

Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it. The advantages of fixing a bug are: better reputation, less time wasted with tech support, you might charge more for the product. -- Hard-assed Bug Fixin'

If it's a core business function - do it yourself, no matter what. -- In Defense of Not-Invented-Here Syndrome.

VB is not cool because your code doesn't have {'s and }'s. I can live with the shame if it means I'm more productive. -- Working on CityDesk, Part Three

Nowadays a good programmer spends a lot of time doing defensive coding, working around other people's bugs. -- Working on CityDesk, Part Four

Joel points the reader to "Guidelines on Writing a Philosophy paper" by Jim Pryor. This article has some important points on writing, such as:
Don't write using prose you wouldn't use in conversation. Make the structure of your article obvious. Pretend that your reader is lazy, stupid, and mean.

Be pragmatic in your choices and don't necessarily follow the lastest hype. -- Working on CityDesk, Part Five

The stricter the API is about its input, the more likely the code is going to work in funny situations. -- A Hard Drill Makes an Easy Battle

Modern programming languages might give the impression that you don't need to understand the underlying concepts anymore. But this is not true. Some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels. -- Back to Basics.

If you're not in a position to force changes to the development process, you still can initiate improvements. 1. Just do it yourself. 2. Find the people who are willing to improve and capable of it, and get them on your side. 3. Let bad programmers solve their own problems, this will occupy them for months and prevent further damage. 4. Get Away From Interruptions. 5. Keep doing your normal work to avoid bad reputation. -- Getting Things Done When You're Only a Grunt.