Testing XMLRPC interface. Please ignore.

Ignore this also.

Okay, so seeing as it's All My Fault, I suppose I should say something interesting.

NITI

Right, so Doc Searls was visiting our office (NITI-Toronto) last week and he said some interesting stuff. A lot of this is straight out of the ClueTrain, but since it was personalized for us, it seemed to hit home that much harder. As time goes on we'll be fiddling with stuff and downplaying the brochureware on our main web site, since (as he correctly points out), nobody cares about or even believes brochureware. Hear hear.

But what nobody mentioned is that our OpenSource site is also brochureware, albeit on less expensive paper. My plan is threefold:

a) Wiki-ize the OpenSource site so people internally will actually keep it up to date.

b) Finally get public anonymous CVS working, so people can find out about and download and maybe contribute to all the new free stuff: WvIPsec (AKA "Thank God it's not FreeS/WAN"), WvStreams, UniConf, ExchangeIT, SSoya, WvTFTP, and a bunch of things I probably already forgot. Note to self: consider making advogato projects for all these so I can add myself to them. Hmm.

c) Start blogging. Note: I hate the word "blog" and all its derivatives, but unfortunately that's all we've got. I'll call this my advogato diary nonetheless, and if you're lucky this is the last instance of the word "blog" you will hear from my virtual lips. Also, while some people claim that the interesting thing about a bl- err, diary, is that you can read all about people's personal lives, I basically have no interest in yours and expect you to have no interest in mine. So I'll stick to the technical stuff wherever convenient.

By the way, although it's All My Fault, choosing advogato as the target was All pphaneuf's fault.

Latency

Down with it!

(You will hear more from me on this topic.)

Trust Certifications

Since a bunch of NITI people have joined advogato, I felt as if I should certify them.

I think the whole web-of-trust thing (pgp, advogato - it's all the same) is amazingly cool, although nobody has ever taken proper advantage of it. Come on, let me define my own trust roots and then apply the trust calculation to arbitrary things - now we're getting somewhere.

Now, for advogato in particular, I feel rather silly certifying someone like slajoie, who is, franky, a genius with real-life experience, at Apprentice level just because most of his work has been on non-free software. Someone with years of coding experience who's not a big name in free software is just plain not an apprentice. We need a different word. But I'll follow the rules and certify him that way anyway, because luckily it doesn't matter.

Also upgraded my own self-certification to Master. "Modesty will get you nowhere," that's my new motto. Hence the bl- err, diary.

Life

No comment.

Current Status

Offically Not Dead.

Branch Constraint Theory

Oh yeah, baby, I just invented a series of simple mathematical formulas that tells you why your project is taking so long to release, has so many bugs, and seems to show no signs of getting better. It might explain the weird many-way-branching of the Linux kernel and the annoying ever-slowing Debian release schedule, as well as (more importantly) some of the phenomena we've seen at work.

It's 28 pages of pure fun. I'll see about publicly releasing it if I can trim out the NITI-internal bits.

The most brilliant insight, which seems obvious once you read it but is quite non-obvious until then, is:

If you have two branches, a stable and an unstable branch, and you spend more time in code freeze than in feature addition, then each release will take longer than the last. That's because you start stabilizing the current "unstable" branch no sooner than you release the previous "stable" branch, so every feature addition phase is longer than the previous bug fixing phase. And if, within a release, your bug fixing phase is longer than your feature addition phase, well... it flies out of control, and you're doomed.

Doomed, that is, until you create MORE SIMULTANEOUS BRANCHES! And then you're differently doomed! Woo hoo!

Corrollary: simply adding more testing time at the end of a release cycle will not save you. And I'm now certain of it.

Oh, another interesting insight is that if you add features more slowly you can make more frequent releases. It's a fundamental law of software engineering and I proved it more-or-less mathematically. Go figure.

Update 2008/02/13: The link in the original article no longer works. You can find the Branch Constraint Theory PDF here instead.