CSE350 Software Design and Engineering

CSE350 Software Design and Engineering University of Pennsylvania http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 March 19th, 2002

Administrative • Final project code will be due by class time (9:00A.M.) on April 18th (19th ends classes) • Demos: • Scheduled during final exam period • One hour per group – presentation + demo • All group members must be at demo • Can hand in any project experiences, documentation, “lessons learned” at demo

“The Cathedral and the Bazaar” • Written by Eric S. Raymond (Penn!) • Codified much of the “open source” ideas, independent but cognizant of, FSF (inspired by Linux not Marx?). • Epiphany came from own experience, with a tool called “fetchmail” • Principles inferred from experience

Experience with “fetchmail” • Program to retrieve mail from a server • Needs to get various things “right” to be seamless and easy to use • Raymond started out trying to solve his personal problem (often best motivation) but also wanted to experiment with methodology • Best ideas came from someone else, comments and suggestions from user community • Judgement: it worked!

Set of “lessons learned”, I: • “Every good work of software starts by scratching a developer’s personal itch” • “Good programmers know what to write. Great ones know what to rewrite (and reuse)” • “Plan to throw one away; you will, anyhow” (quote from Brooks, Ch. 11)

Set of “lessons learned”, II: • “If you have the right attitude, interesting problems will find you” • “When you lose interest in a program, your last duty is to hand it off to a competent successor” • “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging”

Set of “lessons learned”, III: • “Release early. Release often. And listen to your customers.” • “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone” (can be restated as “Given enough eyeballs, all bugs are shallow”)

Set of “lessons learned”, IV: • “Smart data structures and dumb code works a lot better than the other way around” • “If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource”

Set of “lessons learned”, V: • “The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.” • “Often the most striking and innovative solutions come from realizing that your concept of the problem was wrong.”

Set of “lessons learned”, VI: • “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away” (Antoine de Saint-Exupery) • “To solve an interesting problem, start by finding a problem that is interesting to you.” (I skipped a few before this)

Set of “lessons learned”, VII: • “Provided the development coordinator has a medium as least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one” ( opposite Brooks )

Summary of “C&B” • Recounts experience with fetchmail • Ability to absorb ideas • Role, almost, of (self-elected?) “editor” • Love, not money evident • Test/debug in parallel is very important • So-called “many eyes” hypothesis • Is it true?

“Many eyes” analytic benefits: • Goal: deliver a “software product” • Steps: %effort | %life -----------|----- • Design 33.3% | 3.3% • Implement (Code) 16.7% | 1.7% • Test 50% | 5.0% • Deploy | • Maintain | 90.0%

Not a “silver bullet” • “… As an experiment I also planted a comment which should raise eyebrows in some code I released years ago and which is fairly widely used just to see if I’d get any reaction from anyone (the comment says, in effect, ”Something really suspicious could happen here”, although that’s not the real text so you can’t just grep for it to find it :-). Noone has ever asked me about this, from which I assume that noone’s ever looked at the code they’re using. That’s kind of scary, because the comment isn’t in there just to annoy people, you really could build a rather nasty backdoor in there. There may actually be products out there which are released in binary-only form where the vendor has built in a backdoor at that point, although I saw a posting from foo@anon.org in alt.2600 saying he’d looked at the product and it was fine, so it must be OK.” – Peter Gutmann, on Peter Neumann’s “Robust Open Source” mail exploder

“Open Source” Summary • New software development methodology • Enabled by networks, interested community and IP licensing schemes • Forces for and against – is it “Love vs. Money”, or something else entirely? • Next Tuesday: How Microsoft does it…

CSE350 Software Design and Engineering