In ESR’s essays this week, he discusses the differences between cathedral-style software development and bazaar-style software engineering. Cathedral-style development occurs when a relatively small group of developers works on a project exclusively, releasing versions few and far between as the code is carefully curated and polished before any release. Bazaar-style software engineering occurs when development is open-source, releasing early and often, and allowing just about anyone on the internet to contribute.
I haven’t done a software engineering based internship, so I haven’t really been out there in the real world, but I think the development style in the classroom is more like the cathedral – writing and revising code in a small group (or individually, as I prefer) until we think it’s perfect enough to turn in for a grade. I don’t have any experience contributing to open source anything so project 3 shall be an exciting endeavor.
After reading “The Cathedral and the Bazaar” this week, I think the bazaar style of software engineering is probably the future – it worked out pretty well for Linux and ESR points out numerous advantages compared to the cathedral. I thought his point describing how having an insane number of users/co-developers working on a project online with the source code available makes it much faster to find and fix bugs made the most sense. Especially when ESR described the character of these hackers: “contributions are received not from a random sample, but from people who are interested enough to use the software, learn about how it works, attempt to find solutions to problems they encounter, and actually produce an apparently reasonable fix. Anyone who passes all these filters is highly likely to have something useful to contribute” (p.32). This just made logical sense and is probably why open source development has been so successful.
ESR describes 19 principles pertaining to software development and a few of them rang true to me. The first principle, “Every good work of software starts by scratching a developer’s personal itch” (p.23) is a little relatable and a little unrelatable. First, since basically the only coding I’ve done is for assignments and classes, I haven’t experienced this particular principle totally. However, last fall I did write some code for fun that kind of falls under the category of a personal itch. I was studying for computer architecture but I had done all the lectures and things I would normally do, so I (mostly for fun) wrote like three different programs in python to simulate concepts from class to help me study and make sure I knew what was really going on. I think I did a direct-mapped cache and a pipeline simulation and perhaps something else as well.
Principle #3 “Plan to throw one away; you will anyhow” also rang true in my experience in fundcomp. ESR says “you often don’t really understand the problem until after the first time you implement a solution” (p.25), and I found this especially true when I was learning to code for the first time. I think it was because we wrote all of those little programs from scratch, and because I never wrote psuedocode (bad habit yes but I was so young) so I would start a solution, realize during the process that I was approaching it incorrectly, and then restart based on the ideas I thought of while coding.
To conclude this blog post, I don’t think the two models are mutually exclusive if you consider ESR’s idea that users can be like co-developers. software could be developed cathedral-style and then the users are the ones to find the bugs after the release. It’s a little different than open-source because the code isn’t readily available, but similar idea.
nswatlan cse40842 blog 