CSE350 Software Design and Engineering University of Pennsylvania Office: 254 Moore GRW, Phone: March 19 th, 2002

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

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

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

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

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

Set of “lessons learned”, III: l“Release early. Release often. And listen to your customers.” l“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: l“Smart data structures and dumb code works a lot better than the other way around” l“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: l“The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.” l“Often the most striking and innovative solutions come from realizing that your concept of the problem was wrong.”

Set of “lessons learned”, VI: l“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) l“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: l“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” lRecounts experience with fetchmail lAbility to absorb ideas lRole, almost, of (self-elected?) “editor” lLove, not money evident lTest/debug in parallel is very important So-called “many eyes” hypothesis Is it true?

“Many eyes” analytic benefits: lGoal: deliver a “software product” lSteps:%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 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 lNew software development methodology lEnabled by networks, interested community and IP licensing schemes lForces for and against – is it “Love vs. Money”, or something else entirely? lNext Tuesday: How Microsoft does it…