Developer – the flying squirrel

Ubuntu Global Jam in Kitchener-Waterloo

Kwartzlab is hosting Ubuntu Waterloo‘s Global Jam a week from Saturday (Sept. 2).

Along with the usual upgrade and install testing, bug triage, documentation work and so on, Ralph has a project idea. We’re going to run a hackathon to build a new GUI packaging tool, starting with the relatively straight-forward process of upgrading an existing package to the latest version.

So if you’re interested in learning about packaging, GUI development in Qt or Ubuntu development in general, be sure to come by!

If development isn’t your thing, we still need lots of people trying out Oneiric Ocelot on their hardware and submitting any bugs they might find.

Come out and see how you can contribute to make Ubuntu better!

Why track velocity?

Say you’re on an agile software development team and your Customer doesn’t care about release planning or even whether you make your commitment in an iteration. You’re a good team and he’s confident you’ll get the work done when it needs to get done.

Is there still value in tracking velocity? If your customer doesn’t care, is it worth the time to create burn-down charts?

### You can’t manage what you don’t measure. ###

Velocity tells you how much work your team can do in an iteration–say one or two weeks. It’s based on two things: how many discreet items of work you completed and the unitless “size” of those items, as determined by the team themselves, often a long time ago.

Knowing velocity has three separate benefits for the team, regardless of whether anyone else is interested in seeing that number:

1. It can be motivating for people who want to try to improve that number,
2. It tells you how much work your team is likely be able to complete in a subsequent iteration, and
3. It gives you feedback to improve the “size” estimates.

Motivation is great, but the biggest benefit I see is the future iteration planning one. A big part of iteration planning is having the team “commit” to a bundle of work. You can spit-ball an estimate, but software estimation is notoriously hard to get right. Having velocity takes away a lot of the guess-work. It’s not perfect–changes in the team and errors in estimation make the number less reliable. You’re not looking at a precise, hour by hour estimate, however. You just want to have a reasonable amount of confidence in the amount of work you can do on aggregate. Velocity gives you that.

Making your commitment for an iteration is good discipline even if, again, no-one else cares. As a professional, you should be able to finish what you said you’d finish when you said you’d finish. Fortunately, knowing velocity helps you with that.

One of the compelling things about agile for me is the automatic feedback mechanisms. If you plan more work than you’re able to do, your velocity goes down and your next iteration should be more manageable. If you plan too little, and you’re able to take some work off the backlog, your velocity goes up, so you’ll automatically do more next time. Eventually, you find an equilibrium.

Likewise, if you tend to overestimate the “size” of work, your velocity will be high. “Size” has no direct relationship to time besides velocity. Any future estimates you make knowing previous size and velocity will be somewhat improved over your initial, somewhat arbitrary estimates because you now have a better yardstick to measure work by.

Your first iterations are almost certain to be unsuccessful, because you don’t know velocity and you have poor estimates. If you work the process, however, your estimates will improve and you start to have a hope of making your commitments. And it’s much more fun when you’re winning a game than when you’re losing all the time.

If you’re interested in delving deeper, [James Shore does a way better job explaining this stuff than I can](http://jamesshore.com/Agile-Book/estimating.html).

WWBA: Pasta Buffet for Earthquake Relief

> [Cross-posted at the Waterloo Wellington Blogger’s Association](http://waterloowellingtonblogs.org/2009/04/pasta-buffet-for-earthquake-relief.shtml). Ellen and I spotted the flier when we were at the Perimeter Institute concert last night and since they’re about a block away from work and I had to get some stuff done today, I decided to give it a shot. Then I decided I should introduce myself as a “local blogger” to get some details for the WWBA, so I posted this there:

I happened to see a flier yesterday for the [Cortina Club](http://www.cortinaclub.org/)’s all day pasta buffet in support of earthquake relief projects in Italy.

The Italian Cortina Club has been in Kitchener-Waterloo for over 40 years, helping to bring together some 185 families in the local Italian-Canadian community. Many of their members have friends and family in who have been displaced or otherwise affected by the [Abruzzo earthquake](http://en.wikipedia.org/wiki/2009_L%27Aquila_earthquake) last week.

I made the trip down to check out their savoury spaghettata. A heaping plate of pasta is $20 ($10 for kids), and they are very generous with seconds. Not only that, these folks really know how to make pasta.

The Cortina Club is located at [22 Kevlo Place in Kitchener](http://maps.google.ca/maps?oe=utf-8&client=firefox-a&ie=UTF8&q=22+Kevco+Pl.+in+Kitchener.&fb=1&split=1&gl=ca&cid=0,0,17011678365930826213&ei=HQfqSb6kGJrGM5HE0cwF&ll=43.410488,-80.442731&spn=0.011426,0.016479&z=16&iwloc=A), just off Wabanaki Drive. The buffet runs till 6pm. today, Saturday April 18.

If you would like to donate directly, they ask that you donate to the O.S.J Trust Fund L’Aguila Earthquake. They chose that organization on the suggestion of the Italian Consulate.

And if you miss today’s fundraiser, they’re planning a $100 a plate dinner June 13. Watch [their website](http://www.cortinaclub.org/) for details.

Ada Lovelace Day: Barbara Liskov

It’s [Ada Lovelace Day](http://findingada.com/). Here’s my post:

[[wiki:Barbara Liskov]] is a pioneering computer scientist and winner of the ACM Turing Award for 2008. She’s currently head of the Programming Methodology Group in MIT’s Computer Science and Artificial Intelligence Lab.

Barbara Liskov in 1975] Back in the 70s, she designed a programming language called [[wiki:CLU (programming language)|CLU]], which established fundamental concepts about data abstraction that influence every object-oriented programming language (which, honestly, means pretty much every programming language–you heard me, Lisp weenies) being used today. Ruby, C++, C#, Java… they were all built on her work.

*I* know about Barbara Liskov mostly from the [Liskov Substitution Principle](http://www.oreillynet.com/onlamp/blog/2008/02/the_liskov_substitution_princi.html):

> Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

Put another way (and you probably need to know a little bit about object-oriented design to appreciate this), subtypes must always be able to be substituted for a supertype. Programmers mess this up all the time, and it makes for god-awful messes in code, which is why we need Barbara Liskov to set us straight.

* [Recent NPR interview](http://www.sciencefriday.com/program/archives/200903135)
* [Dr. Dobbs interview](http://www.ddj.com/hpc-high-performance-computing/215801518)
* [Faculty homepage](http://www.pmg.lcs.mit.edu/~liskov/)
* [MIT computer science brochure from 1975](http://groups.csail.mit.edu/medg/people/psz/LCS-75/languages.html)
* [Other Babara Liskov posts for Ada Lovelace Day](http://ada.pint.org.uk/subject.php?subject=Barbara%20Liskov)

Dabbling in distributed version control

The new workplace uses Subversion for version control. That’s cool. I know Subversion. It works, and it’s well-supported everywhere.

For ages, though, I’ve been wanting to try out distributed version control systems, but except for putting a few personal projects (which no one else is working on, defeating much of the purpose) in git, I haven’t had the chance. Now I do! Support for pushing to Subversion repositories is almost a requirement to get a new DVCS off the ground.

Work is in C# in Visual Studio on Windows. Supporting those things is helpful too.

Choices come down to [Git](http://git-scm.com/), [Mercurial](http://www.selenic.com/mercurial/wiki/) (hg) and [Bazaar](http://bazaar-vcs.org/) (bzr):

### Git ###

Linus Torvalds coded this up on a weekend to deal with the Linux kernel source. With lots of other projects signing on, it looks like it might win as the standard on Linux at least…

##### Advantages ####

* I’ve started using it for stuff on Linux.
* Fast and space-efficient.
* A friend has been using it for a while, and I’d like to work with him on stuff one of these days.

##### Disadvantages #####

* Subversion integration doesn’t work in the latest Windows release.

### Mercurial ###

I actually know very little about it. [Joel](http://www.joelonsoftware.com) says it’s what they use at FogCreek…

##### Advantages #####

* Good Windows support.
* Most mature [Visual Studio integration](http://sharesource.org/project/visualhg/wiki/) (not saying much).

##### Disadvantages #####

* I find the terminology a bit odd…
* Subversion support is [confusing and/or alpha-ish](http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion).

### Bazaar ###

Popularized by the Ubuntu project, bzr seems less user-hostile than the others. I’m only really looking into it seriously now.

##### Advantages #####

* I like Ubuntu and it’s made by the same guys.
* Canonical actually cares about usability.
* Subversion support is simple and well-integrated.
* Windows support is good.
* Dedicated to inter-operating with other systems.

##### Disadvantages #####

* No Visual Studio support (yet).

So none give me exactly what I want. I think bzr is the closest, though.

As an aside, the [Ankh SVN 2.0](http://blogs.open.collab.net/svn/2008/07/ankhsvn-20-fina.html) Visual Studio integration is actually really good. A little rough around the edges, but still surprisingly good. I’m kinda sad I didn’t hear about it back when it came out in July. It would’ve made my life a lot simpler.

A good Visual Studio integration is the one thing that’s holding me back from diving straight into bzr and using it for work. I’m debating whether automatically tracking adds, drops and moves trumps being about to work on my own branch without having to tell the server about it.