Is XP Unsuitable for a Diverse Team?
A post on Twitter claimed that Agile won't work for a heterogeneous team because it's practices were developed by a "bunch of white dudes." While that isn't something I want to believe, the comments indicated that many folks did believe it. When a large body of opinion contradicts my assumptions, I like to pause for thought.
Untapped Resources of Agility
Last week I attended the first XP Day France, where I had been invited to give the keynote. We don't see many attendees from France at the European XP events, which is too bad, because the quality of the presentations was impressive. I'll be blogging separately about some of the things I learned.
We could all benefit by hearing more from these folks and I think they would also benefit from being part of the larger events. I hope some of the folks I heard speak here in Paris will turn up for XP2006. If language is an issue for some, I'd be glad to help.
What's a Test Worth?
In a discussion about unit-test suites that take too long to run, Ron Jeffries writes
Splitting the tests into slow and fast is a tradeoff, and it's an easy one. But is it ideal? I think not. I think a better approach might be to split the tests into "likely to provide interesting information" and "unlikely to do so". Then make the ones that are likely, also fast.
This struck me as an interesting point. If the value of a test is seen as the amount of information it is likely to provide and the cost is - at least in part - the time to run it, then the problem of which tests to keep in that "too slow" test run is quite similar to the value versus cost balancing problem we face in XP when we schedule stories into an iteration.
Project Turnaround: XP to the Rescue?
In July of 2001, I spent three weeks trying to turn a project around. I had only recently learned about Extreme Programming and this was my first attempt at using it. The short-term results were quite spectacular, the long-term, less so.
Test-First Challenge - Table Model
So we're evaluating expressions. Now we are to create a two-dimensional adapter for Sheet so cells can be referenced by row and column. Since this specific interface is aimed at a Java-based GUI, I'm not really sure if I need all of it. But I've put it together quickly using the tests Bill supplied.
Test-First Challenge - Cell References
Having built the parser in Part 2 and cleaned it up in my Refactoring Interlude, I'm now ready to handle references to cells in the formulas. First step is to have a new token type that handles "names". I made these be any span of alphanumerics starting with an alpha. This is actually a superset of the pattern called for in Bill's tests, but it can be changed later if necessary. Here's the new version of LexicalToken.
Test-First Challenge - Refactoring Interlude
In Part 2 I developed a parser that handles integer constants and some operators. In doing this, I built up some design debt and I now need to refactor. In addition, Part 3 now calls for formulas to handle references to other cells. This will call for some preliminary refactoring based on some quick design thinking. On this page I describe both refactorings and also discuss how I feel about all this change.
Test-First Challenge - Basic Formulas
Part 1 was originally done with only one string holding the content for all the cells. As expected, this broke on the first test of Part 2 (testManyCells) and some refactoring was required.
Test-First Challenge - Getting Started
Bill Wake created the Test-first Challenge as a way for people to practice test-first. He provided a set of tests that drive the development of a simple spreadsheet application. A number of people who frequent the extreme programming list wrote code in response to Bill's tests, including me.