Common Source vs Common Specification

Morten Hjerde has an interesting post on mobile Multi-platform Development. I have worked on projects that are common source and common spec so here are a few observations…

The main problem I have seen with common source is that it’s very easy for anyone to ‘break’ the code so that it no longer compiles. Despite rules, guidelines of whatever, people will always put stuff back into source control that doesn’t necessarily compile on other platforms. On the plus side, it’s possible to have non mobile developers writing code. This is especially an advantage when working in areas where there are highly specialised domain experts. I saw this when I worked at Philips on Mobile TV.

Note that working with common source doesn’t have to be inefficient. Often the OS abstraction layer (e.g. file handling, event handling) is actually very thin and just involves a few very simple calls to the OS for each particular platform.

Morten says of common spec

"Like a detailed architectural drawing, a common spec must be highly detailed and include the exact visual representation, the interaction design, the complete technical architecture down to the individual method and class names and their documentation."

The problem with a common spec is that a lot of time can be spent up-front thinking about the application when, in fact, all this will change as the application evolves. The spec easily goes out of date, becomes impossible to maintain and can be difficult to do create anyway due to differing platform idioms (different ways of supporting async operations for example).

Two further approaches I have worked with, that Morten doesn’t mention, are evolving from a single platform and partial common source. Evolving from a single platform requires more time but allows the project ideas to be tested and changed before committing to all the other platforms.

Partial common source allows the common source to be the ‘business logic’ with variant code for each platform (mainly the UI and some ideom specific stuff). This requires careful design. The common source tends to be c as all c++ compilers also support this. The disadvantage is that it’s not portable to Java specific platforms.

I’d recommend people be more flexible and pragmatic than Morten advocates. Even consider a mix of approaches if necessary. Look at the pros and cons of each approach and decide depending on your exact project. Assess factors such as project size, time to market, platform features, whether realtime or not as well as available software skills.

One thing I do agree on is that code rarely contributes to project failure. It’s more likely how the project is managed and marketed.