So you‘ve decided to build a new product, and you even selected a platform and an operating system on top of it that are state of the art – the best money can get. Guess what? You won’t be able to continue with that platform and operating system for eternity. A couple of years will pass, and you’ll need to move on. On to the next big thing.

I’ve been with RADVISION for over a decade, mostly catering developers who need VoIP solutions to integrate into their own products. What I have noticed are two interesting things:

1. Many of our customers return back to license additional operating systems when they migrate from one platform to another: if once they developed on VxWorks, they now develop on Embedded Linux; if once they developed on Windows Mobile, they now develop on Android.
2. Some customers have their own solution already up and running on one platform – something that was developed in-house in the past. But once they move to another platform, the porting effort is so huge that it will cost them less to just license the technology and integrate it from scratch.

The best thing about catering developers at the level we do, is that we actually get to design and build architectures that are portable and modular. For us this means that we will be able to license our products to multiple vendors running on various platforms and that our products can usually cater more than a single, specific task.

Here are a few suggestions if you plan on developing a product any time soon, especially if you are working on the embedded or consumer electronics markets:

1. Always assume you will need to switch to another hardware platform in the future.
2. Always assume you will need to switch to another operating system in the future.
3. Modularize your code to the point of obscenity – you never know when a module you are developing now will be needed elsewhere in another project.
4. Split protocol implementation from application logic and application logic from the actual UI – you already know that by now, but I’ve seen too many mistakes in this area done in the past.
5. Always assume someone else (!) will be porting the code next time. Be considerate, document as much as possible and write the code as general as possible.

Take this thing seriously – the migration costs across platforms can be considerable ones, if you don’t plan for it in advance. And planning in advance means planning when you still don’t have any plan for migrating.