Thoughts about the Cathedral and the Bazaar

The Cathedral and the Bazaar is a book, written by Eric S. Raymond, about two different styles of development: the “cathedral” model and the “bazaar” model; and also about all the lessons he learned when working with an open source software while testing the theories of software engineer suggested by the history of Linux.

From my own perspective, the cathedral and the bazaar development models are pretty much like the waterfall and agile development process respectively, because the cathedral is like trying to successfully finish all the steps in a process, and the bazaar is like working with almost everyone and releasing software fast in short time periods. Actually, I think that the waterfall and the agile development process came from the concept of the cathedral and the bazaar model.

Here are all the 19 lessons from Eric Raymond, most of them are easier to understand by just reading the sentence, but for other you need to read about what he was talking about to understand it.

1. Every good work of software starts by scratching a developer’s personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. “Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers
8. Given a large enough beta-tester and co-developer
   
   
   almost every problem will be characterized quickly and the fix obvious to someone
9. Smart data structures and dumb code works a lot better than the other way around.
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong
13. “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected
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!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

For more detailed information, visit this page.

My favorites are the number two and three. The others are important too, and I recommend to understand all of them, but only those three made me think over it a lot.

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

Before reading this, I always had the idea of doing new stuff from scratch because that way you get like the idea of “if you do it from zero, you will understand it better and learn more”, which is not actually false but it is not efficient because you lose lot of time. But like the lessons says: great programmers know what to rewrite; this means that being able to understand any other program is much better that know or learn how to do it by yourself.

“Plan to throw one away; you will, anyhow.”

Something notable form the document:

“Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once”.

I have experienced this myself many times not only in programming but in other things as well, when you try to solve a problem and you “succeed” or almost reached the solution, you notice a better way to solve the problem or notice that you started in the wrong direction and that you have to do it all over again. Which is actually not a bad thing, if you think about it, if you keep trying in the wrong path you will never reach the solution.