Reading 07: The Cathedral and the Bazaar

 In The Cathedral and the Bazaar, Eric S. Raymond (ESR) explores two distinct software development models: the cathedral and the bazaar. ESR describes the cathedral as “carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time”. ESR saw this approach to development as better for more complex problems, such as the larger tools he had developed in the 90’s, and it encompasses much of what I have seen in my short tenure as a software developer in the real world. For every project I have worked on, there has been a project lead with (mostly) absolute power over its process and result. In my experience, the cathedral model has been effective at keeping teams on task, but it also keeps the project rigid in scope and prevents some great ideas from coming to fruition. I see less collaborations between teams with reasonably consistent results.

ESR describes the bazaar model of software development as “a great babbling bazaar of differing agendas and approaches… out of which a coherent and stable system could seemingly emerge only by a succession of miracles.” This approach, exemplified by open-source projects like Linux, involves a collaborative and decentralized environment where developers with various interests and motivations contribute to the codebase. The resulting product tends to be incredibly dynamic and flush with ideas from a large base of testers. I do not have any personal experience with the bazaar method of development, but ESR does an excellent job selling the idea. A collaborative environment with effectively unlimited testers and constant aid from others sounds like a dream to work in professionally. I cannot help but wonder how company politics and in-fighting would practically disappear when teams did not feel the need to compete for budget or status. I am excited to see how open-source development feels when we work on our final class presentation.

Of the 19 lessons that ESR detailed in his essays, I found #3 and #7 to be the most relatable to my experiences. Lesson #3 states that you should “plan to throw one [version] away; you will, anyhow.” Whether it be for my job, a class assignment, or a personal project, I always do end up throwing a version of my work away. I always strive to develop a proof of concept that usually helps me better understand the problem at hand and build off of it in a better way. Lesson #7, which states that you should release and often with customer input, is also particularly relatable to my development habits. I am abysmal at pacing myself, so scheduling releases to be frequent helps me keep up with intended goals. The feedback I get from these frequent releases tends to drastically change my projects for the better.

For the future of software development, I would have to say that the bazaar model reigns supreme. The amount of time and resources that an open community can provide to a project trumps the finite abilities of closed firms using the cathedral model. However, the two approaches can clearly co-exist in the present as long as large companies continue to have the capital to spend on the same power that open-source communities provide for free.

Comments

Post a Comment

Popular posts from this blog

Reading 02: Hardware Hackers

An ethical debate between "True Hackers" and "Hardware Hackers" is not something I had in mind when I first heard each of the individual terms. Both groups were stereotypical nerds who abhorred sleep schedules, were "afraid of women", and simply loved all things tech. I did not think there could POSSIBLY be a divide between these two groups. After all, how much disagreement can there be over a 6-part ethical code dedicated to spreading awareness and practicality for computers? The answer may shock you. "True Hackers" wanted to keep their ideas locked behind a certain barrier to entry, namely how they judged your ability and character. While I can understand this, I think that "Hardware Hackers" had a much more reasonable approach to the Hacker Ethic: make computers more accessible by any means necessary. By spreading access to computers beyond college club rooms, more people could slip past the elitism of computing that had existed in i
Read more

Reading 01: I Hack, Therefore I Am

  My first introduction to the idea of a "hacker" came from playing video games as a kid. I was terrible at most of the video games I tried, but this barrier was not going to stop me. When I eventually got access to the internet, I found my saviors in the form of video game "hackers". These mystical figures could find every bug, exploit, and cheat to let me bend the rules. As I grew older, this idea of "breaking the rules" is how I envisioned hackers. While the means and purpose always vary, hackers beat the system in ways not intended. However, I would not say that I took this idea too seriously. Pop culture painted hackers as stereotypes with few aspirations, which did not catch my interest as a kid. The video from the second lecture titled "Hackers - Technobabble" really summed up how I saw hacking as a whole. This reading from Steven Levy gave me an entirely new perspective on the idea of hacking. Levy describes "true hackers" as pe
Read more

Reading 03: Game Hackers

  Early hackers viewed programming as a point of pride, something to perfect and show friends like a trophy of your abilities. However, as computers finally became more accessible to everyday people outside of college campuses, a new marketplace was created for the world of software. A third generation named “Game Hackers” saw monetary value in computing and changed the focus of hacking from progress to profit. “Game Hackers” valued ability and rewarded it better than their predecessors ever could, but their idea of perfection was wildly different. “Game Hackers” preferred “less polished programs that shipped on schedule” (Hackers p. 334, Steve Levy) to a program that was the fastest or most resource-efficient. Marketing the product instead of perfecting it was the real focus, since that is what sold the most games. Ken Williams sums up this shift best in Steve Levy’s book, saying “"We'll lose our dependence on programmers. It's silly to think programmers are creative. I
Read more