Feeds

Why Symbian failed: developers, developers, developers

Fear and loathing in active objects!

  • alert
  • submit to reddit

Using blade systems to cut costs and sharpen efficiencies

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.

HP ProLiant Gen8: Integrated lifecycle automation

More from The Register

next story
Yorkshire cops fail to grasp principle behind BT Fon Wi-Fi network
'Prevent people that are passing by to hook up to your network', pleads plod
Major problems beset UK ISP filth filters: But it's OK, nobody uses them
It's almost as though pr0n was actually rather popular
Microsoft unsheathes cheap Android-killer: Behold, the Lumia 530
Say it with us: I'm King of the Landfill-ill-ill-ill
All those new '5G standards'? Here's the science they rely on
Radio professor tells us how wireless will get faster in the real world
Apple orders huge MOUNTAIN of 80 MILLION 'Air' iPhone 6s
Bigger, harder trouser bulges foretold for fanbois
US freemium mobile network eyes up Europe
FreedomPop touts 'free' calls, texts and data
'Two-speed internet' storm turns FCC.gov into zero-speed website
Deadline for comments on net neutrality shake-up extended to Friday
Oh girl, you jus' didn't: Level 3 slaps Verizon in Netflix throttle blowup
Just hook us up to more 10Gbps ports, backbone biz yells in tit-for-tat spat
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Reducing security risks from open source software
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.