I took part in Charles Weir’s Supporting Many Platforms session at the ACCU conference (URL) yesterday.

Charles heads up Penrillian, a company specialising in porting applications between mobile platforms and between different implementation languages.

The first question was why port? why not just start again from scratch? The answer is that rewriting from scratch is in most cases very expensive, it’s almost impossible to reimplement from a specification (or rather to rewrite the specification from what you’ve implemented). Furthermore, while you’re rewriting you’re not advancing and so you lose time in which other software may be moving forward in the marketplace. (Internet Explorer overtook Netscape while Netscape was being rewritten.) In a Software Product Line setting you have to produce so many product variants that it’s simply not practical to rewrite from scratch each time.

Charles presented three key techniques to perform the porting process:

Code Triage - Begin by dividing the codebase to be ported into portable code, potentially portable code (which would be portable if it was refactored) and platform-specific code (examples of this are typically found where the code talks to the outside world e.g. device hardware, networks, UIs etc.). Charles also noted that this triage process implies some architectural decisions to minimize the size of the non-portable code.

Refactoring to produce portable code - Much code could be portable if it was refactored “ business logic and rendering code are prime examples. Typical issues Penrillian have encountered include UI event handlers that do business logic, rendering code for a fixed-size screen, communication interfaces that aren’t abstracted.

Test-driven porting - Changing code introduces bugs and so you need a safety net. The process used at Penrillian starts by ensuring that the code is under test on the original platform. When this has been achieved logging is used to record calls and responses at the points where the program calls non-portable code. This logging data is then used to generate mock objects (URL) to mock-out code for your new platform. Once you have this in place you can begin your reimplementation of platform-specific code safe in the knowledge that your safety harness will catch any problems in your new implementation.

Charles concluded by noting the two worst mistakes when porting:

• Thinking something isn’t needed when you port - it usually will be.
• Not using testing to support your construction process.

At the end of the talk I asked everyone what his or her thoughts were on device convergence in the mobile space. I’ve participated in a few of the sessions run by Cambridge Wireless’s Mobile Games group and these always seem to end with the hope for greater convergence in the device space. As I’ve previously noted, 50% of the development budget for a mobile game can be consumed by porting costs.

The first observation was that convergence is nice because there’s so much of it. More seriously it was also observed that vendor lock-in relies on divergence and it’s my own view that the pressures operating in this market will force continued fragmentation in device platforms and capabilities. The forces for convergence are simply not strong enough yet.

Penrillian has a number of links to mobile porting resources on their web site at http://www.penrillian.com/porting.

Day 2 of the ACCU Conference saw me at Peter Sommerlad, Kevlin Henney,  and Giovanni Asproni’s session on the value of simplicity in software development. 

This was a workshop session with the aim of working towards a Manifesto for Software Simplicity along the lines of the Agile Manifesto. With a keen and knowledgeable audience we stood a high chance of success…

Kevlin, Peter and Giovanni began by talking about their previous work in this area and what brought them together for this session, for example Peter is hosting a wiki on the topic.

As background to the workshop, the Laws of Simplicity, as formulated by John Maeda, were introduced:

• Reduce - Shrink, hide, embody (by abstraction) to make things simpler.
• Organise - Make a system of many appear fewer. (The system then becomes easier to abstract and has a higher degree of regularity). Patterns / Themes, Grouping and Clustering are key tactics here.
• Time - Savings in time feel like simplicity. When you deal with something, if you can save time by dealing with it in an easy way (or automating it) then things are simpler.
• Learn - Knowledge makes everything simpler - build models of domains to make your life simpler – you can identify patterns that you’ve solved before etc.
• Differences - Simplicity and complexity need each other – contrast makes simplicity appear good.
• Context - What lies in the periphery of simplicity is definitely not peripheral. If you understand the context then you can make things simpler – if you don’t then you can’t. Defining the (domain) rules can help communicate ideas and improve learning.
• Emotions - More emotions are better than less. Individuality comes through simplicity – making things simpler is inherently creative and satisfying. Emotions have an impact on what you think is simplest in a given context. Acknowledges humanity in coding activity. Gut reactions to code based on expertise and experience.
• Trust - In simplicity we trust. You trust things to do the work you expect them to do – but if they’re complex you don’t trust them. If you don’t trust stuff then you make things more complex by erecting elaborate barriers between things.
• Failure - Some things can never be made simpler. Recognising that you can’t make something simpler saves time (and so makes things simpler).
• The One - Simplicity is about subtracting the obvious and making it meaningful.

Three Key Patterns were also presented: 

away - More appears like less by simply moving it far, far away. (This relates to levels of abstraction).

open - Openness simplifies complexity. Leads back to learning.

power - Use less, gain more. Less code => more software.

After the introduction we divided into groups for a bit of brainstorming around our beliefs about simplicity in software and then reviewed and discussed what each group had come up with.

My own best contribution was ‘Simplicity is Satisfying’; other things that resonated around the room were (paraphrasing):

• Duplication is anathema to simplicity, cut & paste is evil – a good argument for (software) reuse.
• Automation is good because of time-saving and its capability to hide complexity –
  Rewriting poor code is leads to more simplicity than refactoring it.
• Doing one thing well leads to simplicity, constraining scope is good – there could be some relevance for people developing Software Product Lines.
• Component / Library / Compiler complexity is favoured over code complexity. Code should be human readable. It’s interesting that compiler was named specifically here – I wonder if a generalisation can be made in favouring tool sophistication over code complexity?
• We believe in not crossing bridges until we come to them (in case you don’t have to) – there was an interesting discussion here around the trade-off between planning and simplicity.
• Design by contract makes things simpler – both by making assumptions explicit and by providing a form of contractual framework that enforces consistency and simplicity.
• Dynamic languages are preferable to static languages (for simplicity) – a theme that also emerged at SPA 2007.

The full session outputs are now available on Peter’s wiki here.