dark mode light mode Search Menu
Search

The Cathedral and the Bazaar

Adbdulaziz Ceylan on Flickr

Software is created through sharing code in groups, like a chaotic bazaar, or built like a cathedral with experts who develop then execute a careful plan. While you might think decentralized groups working on one large software project is doomed to fail, in many cases a group develops software faster with less errors.

Arriving along with public access to the internet, email, and the rise of the web, in the early 1990s, the Linux operating system used a large decentralized group of volunteer programmers to develop highly stable world class software with source code available for free.

Until then, operating systems were built by companies with dedicated teams and top down leadership. Source code was guarded and rarely shared outside of proprietary companies or groups. Linux showed sharing source code openly online led to more stable code. And leadership based on a common understanding of problems and possible solutions led to better software design and code.

In 1996, having experienced the often chaotic development of the Linux operating system, Eric S. Raymond wrote an essay, The Cathedral and The Bazaar, that summarized what he experienced. The essay is a key piece of computing history and useful for programmers to read today. Along with Linux and a few other projects, the essay helped gain acceptance for a very different way to develop software.

Raymond’s essay is particularly insightful about the best ways to develop software and the traits of great software programmers. For example, if a piece of software provides only some of what you need, which choice is better: add to the software or build a new application?

Raymond argues the best programmers extend software instead of creating new software (unless there is no choice, of course). Linux started by extending Minix, a tiny operating system for computer clones, using it as a scaffold to build a new operating system that eventually replaced all the original Minix code.

As Raymond says in his essay, “While I don’t claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it’s almost always easier to start from a good partial solution than from nothing at all.”

Another insight came from a book by Fred Brooks, The Mythical Man-Month, published in 1975, which explores the reasons software projects often fall behind schedule, especially if programmers are added to a late project. If one programmer could code a software application in 12 months, it is not true that 12 programmers could do the same work in 1 month. Depending on the complexity of the application, 3 software developers might be able to do the work in 6 months that 1 coder can do in 12 months.

The Mythical Man-Month book also offers another insight about programming: you don’t begin to understand a software development problem until you create a solution in code. The tradeoffs you make plus the strengths and weaknesses of your code reveal better ways to recode your software application. Raymond, and Brooks, believe good programmers should build multiple solutions, that it is better to start over with the right idea bsed on experience than go back and fix a broken solution.

The often chaotic experience of working on the Linux software development project, where groups of people worked together to solve technical problems and write code, also led to another funny quote and insight about the best way to create software.

When Raymond mentioned to Linus Torvalds, the creator of the original Linux kernel, the key part of the operating system, that creating the kernel was less important than creating the community model to develop the software, Torvalds answered, “I’m basically a very lazy person who likes to get credit for things other people actually do.”

Are good software programmers really lazy?

Reading The Cathedral and The Bazaar makes it clear good programmers know when to engage and when to step back. They listen to the problem, possible solutions, people working with them, people who use their software, and other inputs. At times a good programmer needs to step in, other times not. It’s less laziness and more about listening and calculation.

Another interesting aspect of software development has to do with bugs, errors in the code. In 1991, Linus Torvalds released a new version of the Linux kernel every day at one point. The community of developers who wanted to use Linux happily helped him test each release which, in turn, found and fixed many bugs.

When software is built like a cathedral, bugs are hidden from users. This slows down the software development process because it takes longer for a dedicated team to find and fix each bug. A community of programmers often will find and fix these errors more quickly and thoroughly. Instead of one or two releases a year, a dynamic community can release four or more new versions of a software application. Frequent releases haev become the norm since Linux and similar projects started.

Finding and fixing bugs also scales while developing software does not. A hundred programmers inspecting and using software to find then fix errors will make the software highly stable in a short time. The same hundred programmers, however, could not build the software application more quickly than a handful of programmers because of the time required to organize and manage their efforts.

Perhaps the biggest benefit from reading The Cathedral and The Bazaar today are the insights into how programmers work, and what works best. The essay footnotes and references also lead to more books, essays, and people who provide added insights and context for programmers and would be programmers.

Much of The Cathedral and the Bazaar discusses what interests programmers and how interest in solving a problem is the key to great software and programmers. Building stuff is one of the joys of programming and the process of building is full of engaging detours. The journey often is equal or greater than what you build.

Learn More

The Cathedral and The Bazaar

http://www.catb.org/esr/writings/cathedral-bazaar/
http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

The Mythical Man-Month

https://en.wikipedia.org/wiki/The_Mythical_Man-Month