Session 7

TDD Exploration for the Project

810:188
Agile Software Development

Follow Up on Reading

... Ward Cunningham on the debt metaphor.

• ... debt metaphor. There can be others, for different audiences. Example: training deficit, for runners.
• Ward is a giant of software development: Smalltalk, creator of wiki, design patterns, XP/agile (especially pair programming, test-driven design, refactoring), automated acceptance testing, ...
• "Ward number"

... Jason Fried on No Functional Spec.

• Word docs and spreadsheets versus index cards and Post-It notes.
• How can this work? Communication, code. Small teams. (Is small teams really just for agile?
• We won't use the UIK to drive development. We will write tests and small bits of functionality, with lots of interaction between team and customer.

Toward a Syllabus

This is how we will assign grades:

• 10% -- class participation
• 10-15% -- homework
• 80-75% -- group project

Grades for the group project will be based in part on contribution to the code base, use of the XP practices we learn, and peer evaluation.

Exploratory Programming on the Project

We discussed the one-page story you were asked to write. I read Nate's, which most closely reflects what I would write. I will post mine on the course wiki.

We discussed the project requirements and stories more. The ended up thinking that starting with a single general journal for all transactions would simpler for the team, and I as customer agreed. So we adjusted our thinking and our stories.

We paired up, took a simple story, wrote a test, and wrote code. The story:

Record a check written for cash in the amount of $100.

Some pairs started working on a second story; others tried to forge ahead even further. By writing even one test, the team learned some new things about the system to be built. For example,

• A transaction is atomic. You can't add a debit to a journal independent of its balancng credit.
• Recording a transaction does not update any account. That happens when the journal is closed at the end of the period.
• There is a difference between the model (the core computation and data of a program) and the view (the way users see or experience the program). We can and usually should think about these parts of our program as independent.

The first two lessons are are about the domain. The last is about software design. Both kinds of lesson are good ones for a young team to to learn, or be reminded of, while building this system.

We took a second story:

Record receipt of a $200 paycheck, with $100 going to my checking account, $20 to my prepaid medical expense account, and $80 to income tax withholding.

Again the team learned something: A transaction must may consist of multiple debits or credits. This also means that a transaction must be able to record multiple amounts (unlike in the first story), because several debits may total up to the value of single credit.

Each little bit of learning helps us to grow the design of our system, from something perhaps as simple as a string to a simple collection (say, a Ruby array) of string/number pairs.

Wrap Up

• Homework. Download and install a git client for your laptop. There are instructions there, but you can also move on to...


• Reading. Read Git for the Lazy. It's not so much for the lazy as for newbies to git. It does seem to presume some experience with version control.

  Here is the official git tutorial man page, which may also be useful to you, though it seems also more useful to programmers who have already used a version control system.

  This page on Everyday Git is a short listing of the basic commands different kinds of users need when working in git. Again, it seems to presume experience with version control.

  I will try to find (or write) a simple set of instructions for using git aimed at more novice programmers.

  (The HgInit tutorial you read over the weekend is a good general description of the ideas behind distributed VCS and thus about how git works, but its details are all about Mercurial.)



• Programming. And keep practicing Ruby.