Everything looks worse in black and white

February 3, 2010

When we worked on describing our values at the Symbian Foundation, the adjective which came out top was Passionate. We are all passionate about what we do and what Symbian is for.

Working with a small group of passionate people can be great, but there are some perils which I’ve been thinking about recently. Everything is more vivid: the highs are higher, the progress is faster, the successes are sweeter. Sadly, the lows are lower and the frustrations more frustrating. Here are some of the bad things that can happen:

The Last Word – Passionate people care about getting their point across. Sometimes this drives them to keep going when others want to stop the conversation and just agree to differ.

Heat – Passion can turn a vigorous debate into a heated debate, and maybe even a full blown row. People care about the subject, so they are more likely to start the discussion in the first place, and invest more in winning the argument.

Toes – Caring passionately about the outcome can lead you to overstate your case, and to ignore common courtesy and politeness. Someone agrees to accept part of what you say? Great – but the temptation is to press harder to win the rest of the argument, when maybe you should be acknowledging the concession that they’ve made.

Dogma – The worst thing is when passion leads to “You disagree with me, so you can’t be a True Believer”. This is a really lose-lose mistake, because it divides people who ought to be able to cooperate, and poisons the mood for everyone. For the people on the receiving end, there’s no way to answer. Burn the heretic!

All of these bad things are made much worse by another feature of being passionate: if I am really passionate about something, I will build that something into my view of myself. If you challenge that something, then it feels to me like a personal attack. If you say that I’m not a true believer, then maybe you are right, and maybe that part of me just suddenly evaporates leaving … nothing?

So why am I blogging about this? Well, I’ve been surprised by the depth of feeling in some discussions lately, and very surprised by my own reactions. This blog is the result of trying to understand: now that it’s written down I can see clearly that I’ve been demonstrating some of these behaviours as well as being on the receiving end, and I have a few more things to watch out for. I will continue to be passionate about the Symbian adventure, and I hope to contribute more effectively by controlling that passion better.

Thanks for listening – you’ve been a great audience.


I wanna be like you, ooh, ooh

December 23, 2009

One day, I was using the “–similarity 100” feature of the Mercurial addremove command to work out which files were really just renamed rather than newly created. It struck me that Mercurial could do this more efficiently for the “100” case (files have identical content) by using the file checksums rather than extracting the files and diffing them. I thought I’d suggest this as a “wish” in the Mercurial project’s bug tracking system.

Could the “hg addremove –similarity 100” performance be improved by noting that the checksums of the two files must be identical for 100% similarity, and so there’s no need to extract the file content and compare. It’s a special case optimisation, but “identical” is surely the main use of this feature?

Here’s how the story unfolded:

2009-11-24 14:36 – I posted my wish

2009-11-24 14:51 – Martin Geisler agreed that it would be more efficient, and pointed me to the place in the Mercurial code where I could try to implement my suggestion.

It’s my itch, so it’s fair enough to suggest that I should do the scratching. I had a look at the code, but I’ve not done much Python yet and it wasn’t very clear to me how the code was actually working right now, and what functions I would need to call on which objects to get the checksums. I thought I might as well have a go, but probably another time.

2009-11-24 15:38 – Benoit Boissinot added a suggested implementation to the issue.

Wow! That certainly saves me some work, and probably helps me get my head around the Python code as well. I’m still a bit stuck, but I asked my colleague Pat Downey how I would build a version of Mercurial with the change. Pat offered to try it out for me, so I thought I’d wait for his results and then feed them back to Benoit the next day.

2009-11-24 18:31 – Pat emails me to say that he’s tried the change and it showed a speedup in a largish example of 17 minutes reduced to 6 minutes.

2009-11-24 18:45 – Benoit adds a rework of his changes, as commits into his working version

2009-11-24 21:03 – Benoit delivers the reworked changes into the mercurial-crew repository, and asks me to try out the new version

I come into work the next morning and discover that the stuff is all done. I confess that I didn’t follow up on the second set of changes and retest, but even that failing on my part didn’t stop the ball rolling

2009-11-26 16:00 – Benoit finishes testing the change to his satisfaction and promotes the code to the main repository.

From “wish” to implemented code in 49.5 hours!

This is what “good” looks like. No, strike that – this is what “outstanding” looks like.

It’s not about fancy tools, beautifully crafted instructions or elaborate processes: it’s about having people who are skilled in what they do and passionate about the project. I’m part of the Symbian Foundation and I’m passionate about what we do: in future when people ask me what the “contribution user experience” should be, or how package owners ought to behave, I’m going to say:

Look at Mercurial. Look at guys like Martin Geisler and Benoit Boissinot.

Go and do likewise…

Do you want to know a secret?

November 19, 2009

Back in the days of Symbian Software Ltd, Symbian OS was a commercial product with fairly complex licensing conditions. Code that was wholly owned by us as divided into 5 categories called A, D, E, F and G, with category A indicating the “crown jewels” , the very essence of the Symbian-nature. Most people didn’t get to see the Category A code, and even Nokia wasn’t permitted to change a line of it.

As you know (Pay attention in the back row), Symbian Software Limited is no more, the code has passed to the Symbian Foundation and we’ve started opening up the source code to the public. The Kernel and Hardware Services package is now available under the Eclipse Public License, and Lo and Behold! – there are the Category A files.

The list seems to have grown a bit since I last looked, probably because the distinction ceased to matter after Nokia completed the purchase of Symbian Software Limited in December 2008.

Good – that’s another bit of arcane knowledge I can forget about forever…

Sing out the words I couldn’t say yesterday

November 17, 2009

Another benefit of Open Sourcing the Kernel is that we can now publicise the public APIs! (Try saying that fast three times…)

The Symbian Platform has a compatibility promise which says that applications written using the identified “Public APIs” should work on all future Symbian-based devices. To make use of that promise, you need to know which APIs are included, and that’s the information which we have now made public.

We have put the list of header files for Symbian^2 onto a wiki page, but I thought it would be interesting to try to make the content available in a convenient form, and to try to convey how the list is growing for successive releases of the Symbian platform. My solution is to put the header files into Mercurial as they are laid out in the epoc32 tree, and make that repository searchable using OpenGrok: the “history” and “annotate” options in OpenGrok will then let you find out how a header file has changed across releases and when that header file was introduced.

Here are some of the neat things that you can do with this:

All of this is new, and I’d welcome your comments and feedback.


Publicise the public APIs
Publicise the public APIs
Publicise the public APIs

Don’t come around here no more

November 4, 2009

It’s quite striking how different life is working for an Open Source foundation, compared to a conventional commercial organisation. One difference is what happens when people leave.

In a commercial organisation, there is a very clear point at which you stop being “One of Us”: you give back your badge and your laptop, and then you are out on the street, with the door slammed shut behind you. Your accounts are closed, your existence terminated, and salt is scattered on the ashes.

Here at Symbian, it seems to be very different. Several people have left in the 7 months we’ve been going, and some of them continue to show up in our offices from time to time, working on stuff for us. Back in the commercial world it’s almost impossible to do contribute once you’ve left, but the Open Source world involves lots of volunteers and so people can switch easily from paid full-time work to occasional contribution.

X is no longer with us, except in spirit. And occasionally in body as well…

Wondering what on earth I’m doing here

September 4, 2009

Not angst, but reflection prompted by a 2 day SCRUM master training course run by Michael James of Danube.com.

We’ve been running as a SCRUM team since 1st April when most of us were transferred to the Symbian Foundation from Nokia – “Agile is the new Black”, so we never really considered any other way of organising the development work. I’ve been the Product Owner for the team for all 5 months, but this is the first actual training I’ve had for SCRUM, though some of the team had SCRUM training at Nokia.

I thought it would be useful to reflect on what we’ve been doing, and compare it to what was in the course, which included both the basic SCRUM methodology and a lot of examples of how people have applied it.

SCRUM, or “SCRUM, but…”?

Strictly, the SCRUM methodology is 3 roles, 5 meetings and some artifacts. Roles first…

I’m the Product Owner, managing and prioritising the product backlog. Andrew Simpson is the SCRUM master, and we have currently 9 other team members. The team has grown a bit too large again – when this happened before there was a “sub team” of 4 people focussed on one particular area, so we split into separate teams, and Mike Kinghan took charge of the new team. I continued as Product Owner for both teams, but I found I was just re-writing Mike’s stories before accepting them into my backlog, so over the last few sprints we’ve effectively separated the backlogs and Mike is now the Product Owner for his team.

Now the meetings…

team area

Team area - there are a few more desks out of shot

We have a daily standup meeting around a board with index cards for tasks – tasks start at the left side, move to the middle when in progress and end up at the right when completed, next to the backlog items (in white) that they relate to.

task board

Task board part way through a sprint - cards swim towards the backlog item

The standup meeting is at ~10:30am each day and lasts for about 20 minutes. I normally go to the standup, and I sometimes volunteer for a task if I can commit to complete it and it helps towards one of the important stories.

Our sprints run Thursday to Thursday because we have long build times, and it’s important to get good use out of the weekend – if we spent Friday afternoon planning we could have machines sitting idle for 72 hours.

The Sprint Planning meeting starts at 3:30pm on Thursday with my presentation of the stories at the top of the backlog, then the team works through them identifying the tasks. This is much like the Sprint Planning meetings in the training course, but there isn’t any sense of the team committing to complete the stories and saying “enough, we can’t do that one as well”.

At the end of the sprint, we have a Sprint Demo meeting at 11am on Thursday, where I go through the backlog asking for demonstrations, and make a judgement about whether or not I accept that each story has been completed. We usually don’t complete all the stories, and sometimes complete lower priority stories instead of the top priority ones.

We don’t have an explicit Sprint Retrospective meeting, but we have occasional stories which explictly ask for a review of some major activity with recommendations for improvement, and the team aren’t shy about including improvement tasks or requesting improvement stories when they see a need. Agreeing to put more effort into the top priority story is one example of a retrospection outcome which happened without the formal meeting.

We don’t have the un-named meeting for grooming the stories in the Backlog, but that’s generally what I’m doing in the hour or so before the Sprint Planning meeting. When stories haven’t been completed, I may modify them to reduce the scope, or sometimes to add a bit more before putting them back into the backlog.

And the artifacts:

I maintain the Product Backlog as a spreadsheet on Google Docs which contains a prioritised list of “user stories” in the “As a (role) I want (something) so that (benefit)” format.

The top 4 stories in the current backlog

The top 4 stories in the current backlog

For the Sprint planning meeting I put the stories for the sprint into a Powerpoint presentation, print it out in the “handout” format, and cut the printout up into reasonable sized Backlog Item cards. At the Sprint Planning meeting the team does “planning poker” to establish a common understanding of the work, and produces a set of tasks for each story. The tasks are written on cards, and they go with the Backlog Item cards onto the Sprint Backlog board (pictured above).

We don’t have a Sprint Burndown Chart because we don’t estimate the size of individual tasks, but we argued that this is one-off work which wouldn’t be representative of later team activity anyway. We do put T-shirt sizes on the stories (as a side-effect of planning poker), but we don’t have a Product Burndown Chart – that’s something new I learned about in the course.

Hmmm, I counted five instances of the B-word in there, so things to think about already…

Agile or aimless?

We started with a big pile of raw source code and needed to develop the ability to build and ship it as soon as possible (see my first blog posting for more details). We decided to use 1 week sprints to allow for frequent “corrections”, and I only wrote stories for the very near term.

The course guidance on when SCRUM is appropriate talks about a “chaotic” region where defined processes won’t work and am empirical approach is needed. That was certainly our situation: we had unknown amount of technical risk, and a belief that in Open Source the requirements are always malleable and subject to “do what you can” pragmatic adjustment. Writing just the near term stories was a way of navigating through unknown territory – pick a direction which contributes something to the vision, make some quick progress, see where you get to, and repeat.

Even if we had known about Product Burndown Charts, we would not be able to use them with this approach to the backlog: there is no set of stories to burn through, and no articulated vision of the “release”.

Having said all that, we do seem to have got the show on the road, and we’ve moved to 2 week sprints as a recognition that the first phase is over. The whole department is now taking time to set objectives for the next 6-12 months, and this would be a chance to have a more substantial Product Backlog with is leading towards a more clearly-stated goal.

What to change, if anything?

I think the team is too big again, so time for another split. “SCRUM at scale” was another subject discussed in the course, though our situation is slightly different from introducing SCRUM into a large organisation.

I want to try having a substantial backlog which gets all the way to our goals for the end of 2009, and try using the velocity and burndown analysis to see if we are likely to make it. This might also involve asking for a more distinct commitment to the Sprint Backlog, but I still don’t want to estimate individual tasks.

Hello Darkness, my old friend

September 4, 2009

As mentioned elsewhere, the main Symbian blog is undergoing a change of focus/policy, so it’s time to come back to a personal blog, where the usual disclaimers can apply.

Please tick one or more of the following (Note: viewing will be invalidated if no disclaimer is selected)

  • The opinions expressed in this blog are my personal views, and do not imply endorsement by my employer. Hell, I’m not sure I believe ’em half the time…
  • These words are published under the Creative Commons license, but don’t quote me on that.
  • By reading this posting, you agree that these words will not be used for purposes associated with chemical, biological or nuclear weapons or missiles capable of delivering such weapons, nor will they be resold if you know or suspect that they are intended or likely to be used for such a purpose.

Their eloquence escapes me…

April 7, 2009

Seeing Tim Holbrow’s blog about Export Control and the Symbian Platform reminds me just how insane the Export Control regulations really are.

The Government argument is that a) the platform contains “strong cryptography”, and therefore b) it would be a Bad Thing if Bad People got hold of it. We can’t be told who the Bad People are, or what Bad Things might happen (National Security), so the only solution is to insist that we log every delivery and try not to send it to countries which aren’t on the Nice list.

There’s only one word for this. Stupid.

Let’s make some guesses. The Bad People are terrorists, spies and criminals, all of whom would like to hide what they are doing from the police and the government. Those people do things which really are pretty bad by any standards, but the “strong cryptography” angle means that the authorities are primarily worried about one specific “Bad Thing”, i.e. they could store and transmit information which can’t be decoded by the authorities.

I guess none of us want to help terrorists blow up railway stations, but the government seem to have missed the point: strong cryptography is already out there, freely available. Furthermore, the Symbian Platform is open, which means that any Bad Person can pop along to an internet cafe, download OpenSSL, and compile their own applications to install on their own phones. The phones themselves can be purchased almost anywhere in the world, and even Bad People sometimes visit (or live in) Nice countries.

It makes about as much sense as requiring a modern London Taxi to carry a bale of hay for the non-existent horse. That law was repealed in 1976 after 145 years – let’s hope we don’t have to wait that long for sense to prevail on “Export Control”.

Another suitcase in another hall…

April 1, 2009

My first day in the Symbian Foundation, and it’s like living in a building site. This is true for the physical building – there is drilling and hammering going on as the reception area is being constructed – but it’s also true for the software.

The Symbian Platform is being seeded by a massive contribution of software from Nokia, but nothing is ever that simple. It’s rather like buying a house: what you saw was someone’s home, when you agreed the contract there were things explicitly removed (“We are keeping the washing machine”), but when you take possession it feels like an empty shell. It takes work to make that house into your home, and it’s hard to see how much work will be involved until the day you get the keys.

In our case, what we saw was the working software that is being updated, built, tested and deployed in Nokia phone prototypes, supported by teams of people with well-established development cycles and delivery processes. What we received today is most of the raw source code, and our immediate task is to establish our own build and delivery processes.

Not all of the working software we saw belongs to Nokia: over the years many Make/Buy decisions have chosen the Buy option, and licensed software from other organisations, for example the Java virtual machine and standard classes. An enormous amount of work has gone into identifying precisely which source files can be contributed to the Foundation, but it’s only now that we can really see the result and discover how much is missing. Some code will have been removed by accident, and will be contributed later when Nokia have had a chance to separate their code, but other pieces are more fundamental.

I’m looking forward to getting stuck in, and I’m hoping that you will be interested in our progress.