Swamped and stuff

Just when I was getting into a rhythm with my blog postings, I had to drop out for a while because of increased work load. Plus I started to work with Titus on an application we'll present at our "Agile development and testing in Python" tutorial at PyCon 06. And here's where the "stuff" part of the post comes into play. We've been developing and testing for a week now, and it's been a most enjoyable experience. I won't go into details about the app itself, which is still in its infancy/prototype stage, but here are some methodology ideas we've been trying to follow:

• 1-week iterations
• We release working software every 3 weeks
• 10 iterations and 3 releases until Feb. 23rd (PyCon'06 tutorial day)
• Enter releases as milestones in Trac

• Features are developed as stories
• A story should fit on an index card
• During each iteration, one or more stories are completed
• A story is not completed if it is not tested
• Two types of tests per story
  • Unit tests
  • Functional tests (at the logic layer, not the GUI layer)
• We package the software continuously (every night) using buildbot
• We also run unit test and a smoke test (a subset of functional tests) every night via buildbot
• Before each release, we also test at the GUI layer
• Before each release, we also run performance tests
• We file bugs using Trac's ticket system
• Think about using burndown charts (see XPlanner for ideas)

We haven't hit all of these items yet, but we still have some time until our first release, which is slated for Dec. 31st. Here are some random thoughts that belong in a "Lessons learned" category.

Remote pair programming/testing rocks
It's amazing how much difference a second brain and a second set of eyeballs makes. Although Titus and I haven't practiced "classical" pair programming, we've been going back and forth via email and have added code and unit tests almost in real time, so it felt to me like we were pair programming. Having another person integrating your code and your unit tests instantly and giving you feedback in the form of comments/suggestions/modified code/modified unit tests goes a long way towards greatly improving the quality of the code.

Learning new code by writing unit tests rocks
I think I first read about this concept in one of Mike Clark's blog posts, where he was describing his experiences in learning Ruby by writing unit tests for simple language constructs. I found that writing unit tests for a piece of code that's not mine is an amazing way of learning and understanding the new code. Generally speaking, I find that there is no way to write quality code if you don't write unit tests. What we've done so far in this project is not quite TDD, but it's close. I'm tempted to call it TED for Test Enhanced Development: you write some code, then you start writing unit tests for it, then you notice that the code doesn't quite express what you want, then you modify the code, then you add another unit test, etc. It's a code-test-code cycle that's very tight and makes your code airtight too. In this context, I'd also like to add that coverage rocks: we've been using Ned Batchelder's coverage module to keep track of our unit testing coverage. It's well known that no code coverage metric is perfect, but the coverage percentage reported by the tool at least keeps us honest and makes us strive to improve it.

Trac rocks
Trac proved to be absolutely essential for our "agile" approach to development and testing. Trac combines:

• a Wiki -- which allows easy editing/jotting down of ideas and encourages brainstorming
• a defect tracking system -- which simplifies keeping track of not only bugs, but also tasks and enhancements
• a source browser -- which makes it easy to see all the SVN changesets
• a roadmap -- where you can define milestones that are tied into the tracker
• a timeline -- which is a constantly-updated, RSS-ified chronological image of all the important events that happened in the project: code checkins, ticket changes, wiki changes, milestones