Typical software firm (mostly based on my Netscape experience)
  Programmers, junior and senior
  Directors / architects
  Managers (often worried about schedule)
  Q.A. staff, junior and senior
    - automated Q.A. tools
    - regression testing
  Build masters 
  - describe Netscape "tinderbox" automatic builds
  - tell story of Tara & her tequila @ Netscape
  - talk about being "on the hook"
  Elaborate bugs database
  - bugs are assigned, prioritized, "latered"
  - source code comments reference bug numbers
    - XXX comments
  - bugs database == "to do" list
  
  Footnote: cost of finding bugs
  - if programmer finds it, can fix immediately
  - if Q.A. finds it, has to isolate the bug, make it repeatable, and
    track down responsible programmer
  - if hand-picked beta user finds it, Q.A. has to figure out whether
    it's real, etc.
  - lower quality bug reports from normal users --> higher Q.A. cost
  
  ==> getting it right early saves development cost
      (but, shipping late costs market share!)
  
  Source code repository & basic CVS concepts
  - checkin / checkout, locking vs. concurrent
  - regressing a bug
  - forking and merging the tree
  - some organizations have strict rules about what gets checked in
  
  Typical lifecycle:
  - Ship version N
  - Everybody has wish list for version N+1
    - Some changes incremental, others revolutionary
      - Do you fork the tree and split your developers?
    - Some requirements come from customers, others from bug
  - Estimates of how much time is necessary and what dependencies exist
  - Tools like Microsoft Project track dependency graph
  - Weekly status reports, often including bug numbers
    - help managers update dependency graph
  - The release pipeline
    - Series of 'beta' releases
    - Bugs labelled with target beta releases
    - Code freezes, as ship date approaches
  
Okay, how do specs really happen?
  Example: Java JAR file spec
  
  Problems to solve:
  1) transmitting lots of .class files over the network is really slow
  2) need a digital signature scheme for security purposes
  
  (digression on what a digital signature is)
  
  Initial proposal from Sun: add signature inside the .class file
    Ugly problem: how do you avoid checksumming the part where the
      signature goes?
    Also, doesn't do anything to solve the transmission problem.

  Initial system inside Netscape 3.x:
    - use uncompressed Zip files to hold all the .class files
    - extend <applet> tag to have "archive" attribute
      - defined semantics: get classes first from archive, then codebase
  
  Sun/Netscape meeting
    - much wrangling over how to hide a signature inside a .class file
      (ugly because of class file structure)
    - bright idea: external signature files in their own subdirectory
      - allows the use of any packaging technology (zip, tar, ...) or none
    - next question: what's the format of the spec files?
      - if we were doing it today, it would be XML
      - back then (1996) we chose RFC822 (e-mail header) style
      
  After meeting, written up as a document and became the JAR spec

Okay, how do implementations really happen?
  (or, how not to implement a system)
  
  One Netscape guy assigned to do it, some security experience
  
  1) wrote everything in C from scratch (reuse of existing crypto code?)
  2) signing tool was flakey
  3) browser integration was late
  
  Ended up having a multi-day code review (painful)
  
  
  Meanwhile, Sun rolled their own version, using pure Java
  
  Sun and Netscape turned out to be incompatible because they used
  different cipher suites.
  
How *should* we have done it?
  1) figure out what's already out there
     - pre-existing Zip library support (in C)
     - pre-existing crypto libraries, both in C and Java
       - C support already inside the browser, no Java
     
  2) identified "soft" places in the spec and had required/optional profiles

  3) better implementation strategies
  
  4) having a scheduled "bake-off" to insure implementations are compatible
     (used often in the networking community)
     
If *I* was king for a day
  - Start with pure-Java prototype implementation
    - Borrow crypto classes from elsewhere
      - Punt on the problem of access to browser key store
    - Get it working soon
      - Java code can be shipped in private beta / developer releases.
        Even if it's slow, it's stable.
    - Build hooks into the native runtime following existing interfaces
      - Requires studying interface of Java crypto library and C crypto
        library and figuring out whether they're compatible

  - And speaking of ugly
    - Untrusted code can be running in the browser's JVM
      - Access to browser's key store can be dangerous
    - Crypto export regulations (thankfully no longer a problem)
    
  - Footnote on security issues
    - Designing great interfaces is fun, but you have to figure out
      if you're in a hostile environment or not
      - Talk about Richard Smith's ActiveX "safe for scripting" discoveries