It is possible to write software that solves real business problems, cheaply and reliably. The recipe is well known, even though it's not easy to do.
I am an Extreme Programmer. I help individuals, teams and organization become more effective. I'm lucky to work as a developer for ThoughtWorks, mostly in the Milano area. I used to teach at Università dell'Insubria.
Here are the two measures I pay the most attention to:Kent Beck on the TDD mailing list
- Frequency of test runs. The more work I do between runs, the greater the chance of unexpected errors. The greater the incidence of unexpected errors, the slower I go. Unexpected errors generally indicate either fatigue or a lack of understanding on my part. If I'm tired, I (should) rest. If I don't understand, I divide the work into smaller slices so I can test individual assumptions.
- Double reds. If a test run fails twice in a row, I'm not doing my job well. Again, it's either fatigue or ignorance. This is why the JUnit Max postage stamp has a teensy tiny test history along the bottom. It should go red/green/red/green/green/green/red/green. If the reds start doubling up, it's time to shift gears.