Argle Bargle

Technical: In this article I explain how we use the Asterisk open source pbx module extensions to connect it to the service we provide at iotum

Non-technical: I wrote an article! wheee!

Building The iotum Asterisk Module

Well, there it went. The company I work for, iotum, was accepted to present our product at Demo 2006. Our founders Alec Saunders and Howard Thaw worked very hard to make a great presentation (embedded video of the presentation).
Now, almost a week later, we’re getting great press & blogger coverage

For the last 3 or 4 months, since we were accepted to go to Demo 2006, we’ve all been working really hard to build and polish the latest features and get them ready for the show. It’s funny, it’s rarely the technical details which present the greatest challenges, it’s making the features simple and straightforward for the users. Those decisions have provoked the most interesting discussions.

The setup wizard, for configuring a new users account, has been through at least 3 different implementations and countless whiteboard versions. The servers have been coddled and updated. The core engine expanded and the Outlook addin extended to support the new Conference call feature.

So here we are, and we will continue to push forward with more features and improvements.

Joel has yet another article where he writes about what I’ve been thinking about. Where I work we have candidates for developer positions write code during the interview. Why? Well, to quote someone “When you’re hiring a juggler, you ask them to juggle”.
I’m not trying to trivialize the hiring process, but I think that we all expect a software developer to write code as a big part of their day-to-day job. And so, I want to see a candidate write code.

Writing code should be second nature to a software developer, not a struggle.

I just posted a high level description of how and why we use the agile development process at Iotum.

We’re hiring at Iotum :

• Software Developer
• Program Manager

These aren’t quite the same as Joel On Software’s 12 Steps to Better Code. These are more like “10 Steps to a Better Software Company.” Higher level, corporate wise.

My favorite is the 20% rule, where engineers can spend 20% of their time (1 day /week!) on approved projects of their own design. You’d be hard pressed to find a software developer who doesn’t think that’s a great idea.

Another one that I think is important, and I’d bet it has a big effect inside Google:

Strive to reach consensus. …
At Google, the role of the manager is that of an aggregator of viewpoints, not the dictator of decisions. Building a consensus sometimes takes longer, but always produces a more committed team and better decisions.

At Microsoft the role of Program Manager is like this. You have responsibility for a set of features, or functionality and no power to tell anyone how to do it. Yet you have to get a wide variety people to agree on a way to proceed. Negotiation, consensus-gathering and horse trading are how things get done.

At Microsoft, it’s not unusual for a team member to receive a “ship gift” after a product has shipped, or reached a major milestone. I have a variety of t-shirts, jackets and fleece pull-overs from my time there. For one VisualBasic milestone, from a bit before I joined, there was a pair of shorts with the logo on it. Never any footwear that I saw though.

However, nothing, I mean nothing, I ever received, come close to this one. Custom personalized engraved , limited edition, xbox360 in cool colours, with the phrase "I made this" on the front.

Wow. Now, that’s a ship gift.

Not from me, I haven’t got much advice yet. Still waiting for the hindsight part. However, Evan Williams , he’s got the hindsight. Having built Pyra Labs, producing Blogger, getting bought by The Google, and now off again with Odea

Here’s his advice summed up in 10 rules

[update: hindsite -> hindsight ]