Feeds

What killed Motorola? Not Google! It was Moto's dire software

Ex-Moto director Rockman tiptoes through the code graveyard

New hybrid storage solutions

What completely derailed Motorola? Software

What Motorola failed to do was spot the turning tide in what people wanted; it became a time when, for instance, you bought computer games on the strength of who wrote them: if Minter, MacLean or Molyneux was on the tin, you stumped up the dosh. The result was none of Motorola's great talent wanted to work for the company. Why program for a dull Midwest company when you can go to the Bay area and be fêted?

As screens evolved beyond seven-segment displays, phones needed fluffy user interfaces. They needed more features – such as customisable ringtones, clocks, calendars, games, biorhythm calculators and other tat.

Christian Lindholm at Nokia saw this and started using psychologists to understand what people expected phones to do. Motorola developed software it called Personality, which allowed users to configure their primitive handsets the way they wanted. But the code struggled to keep up on the manufacturer's MicroTac phones so a plan was hatched: a new elegant platform, something like an operating system, would sit between the user and the firmware that did all the real work of controlling the radio and the UI. And so Platform 2000 was born, and sitting atop P2K was the Synergy user interface. This combination was to be the future for Motorola’s phones from analogue and US TDMA to CDMA and GSM - one platform to unite all devices.

To shortcut the development time, the new software wasn't written from scratch but based on the existing Personality code. It didn’t come soon enough.

 

Remember how phones used to look? The Synergy user interface in 2002

Phones scheduled to be on the new platform started to run late. Quick kludges were implemented to get gear shipped with the software. One phone would be shipped with new features banged in but written in a way that could not be absorbed back into the operating system's mainline source code. This prevented other phones from easily including the feature: there was no time to redo what had been hacked together for other hardware.

The software forked like crazy. Building a version of the OS for each new phone became a major undertaking. A colour-screen GSM phone with photos in its address book could not pass along this feature to other devices.

Bit hard playing games if you can only press one button at a time

At the same time, requirements soared: Moto's software engineers needed to add support for colour screens, cameras and Java. In 2001 there were still awkward limitations in the system, such as the inability to detect more than one button on the keypad being pressed at once – something games needed if the player wanted to move and fire at the same time.

More and more development resources were thrown at P2K with thousands of people working on it. The failure to manage the operating system programmers meant they churned out stuff like crazy, bits of source code were lost, and eventually the platform became less like physics - where you know what will happen given a set of inputs - and more like biology - where you inject a drug and see what happens. No one wanted to make changes fearing what might break.

The solution adopted by the product development teams was to avoid P2K altogether and commission outside device manufacturers to make handsets using their own operating systems that were similar to P2K but did what the product managers wanted. Competition meant that a large number of these external electronics companies were used, each with their own software base. All the user interfaces had to look like Synergy. Keeping all the phones working in the same way became a nightmare. A simple change, such as adding a field to an address book, would have to be added to 20 code repositories and had a 36-month lead time.

Source code changes became such an overhead there were huge company processes put in place to make sure that everyone really wanted a change before it was implemented. The software requirements conference call was broken into a number of features, with fifty people invited to the daily call of an hour and a half, except on Fridays.

Motorola tried to redress this with the purchase of TTPCom for $193m in 2006. The prize here was Ajar: the not-quite-open-software platform aimed at low-end phones. Handled correctly this could have saved Motorola’s low-end business.

Unfortunately, TTPCom gobble was the brainwave of Moto's chief technology officer. The people who actually made phones – the product team vice-presidents - were so battle-scared from dealing with Motorola’s in-house software, they didn’t trust Ajar and preferred to use the proprietary operating systems built by the outside contractors, the original device manufacturers (ODMs).

For example, an ODM was told to build a product using either its own feature-phone OS or an Ajar-Synergy combination - whichever one could be done on time and to budget and looked like Synergy. If the ODM used its proprietary system, it would get royalties on each phone. If it used Ajar, it would not.

It was never a fair fight, made worse by the decision to take Ajar - a smart flexible multi-threaded OS - and port Synergy to it, running the whole environment as a single thread, effectively an OS within an OS. This was powered by a 50MHz ARM7. The memory budget went through the roof, it crawled along, and Ajar's reputation was tarnished within Motorola.

(If I sound bitter it’s because I worked on a user interface for Ajar that was - in my humble opinion - smart, elegant and Nokia-beating. In six months with eight people we’d built something better, slicker and nearer completion than hundreds of Motorola bods had in years. Indeed, Motorola did so badly because it used armies of mediocre or, at best, good programmers. I worked with a few brilliant ones who could guide the merely good. By having everyone in the same room and using agile methods we raced ahead.)

Secure remote control for conventional and virtual desktops

More from The Register

next story
Drag queens: Oh, don't be so bitchy, Facebook! Let us use our stage names
Handbags at dawn over free content ad network's ID policy
Blockbuster book lays out the first 20 years of the Smartphone Wars
Symbian's David Wood bares all. Not for the faint hearted
'Serious flaws in the Vertigan report' says broadband boffin
Report 'fails reality test' , is 'simply wrong' and offers ''convenient' justification for FTTN says Rod Tucker
This flashlight app requires: Your contacts list, identity, access to your camera...
Who us, dodgy? Vast majority of mobile apps fail privacy test
Apple Watch will CONQUER smartwatch world – analysts
After Applelocalypse, other wristputers will get stuck in
Shades of Mannesmann: Vodafone should buy T-Mobile US
Biting the bullet would let Blighty-based biz flip the bird at AT&T
Net neutrality fans' joy as '2.3 million email' flood hits US Congress
FCC invites opinions in CSV format, after Slowdown day 'success'
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
Top 5 reasons to deploy VMware with Tegile
Data demand and the rise of virtualization is challenging IT teams to deliver storage performance, scalability and capacity that can keep up, while maximizing efficiency.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Secure remote control for conventional and virtual desktops
Balancing user privacy and privileged access, in accordance with compliance frameworks and legislation. Evaluating any potential remote control choice.