I'm always struck by how everybody goes to a different conference. This was mine...
10-24-04 - Sunday, and 10-25-04 - Monday
"Usage-Centered Design in Agile Development", by Jeff Patton. This tutorial used a series of exercises to simulate how UCD works.
The Scrum gathering was a workshop gathered for a couple days in Denver, this past October. We worked in three groups: metrics, process, and facilitation. (Scrum is an agile process. I think of it as approximately the project management part of XP, though that's of course not fair to either one:)
I participated in the facilitation group.
Sven Gorts has introduced what he calls Refactoring Thumbnails. These are UML-like diagrams augmented with some flows, and used to summarize refactorings. (For example, the UML might have no words, but rather squiggles to represent identical text in two different classes.)
The Napkin look-and-feel is designed to look like it's drawn on a napkin. The idea is that when the UI is at prototype level, the screens look that way. What a clever idea!
Most LAFs leave me a bit cold - they're changing things for the "cool" factor, not for any user benefit. This one is different - there's a reason for it. Two thumbs up!
Someone asked on the XP egroup about getting access to private methods for testing purposes. Others suggested a number of ways to get this effect, but it got me thinking about refactoring.
Refactoring is often thought of as a pure, safe transformation: convert a program into another program with the same semantics but a better design.
I recently had a chance to do some refactoring of some Visual Basic code. I hadn't worked with it in several years. In particular, I hadn't worked with the object support that's in VB.Net. It's very striking how much it's like C# with different keywords.
Test-Driven Development is a style that says "write a test for a small bit of functionality, write code to make it pass, refactor, and repeat."
Test-driven development uses a tight cycle of "test, code, refactor" to develop software.
A traditional project plan has an ethos, "Plan the work, work the plan." The planning process will work out all the expected tasks, estimate them all, and assign workers to the tasks. This has several problems: the sheer mass of data makes it hard to see what's really important, the plan is vulnerable to changes in direction, and it's hard to keep up to date.
I'm reflecting on the most important tools I've been using this past year for my Java projects.