Designs by collaboration

12. Designs by collaboration

The previous chapter presented “the Symbian paradox”: developing a new release of platform software takes longer than allowing individual licensee teams to create their own product software which would, for them, achieve the same purpose. To gain their extra speed, licensees would base their work on a previous version of the platform software – or perhaps even on a different, simpler, platform. Because their ambition was less general, the licensees could proceed more quickly. The paradox is that the benefit to the licensee team is only a short-term one. The product software they create lacks longevity and extensibility.

Ultimately, the solution to this paradox is that the platform needs to:

  • Have a clear idea of what are its core parts, as compared to its peripheral aspects
  • Ensure that the core parts are indeed developed reliably and swiftly
  • Operate good mechanisms for bringing selected enhancements of peripheral aspects back into new versions of the platform, from the customer-led projects where these enhancements took place.

In the years that followed, Symbian became better and better at these three tasks – especially at the first two.

But this was not the only issue in the Symbian world that received the name “paradox”. In the long lead-up to the Nightingale retreat, I had identified something I dubbed “the fundamental paradox of Symbian product strategy”. I described it as follows:

EPOC technology will fail unless it is packaged along with working UI systems, but Symbian cannot spare the resources to create these systems – and in any case licensees rarely appear to be satisfied with the UI systems we provide for them.

The product design paradox

Here’s the issue. In order for developers to be confident that an underlying component of smartphone technology is working well, they need to embed that component in an overall system which subjects the component to a realistic and complete set of interactions. This “test environment” should enable developers to assess the performance of their component in circumstances that reflect the stresses and strains of actual smartphone usage.

Without an adequate test environment, faulty assumptions in the design of the component may go unnoticed. For example, aspects of the design might unwittingly assume complete control over smartphone resources (such as communications channels) that, in real world usage, need to be shared with other applications and other components. Or the design may assume that the data in the component is always accessed in a strictly sequential order, rather than via random access. These two examples are both relatively simple, but in practice many design mistakes are possible which are much subtler and more complex to explain.

Ideally, mistakes in design assumptions would be noticed during design reviews. In practice, it’s often difficult to anticipate, in advance, the full set of demands that will be placed on a component in the midst of an all-signing, all-dancing multi-tasking smartphone that contains new hardware feature that are kept secret during early development. That’s why a dual approach is needed:

  1. Challenge designs in advance, by peer review, before work starts on implementing them
  2. Confirm the designs, after they have been implemented (but before the design is frozen), via thorough integration testing.

Post-Nightingale, Symbian would only supply a single “Test UI” integration platform. This Test UI was, intentionally, not meant to be highly polished, from an ease-of-use point of view. Any such polishing would take effort away from work on the engine platform. Nevertheless, this introduced a new risk: the Test UI would fail to challenge the components properly. The risk is that shortcomings in the design would only be uncovered later, in the context of integration projects involving licensee-owned UI systems. By that time, the design of the component may have been frozen, with too many other components depending on it.

This may sound like an abstract concern. However, it describes what actually did befall Symbian, in the years that followed. There was an increasing mismatch between the design of engine components released by Symbian, and the way that Nokia would have preferred these same components to be designed, given the needs of the UI systems that Nokia created. In turn, this mismatch contributed to ever-lengthening durations for new Nokia phone projects, leading to the loss of competitiveness of the operating system itself.

Nightingale was aware of this risk in advance, and had a proposed solution to it. Symbian should:

[ SNIP ]

Recent Posts