Why Symbian failed: developers, developers, developers
Fear and loathing in active objects!
Andrew's Mailbag Extra The reasons why Apple succeeded in creating a smartphone market – with OEMs rushing to follow in its slipstream with Android – have now become conventional wisdom. Firstly, the iPhone was designed to be a mobile computer first, not a phone, and was optimised around a new, radical UI. It surprised people with its capabilities and the UI was forgiving. Secondly, bundling data with the appliance reduced the risk for customers - once data was bundled, you were daft not to use it.
And there’s similar agreement on the reasons why Nokia, having planned a mass smartphone market for 15 years, missed out. Nokia’s design philosophy was that smartphones were phones first, not computers. It wasn’t in a position to dictate to its customers – the networks – how they should price their data. So because these assumptions were wrong, so were the decisions on the product and R&D. Nokia was reliant on Symbian but had neglected to develop and polish the user interface over the years. Other people point to underpowered hardware and releasing a spread of indifferent products, rather than a few good ones: these reasons are popular but not unanimous. But there’s something missing from these analyses. It’s not the full picture.
I’ve found something else. It’s developers, developers, developers.
I’ve taken soundings from a number of former people intimate with Symbian and found a strong divergence of views. What Symbian’s engineers thought of it, and what they knew it could do, differs sharply from how third-party developers perceived it. I’ve collated a few comments here. It was sparked by a throwaway remark from a Symbian veteran about strings. It inspired this rebuttal .
Symbian is addicted like crack cocaine to the word ‘ecosystem’. What you’re about to read is far removed from what that hippy, happy phrase evokes.
An engineering source who spent years in a business deeply involved in the Symbian market tells us:
Symbian went its own way with just about everything. I delivered Symbian courses all over the world. Everyone hated string handling, it provoked the biggest howls of despair: good developers, bad developers, in the UK, abroad: everyone.
Instead of threads it uses “active objects”, a single-thread co-operative multitasking mechanism with its own arcane syntax and semantics. Instead of exceptions we have “leaves and traps”. For memory management, the “cleanup stack”. And so on.
My complaint isn’t that these mechanisms were inefficient, because they weren’t. In fact they were the opposite... when used correctly. And therein lies the rub. These things were so damned hard to learn, most people just didn’t bother. The sluggish performance you see on your Nokia phone today is a direct result of developers doing things synchronously rather than asynchronously (because Active Objects were difficult to learn), and allocating massive buffers rather than doing efficient string handling (because descriptors are a pig to use). I know this because I’ve seen the code so many times: at Symbian, at Nokia, and at many other Tier-1 Symbian licensees.
Symbian boasted that back in the Psion days, EPOC was designed not by "soft" scientists like software engineers, but by "hard" scientists (their words!) with backgrounds in maths and physics who understood how to bleed every last ounce of performance out of a system. I don’t doubt for a minute that that was the case. But sadly, what those hard scientists utterly failed to grasp was the concept of usability.
That matters, because an "ecosystem" is as good as its skill set. Our anonymous source explains:
Anyone who’s spent a week or more working for a software company knows how much real production code is bashed together by short-term contractors, or by people completely new to a platform. Your platform can be as clever as you like, but until it’s so intuitive that developers take to it like a duck to water, the cleverness will all lie unused, gathering dust. "Intuitive" means having as many of the following as possible: clear, meaningful naming convention; APIs that follow existing conventions; smart, well-integrated development tools; clear and complete API documentation; good supporting reference materials; and well-commented example code. By and large, Symbian fell short on all of the above.
Darren Starr, who ported a well-known application to Symbian many years ago, tells us:
p>As a former professional Symbian developer who has worked on Windows, Mac (Classic and OS X), QNX, Linux, and numerous other platforms over the past 20 years, I can say Symbian was the greatest disaster of a platform design I have ever encountered in an OS that had more than 1000 users. I worked directly with Symbian on several projects and have had plenty of experience of "The Symbian way is better because... well it's Symbian".
I recall putting an obscene amount of work into just trying to make my applications play well with the system since the system was utterly incapable of letting two applications run at once without negotiating with each other as to who should take over. Symbian was more an application that could load other applications into itself than an operating system.
For explanation we turned to a former Symbian insider, close to design decisions being made. The insider told us that Darren's experience was based on first impressions of the original Epoc:
This guy is basing his opinion on the original EKA1 kernel. It was completely rewritten from the ground up in 2002 and 2003.
The redesign also took care of the “co-operative” style multitasking: threads were added in the EKA2 kernel in 2003, exceptions were supported in Symbian 9.1 on, from early 2005.
Ahem. Roger Nolan, who worked on messaging and the kernel for Symbian, points out:
The first generation Epoc kernel, EKA-1, supported full multitasking from the start. Threads and active objects were supported too. Active objects were an optional was of getting concurrency without the overhead of spinning off a thread. Like all Symbian APIs at the time they were designed with that in mind - programmer ease of use came second.
Active Objects have since appeared on iPhone as
NSOperationIt's just basic goodness.
There were, admittedly, idiosyncrasies. These root back to Symbian’s heritage, the former insider explains:
The SymbianOS memory architecture was weird because it ran on ARM processors, which at that time were a little funky in how they implemented their caches - they were virtually indexed, and virtually tagged - so every time the process switched, you had to invalidate half your cache, and this of course meant a flurry of writeback traffic, resulting in poor power consumption.
Yet the Symbian memory management scheme was the reason you could get a few days of usage out of the phone, whereas running Linux it'd only last eight hours.
Symbian would eventually run successfully on five different platforms.
Not all of the criticism can be laid at Symbian’s door. Take this common complaint (from several correspondents) here articulated by Darren:
The greatest reason that the Eikon, Akon, Uikon (and remember Series 60, Series 80 and Series 90 all had entirely new ones) frameworks all ended up so completely unable to inter-operate or even ever be merged is that they all built entire new controls and GUIs on top of the base system in a way that was meant for skinning. They literally turned the concept of inheritance upside down. Instead of inheriting the base classes, the base classes were modified to inherit them instead. This meant that instead of all the UIs sharing a common root, they used the common root as a compatibility layer.
Symbian's confusing graphics architecture
Here we see indecision and politics – and Nokia’s increasing reliance and market power. Symbian itself could never decide whether it was in the UI business or not. It eventually kept one and maintained it – UIQ - and Sony Ericsson and Motorola had both bet product ranges on this UI. But this was an early casualty of the open sourcing move/Foundation – they’d shut it down by the end of 2008. Going further back, I do recall getting wind of various “unity” efforts in the early noughties, so there was one API for developers. These never happened while Nokia ploughed on with the buggy and poorly written S60. Then Python and Posix APIs were hailed as the easy RAD-like environment Symbian needed. Hmmm …
Symbian finally has one simple, easy-to-use API now, with Qt... which is still not quite complete. But it took Nokia’s purchase of Trolltech and a long digestion (during which the Trolltech founders and CTO left) and everyone else dropping out – before Symbian. Says our former insider:
I know there are a lot of things wrong with Symbian OS. But there are also a lot of things right with it: the kernel is a beautiful design, and it has power management far, far better than any other general purpose OS that exists anywhere. The security manager is sweet, and the way it is interceptable, introspectable, and generally hackable (in a good way) is extremely cool.
So... weird and eccentric Symbian undoubtedly is. But the responsibility for the poor stewardship of its Symbian asset must ultimately rest with Nokia.
I just wish Nokia had assigned engineers that understood it, is all. They ruined it from day one. On the one hand, complaining of slow boots, while on the other hand, loading 17 megabytes of bitmaps in their startup thread. Or reading JPEGs one pixel at a time. ®