Agile developers measure their velocity. Most teams define velocity as the number of story points delivered per iteration. Since the size of a "story point" and the length of an iteration vary from team to team, there's not much use in comparing velocity from one team to the next. Instead, the team tracks its own velocity from iteration to iteration. Tracking velocity has two purposes. The first is estimation. If you know how many story points are left for this release, and you know how many points you complete per iteration, then you know how long it will be until you can release.

Anyone who's addicted to a Blackberry already knows about Monday's four-hour outage. For some of us, the Blackberry isn't just an electronic leash, it's part of our business operations. Like cell phones, Blackberries have a huge, hidden infrastructure behind them. Corporate Blackberry Event Servers (BES) relay email, calendar, and contact information through RIM's infrastructure, out through the wireless carriers. It was RIM's own infrastructure that suffered from intermittent failures during the outage.

Tim Ross has published his implementation of the Circuit Breaker pattern from Release It, complete with unit tests. I barely speak C#, so I'm not in any position to review his implementation, but I'm delighted to see it!  

Catching up on some reading, I finally got a chance to read Ted Neward's article "Pragmatic Architecture: Security".  It's very good.  (Actually, the whole series is pretty good, and I recommend them all.  At least as of February 2008... I make no assertions about future quality!) Ted nails it.  I agree with all of the principles he identifies, and I particularly like his advice to "fail securely".  I would add one more, though: Be visible.

I seldom plug books---other than my own, that is. I've just read two important books, however, that really deserve your attention. Concurrency, Everybody's Doing It The first is "Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea. I've been doing Java development for close to thirteen years now, and I learned an enormous amount from this fantastic book. For example, I knew what the textbook definition of a volatile variable was, but I never knew why I would actually want to use one.

How long is your checklist for setting up a new development environment? It might seem like a trivial thing, but setup costs are part of the overall friction in your project. I've seen three page checklists that required multiple downloads, logging in as several users (root and non-root), and hand-typing SQL strings to set up the local database server. I think the paragon of environment setup is the ubiquitous GNU autoconf system.

The Jolt Awards have been described as "the Oscar's of our industry". (Really. It's on the front page of the site.)  The list of past book winners reads like an essential library for the software practitioner. Even the finalists and runners-up are essential reading. Release It has now joined the company of finalists. The competition is very tough... I've read "Beautiful Code" and "Manage It!", and both are excellent. I'll be on pins and needles until the awards ceremony on March 5th.

Somewhere inside every commerce site, there's a bit of code sending emails out to customers.  Email campaigning might have been in the requirements and that email code stands tall at the brightly-lit service counter.  On the other hand, it might have been added as an afterthought, languishing in some dark corner with the "lost and found" department.  Either way, there's a good chance it's putting your site at risk. The simplest way to code an email sending routine looks something like this:

This week, I had Groundhog Day in December.  I was visiting two different clients, but they each told the same tale of woe. At my first stop, the director of IT told me about a problem they had recently found and eliminated. They're a retailer. Like many retailers, they try to increase sales through "upselling" and "cross-selling". So, when you go to check out, they show you some other products that you might want to buy.

Speaking of databases and read/write splitting, Oracle had a session at OpenWorld about it. Building a read pool of database replicas isn't something I usually think of doing with Oracle, mainly due to their non-zero license fees.  It changes the scaling equation. Still, if you are on Oracle and the fees work for you, consider Active Data Guard.   Some key facts from the slides: Average latency for replication was 1 secondThe maximum latency spike they observed was 10 seconds.