CSE350 Software Design and Engineering

1
CSE350 Software Design and Engineering

• University of Pennsylvania
• http//www.cis.upenn.edu/jms
• Office 254 Moore GRW, Phone 8-9509
• March 19th, 2002

2
Administrative

• Final project code will be due by class time
  (900A.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

3
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

4
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!

5
Set of lessons learned, I

• Every good work of software starts by scratching
  a developers 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)

6
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

7
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)

8
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 theyre
  your most valuable resource, they will respond by
  becoming your most valuable resource

9
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.

10
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)

11
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
  )

12
Summary of CB

• 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?

13
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

14
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 Id get any reaction from
  anyone (the comment says, in effect, Something
  really suspicious could happen here, although
  thats not the real text so you cant just grep
  for it to find it -). Noone has ever asked me
  about this, from which I assume that noones ever
  looked at the code theyre using. Thats kind of
  scary, because the comment isnt 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_at_anon.org in alt.2600 saying hed looked
  at the product and it was fine, so it must be
  OK. Peter Gutmann, on Peter Neumanns
  Robust Open Source mail exploder

15
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