Writing in EE Times yesterday, comparing the prospects of different mobile operating systems, Rick Merritt has a bit of illicit fun complaining about what he sees as inevitable slowness in the operation of the forthcoming Symbian Foundation:
Trailing behind
…it will take developers as long as two years to meld all the pieces of the unified open-source platform Nokia plans.The environment will combine the best elements of the UIQ and MOAP(S) environments created by Sony Ericsson and Docomo, respectively. But it will not run existing apps written for those environments.
Worse, the unified Symbian will be defined by a complex set of interworking groups at the Symbian Foundation—including separate councils on feature road mapping, user interface and architecture—drawn from the dozen companies that make up the new foundation. What’s the Finnish term for “design by committee”?
This description of the intended collaborative design and review mechanism of the Symbian Foundation implies that such a process is bound to be ineffective. The underlying idea is that committees (or “councils”, to use the word from the Symbian Foundation whitepaper) are for losers, and never produce anything good.
It’s true that many committees struggle. They can degenerate into talking shops. But not all committees have such a fate.
Indeed, what’s proposed for the Symbian Foundation isn’t something brand new. It’s an evolution of a collaborative design and review mechanism that is already in place, and which has been working well for many years, guiding the evolution of Symbian OS up till now.
For example, Symbian TechCom (“Technology Committee”) has met three or four times each year since 1998, and successfully performs many of the tasks slated for the new councils. Symbian TechCom membership includes leading technical specialists and senior product managers from phone manufacturers around the world. What makes TechCom work so well is:
- A series of processes that have evolved over the ten years of TechCom’s existence
- Continuity of high-calibre personnel attending the meetings, who have learned how to work together effectively
- Skilled management by the Symbian personnel responsible for the operation of this body
- Excellent preparation before each meeting – and good follow up afterwards.
The skills of running an effective committee may sound boring, but believe me, if done right, they enable better decisions and a new level of combined buy-in to the conclusions eventually reached.
As another example, from further back in my professional career, I remember countless long discussions over aspects of the Psion EPOC suite of software. How should the Agenda app operate in such-and-such a circumstance, exactly what APIs should the OPL scripting language provide, which software features should be centralised to libraries and which left in individual apps…? These questions (and many many others) were decided by a process of debate and eventual consensus. It can be truly said that this software system was “designed by committee”. Some people might think that’s a criticism. On the contrary, it’s a great strength.
In short, collaboration is hard, but when you’ve got the means to make it work, the outcome will be better (for complex problems) than if strong individuals work independently.
Let me briefly comment on the other two paragraphs from the above extract:
The [Symbian Foundation] environment will combine the best elements of the UIQ and MOAP(S) environments created by Sony Ericsson and Docomo, respectively. But it will not run existing apps written for those environments.
However, it will run existing apps written for the S60 environment – which is the majority implementation of Symbian OS.
it will take developers as long as two years to meld all the pieces of the unified open-source platform Nokia plans.
But there’s no need to wait for two years before working with this software. That software will represent a smooth evolution of existing Symbian OS. Symbian OS will continue to be updated regularly, with new releases continuing to appear roughly two or three times each year. Any effort applied by developers to create solutions for these existing and forthcoming releases will be well worth it:
- These solutions will run on the smartphone platform that has by far the largest marketshare
- These solutions will also run on devices running the version of Symbian OS released in due course by the Symbian Foundation.
In conclusion, I don’t agree with any implication that the Symbian Foundation is going to result in slower software development. On the contrary, the outcome will be deeper collaboration and swifter innovation.
dw2 
To me, one of the best outcomes from closer integration would be removal of some of the remaining “Chinese Walls” that still seem to exist between Symbian and Licensees.
From personal experience, these include, for example, documentation (you may have noticed by now that this is one of my pet subjects :-)) and the build system. I have followed the Carbide.c++ 1.2 and 1.3 betas quite closely, and I was amazed by how difficult it apparently was for the Carbide team to contribute back improvements and requirements to the Symbian SDKs. In some cases, it seemed from the outside as if their influence and insight was not really much bigger than that of any other 3rd party developer.
Of course, modifying the underpinnings of such a complex system as Symbian should not be undertaken lightly, but it appears to me as if some aspects e.g. of the toolchain seem to be effectively as frozen as Microsoft’s Win32 API, because there are already too many dependencies for anyone daring to touch them.
Then again, this may be more due to the release cycles of SDKs than anything else: Most likely, any fixes made to a Perl script today will only reach the hands of developers with an SDK released two years from now at the earliest, largely because of the monolithic nature of 3rd party SDKs (toolchain and documentation being considered inseparable from specific APIs versions).
If additional committees can help speed up improving the flow of information “from the coalface” back into those areas, and achieving a more modular architecture, I am all for it.
On the other hand, they might also lead to a more “clubby” approach where the distinction between those on the inside, who can get their itches scratched quickly, and ISVs who have to work to rigid published interfaces, becomes even more pronounced.
Or is this perhaps an issue of “self-organized under-resourcing” that seems to affect all software projects alike, regardless of what size [any project will tend to a point where it just about lacks the staff to implement everything it set out to do, because this is the only state in which gains and losses in efficiency become measurable]? 🙂
Comment by mgroeber — 14 August 2008 @ 8:36 am