CSC223 2004F, Class 15: Extreme Programming (2)

Admin:
* Hear Arjun talk at 4:30 today.  Earn extra credit by going.  Earn even more extra credit by asking him (relevant) questions he can't answer.
* Cool convo tomorrow in Harris.  Earn extra credit by going.
* Advance warning about Sam's absences: Oct. 13 and 15
  * Hmmm ... maybe no class
* Never say "I promise I won't miss another class" unless you're willing to accept the consequences.
* Friday: JUnit (How many know it?)

Overview:
* XP, Reviewed
* Remaining components
  * Principles
  * Activities
  * Practices
* Designing a unit testing suite: An exercise in XP

/XP Basics/

* Lightweight design methodology.
* Intended to support key values of
  + Communication
  + Feedback
  + Simplicity
  + Courage

/Basic Principles/

* Suggestion: Principles are the activities you engage in to meet the values
* WRONG!  Principles != activities.
  * Principles guide which activities you do and how you do them
  * He gives us a separate list of activities

* Rapid feedback (value becomes principle)
* Assume simplicity (value becomes principle)
* Incremental change (simplicity plus feedback)
* Embrace change (courage)
* Quality work (precondition) <- core value?

/Additional Principles/

* Teach learning: Don't say "thou must"; structure the environment so that people learn experientially
* Small initial investment: Not many people, not much money, not much functionality
* Play to win: Desire success (stupid basketball metaphor) offensive vs. defensive (don't play not to lose)
* Concrete experiments: Try things, don't just theorize
* Open, honest communication
* Work with programmers' insticts, not against them
* Accept responsibility
* Local adaptation
* Travel light: "Don't expect to carry a lot of baggage and move fast" Keep only the necessary stuff.  Throw away 'cruft'.  Eliminate red tape.  (Who cares about design documents, documentation, and all the stuff that's not code?)
* Honest measurement: Use vague numbers (two or three weeks)

/Detour: Documentation/

* Theory one: Documentation is like testing: Document as you code.
* Theory two: Documentation is like baggage.  Your code will change, so don't carry the documentation with you.
* Theory three: Design a little, test a little, implement.  Documentation is design.

/Activities/

* Coding
* Testing
* Listening (includes "thorough communication")
* Designing (includes documentation by fiat of SamR)

Other activities?
* Playing with toys
* Eating while programming
* Eating after a task is complete
* Rearranging furniture
* Insulting anyone who is not a programmer, but in a positive way

/Practices/

* The Planning Game: Get together (programmers,customers,coaches/managers,groupies) and decide what you're going to do and when.
  + Customers prioritize goals
  + Programmers estimate timeframe
  + Manager helps balance, so that sufficient goals are completed within a short period
  + Academic: Make sure to meet with your prof early.
* Small releases
  + Academic: Implement one or two features at a time.
* Metaphor
  + Academic: More or less the same as industry.  Come up with one.
  + Why do we need a metaphor?  Get it out of technical language.
* Simple design
  + Academic: Agh!  We like to generalize.  Try not to.
* Testing
  + Academic: Yes, but we need to learn how.
* Refactoring
  + Academic: Yes
* Pair programming
  + Academic: But ... schedules don't always work; We have smaller teams.  Try to make your schedules work.
* Collective ownership
* Continuous integration
  + Academic: Plan two-three hour shifts.  Implement for an hour.  Integrate as long as it takes.  
* 40-hour week:
  + Academic: Not for one class.
  + Academic: Hah!
  + Thought question: If we buy Beck's claim that 40-hour-weeks let you do better work, how do we get students to do 40-hour-weeks?  How about 50-hour-weeks?
* On-site customer (assumes large enough client)
  + No.
* Coding standards
  + Academic: Yes!

How big do these teams get?
* Claim in book is for "moderate-size team" (< 20 people, typically 10)

Which of these apply in an academic/class setting?