Passion makes a big difference. Posters all over Symbian premises (and on our websites) boldly declare that we “are at our best when we… love working for Symbian, drive to succeed, believe in ourselves, and take pride in what we do…“
Like many other companies, Symbian each year carries out an internal employee satisfaction survey. The survey is conducted by an external agency, who provide us with information on how our results compare with broadly similar surveys held by other high-tech companies. In the most recent survey, aggregate Symbian employee views demonstrated strong Passion (80% positive rating). Of the six values, this one had the strongest support of all. The score also came in notably higher than the benchmark. In general, our employees enjoy working here, and put their hearts into their activities.
In some ways, “passion” is a longer word for “fun”. The good news is that, on the whole, Symbian employees enjoy and value their work. The bad news, however, is as I covered in my previous blog posting, “Symbian, just for fun“: many developers outside the company have a less positive feeling about working with Symbian OS software. They may persevere with writing Symbian OS software because their employer pays them to do so, and because of the somewhat attractive prospect of a share in a growing 200M+ unit market, but they often lack the kind of inner motivation and satisfaction that can put them into a super-productive state of “flow“.
The encouraging responses I’ve received to that posting (both via email and online) stengthen my view that it’s vitally important to identify understand the inhibitors to developer flow – the killers of Symbian passion. That’s a big topic, and I suspect I’ll be writing lots more on this topic in the months ahead. But let’s make a start.
Lack of clarity with Symbian Signed
The experience of my correspondent ilgaz is probably quite common:
I think the issue here is , we (even technical users) don’t really get what should be signed, what shouldn’t.
Some might say that Symbian Signed itself is intrinsically a passion killer. I disagree – as I’ve argued elsewhere. But what does kill passion here is the confusion about the rules for Symbian Signed. You can’t expect flow from confusion. I see six causes for this confusion:
- Different devices implement Symbian Signed in different ways. Some devices helpfully support a setting to allow the installation of self-signed apps, as well as Symbian Signed ones. Others do not;
- Different operators have different views about what kinds of applications they want to allow on their phones;
- The subject of permissions for the different capabilities of different pieces of software is intrinsically complex;
- The operation of Symbian Signed has changed over time. It’s great that it has improved, but some people still remember how it used to work, and that confuses them;
- “Once bitten, twice shy”: past bad experiences sometimes over-colour present views on the topic;
- A small number of people seem to be motivated to spread particularly bad vibes about Symbian Signed.
- Continue to seek to improve the clarity of communications;
- Be alert to implementation issues (eg an overworked website – as experienced some months back) and seek to address them quickly;
- Avoid a divergence of implementations of different application approval schemes by different network operators.
Lack of reprogrammable devices
Another correspondent, puterman, points out:
Getting people to develop apps just for fun is one thing, but getting them to hack the actual OS is another thing. For that to be of interest, there have to be open devices available, so that the developers can actually see their code running.
The Linux community shows the way here, with the Trolltech Greenphone and the FIC OpenMoko Neo1973 and FreeRunner devices. It’s true that there have been issues with these devices. For example, Trolltech eventually discontinued the Greenphone, and the FIC devices have proved quite hard to purchase. However, as the Symbian Foundation software becomes increasingly open source, we can reasonably expect the stage-by-stage appearance of phones that are increasingly end-user re-programmable.
Lack of well-documented API support for “interesting” features of a phone
Marcus Groeber makes a series of insightful points. For example,
One of the main things mobile developers would want to do is make use of the unique features of a mobile phone (connectivity, built in camera, physical interaction with the user). However, it is those area where documentation is still most patchy and API support is erratic (CCameraAdvancedSettings anyone?).
In my view, this aspect of mobilie development should be acknowledged to a much greater degree, and the documentation efforts focused accordingly: If there is a feature in a built-in app of the phone, chances are that a developer will want to try and improve on that. Can s/he?…
I believe that these moments of frustration – finding an API that looks useful in the SDK docs, then spending an evening writing an application that uses it, only to get KErrNotSupported in the end – is probably among the chief reasons for people abandoning their pet projects…
True, many “fun” programmers (me included) don’t want to wade through tons of documentation and whitepapers before writing their first proof-of-concept – but to me this makes it even more important that the existing documentation is streamlined, accurate and compact.
Of course, as Simon Judge points out, sometimes it’s not a matter of improving the documentation of existing APIs. Sometimes, what’s required is to improve the APIs themselves.
API awkwardness across the UI-OS boundary
The last passion-killer I’ll mention for now is another one raised by Marcus Groeber:
most of the “interesting” bits of developing for devices actually come from the licensee’s layers of API (in my case, mostly S60), and I believe it is here where there is most work to be done, as well as the interface between the two…
The ad-hoc-ish nature of the S60 UI, which seems to require a lot of experimenting and guesswork for developing even very simple screen layouts that mimic closely what is already present in the phone in dozens of places. Even after years of development, I still consider the CAkn and CEik listbox classes a jungle.
However, the bigger point is the following: both Symbian and S60 have recognised for many years that the separation of the two software development teams into two distinct companies has imposed drawbacks on the overall design and implementation of the APIs of functionality that straddles the two domains. Keeping the UI and the OS separate had some positives, but a lot of negatives too. Assuming the acquisition by Nokia of Symbian receives regulatory approval, the resulting combined engineering teams should enable considerably improved co-design. The new APIs will, hopefully, inspire greater fascination and approval from those who use them!
dw2 
Leave a Reply