Interesting Bits

Predictable Delivery: A killer metric

A killer metric. So many projects collect so much information about the day-to-day goings-on, while many other projects collect next to none. Are you overwhelmed by the sheer volume of measurements you could be taking and recording that you choose to do none? Would you rather track one killer metric that correlates highly with your team's ability to deliver predictably?

Mean time between injection and detection. Measure that: the time it takes to detect a new defect once it has been injected into the system. Not reported, mind you, but injected. Which lines of code were changed to fix a defect? When was that code last changed? That's the latest time that defect was likely to be injected. Certainly, a lower bound measurement is adequate for our purposes.

The higher the mean time between injection and detection, the higher the cost of the defect. Think about what your team goes through to fix a defect, including describing it, logging it, recreating it, arguing over it, prioritizing it in meetings, tracking its root cause, fixing it, testing the fix, committing the fix, then verifying the fix. When we detect the defect weeks after it is injected, all these costs are substantial. When we detect the defect seconds or minutes after it is injected, many of these costs are eliminated.

So, find defects moments after they are injected. Sound impossible? Ask us and we'll show you how.

jbrains on 02.28.05 @ 01:30 AM ET [link]

JUnit Recipes: Great book, less Maven...

In a recent (positive) review of JUnit Recipes, Carlos Valcarcel wrote:

What I liked the least (well, not so much what I didn't like as what I would have liked to have seen): in a book of this depth it would have been nice to see a web-based application with the various testing layers in place using Ant or Maven scripts to run the tests over the development-life of the example. I keep hoping to run into a tutorial like that, but the sheer scope of the example may be too much to cover without short-changing other areas.

This absolutely would have been a nice thing to add to the book, and if I were a Maven wizard, I would certainly have naturally done things that way. Instead, I am an Eclipse wizard, and so all the examples in the book were prepared using Eclipse, and all the code you can download from Manning's web site is conveniently packaged into Eclipse projects.

I will point out that JUnit in Action talks in some depth about using Maven to build a J2EE project, and so I might even have felt it wasteful to repeat someone else's good work.

To Carlos, I would ask, what is so special about a J2EE project from the perspective of using Maven? What would be in a J2EE/Maven tutorial that wouldn't be in a normal Maven tutorial?

jbrains on 02.22.05 @ 10:08 AM ET [link]

Predictable Delivery: Fear is waste

Fear is waste. Some teams fear changing their code so much that they will voluntarily freeze their codebase weeks before the corporate-mandated freeze date.

How would your project be different if you could spend that time adding features your customers care about?

jbrains on 02.22.05 @ 01:17 AM ET [link]

XP Day Toronto 2005: A success

I would like to thank those who helped to make XP Day Toronto 2005 a success, including my wife Sarah, Deb Hartmann, Ron Jeffries, the speakers, the members of the Project Room and, of course, our fantastic attendees. As a first-time conference organizer, I was nervous, but I had surrounded myself with greatness, so only greatness could have happened.

jbrains on 02.21.05 @ 09:53 PM ET [link]