Code reviews

I’ve been quoted in a series of articles at CIO.com on code reviews. The two particular ones I’m in are

Neat!

The author of the articles is Esther Schindler, who has also written articles like “Four Non-Obvious Things Pink Floyd Can Teach Your Team“. I <3 analogies.

Velocity, or v = dx / dt

I was coworking at Stardust today, and we got to talking about Agile Development, and the concept of velocity.

Disclaimer: I hate buzzwords. But, these terms have specific meanings, and although it sometimes sounds cheesy, there really is something to this Agile movement.

Basically, velocity is an Agile concept that is a self-calibrating method for estimating how much work can be done in a unit of time.

The trick is that velocity doesn’t really measure the work done, it measures how much estimated time it takes to fill an actual week of working. The trick behind velocity is that you track (per task) the estimated time of completion, and the total amount of estimated work completed in a unit of time (usually a week). As long as the developers who are on the project are always the same ones handling estimates,  if they have a tendency to overestimate or underestimate, it will be canceled out after the first week or two. Make sense?

If you haven’t tried Agile development processes, I strongly recommend it. There’s a game that was created to help explain how Agile/XP works,  calld The XP Game. It’s a reasonably entertaining way to learn business stuff (better than a pointy haired lecture!), and doesn’t take long.
I’ve still got lots to learn about the finer aspects of applying Agile/XP, but I’m happy to talk with anyone about these ideas — I might learn something new 🙂