BAZAAR LESSONS

A List of Lessons Learned
from The Cathedral and the Bazaar
by Eric Raymond

Lesson 1: Every good work of software starts by scratching a developer's personal itch.

Lesson 2: Good programmers know what to write. Great ones know what to rewrite (and reuse).

Lesson 3: "Plan to throw one away; you will anyhow." (Fred Brooks, "The Mythical Man-Month", Chapter 11).

Lesson 4: If you have the right attitude, interesting problems will find you.

Lesson 5: When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

Lesson 6: Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

Lesson 7: Release early. Release often. And listen to your customers.

Lesson 8: Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Lesson 9: Smart data structures and dumb code works a lot better than the other way around.

Lesson 10: If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

Lesson 11: The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

Lesson 12: Often the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

Lesson 13: "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."

Lesson 14: Any tool should be useful in the expected way, but a *great* tool lends itself to uses you never expected.

Lesson 15: When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and *never* throw away information unless the recipient forces you to!

Lesson 16: When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

Lesson 17: A security system is only as secure as its secret. Beware of pseudo-secrets.

Lesson 18: To solve an interesting problem, start by finding a problem that is interesting to you.

Lesson 19: Provided the development coordinator has a medium at least as good as the internet, and knows how to lead without coercion, many heads are inevitably better than one.

Please report errors to --> errors@alamut.com
This page was first created on --> 16/8/98; 8:29:50 CET
This page was last modified on --> 16/8/98; 8:38:00 CET