The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

is multiplatform application worth the effort?

Nowadays we have dozens of OSes and platforms, from 64bit to mobile phones, from Symbian to Windows Vista, from Intel to SPARC, from GTK to AJAX, etc. Fortunately, I had choosen a right development tool so I'm able to develop applications which can target most of (though not all) available platforms today. The tool is Delphi (for wintel based platforms) and Lazarus (for non wintel platforms).

I can't say that multiplatform application development is easy, but I also can't say it's very hard. Thanks to Delphi and Lazarus. Obviously the multiplatform development requires more efforts compare to single platform development. Not all same codes can be run on different platforms, so sometimes I must provide different approach for a same solution on different platform.

Actually, not all of my applications require multiplatform support, but I designed  them to be multiplatform from the beginning. I just don't want to build them from scratch again in case the multiplatform demand is come. I even design my application can switch among databases backend, in case my clients change his database system. I splitted up UI and bussiness logic very explicitly, in case my clients wants a web version of a desktop application (or vice versa). I design almost every aspect of the application can be changed/replaced due to client's demand.

Then, a question came to my mind, are all these effort worth it? Or should I simply develop for single-lockedin-platform/technology only and manage new development plan when demand of other platform is come?

Any ideas?

PS: Sorry for my bad english, I hope you can understand what I meant. :)
Bee Send private email
Tuesday, August 15, 2006
 
 
In general multiplatform is not worth it from a business perspective.
If you are selling a server utility such as an apache monitor then it might be worth it, very few desktop apps are worth doing.

Even if the cross platform build is painless ( there are little gotchas - which chars do you allow in a filename?)
 - support is a killer.
If you are the first Linux app the company has bought you get called about installing printers, mounting pen drives etc.
Martin Send private email
Tuesday, August 15, 2006
 
 
See this thread where I raised this issue last week. http://discuss.joelonsoftware.com/default.asp?biz.5.375466.18
Neville Franks Send private email
Tuesday, August 15, 2006
 
 
Bee, I believe your modular design will help you whether or not you go multiplatform.  You can add and change features easily.  If there is a demand for multiple platforms, you can quickly and easily build those versions.  Maybe you could do what Steve Jobs did with Mac OS X: Build those other versions now, but don't mention them until customers ask for them.  In any event you're covered.

Your English is fine, by the way.

Tuesday, August 15, 2006
 
 
The biggest cost of multiplatform isn't being able to make the source compile *once* on all those platforms.

It's testing on all the platforms, fixing wierd quirks that occur on platforms, developing install procedures for all the platforms, tracking and testing new OS releases on each platform, etc., etc.,  You also must have access to all the hardware you need - because you can't just compile once on machine X and then never do anything with machine X again - what if you get a support call?
S. Tanna
Tuesday, August 15, 2006
 
 
S Tanna is absolutely right. There is a bigger picture to it.
Ezani bin Abdul Halim Send private email
Tuesday, August 15, 2006
 
 
It's very similar to: Should I care about supporting non-Engish languages now or later?

If you never need support non-English languages and know that you'll never need them, you can say, "To heck with Unicode!"

If you know that you might need to support non-English languages and keep the Unicode (or whatever) builds compiling, it won't be too bad when it actually happens.

But, if you've ever met a development team who did an all-English product and then added multi-language support later, you'll have met people who have lived through hell on Earth.  Adding multi-language or cross-platform support later, with the original code not caring about such things at all, is horrible.

You've got to look at the odds and make your bet.
Daniel Howard Send private email
Thursday, August 17, 2006
 
 
For me, when you talk about multiplatform, you are talking about two issues, which are only slightly related to one another.

1: Making your code compile on multiple platforms. This, in my opinion, is very useful, as it can help you expose bugs in your code easier. This is particularly true of subtle bugs. Having your automated testing process running the same test suites and code on multiple platforms is a significant win in my book.

Any amount of multiplatform testing you can do can help, in my opinion, even if it isnt the full application (say just the core group of classes, for example).

2: Shipping your code on multiple platforms. This is, at its heart, a business decision. Of course, if you do compile on multiple platforms, then the business decision is easier to make if there becomes a market for the additional platforms.

The real cost in multiple platforms isn't an engineering cost, it's a developer cost. A lot of the benefits for multi-platforms come from choosing the platforms though; for example, i'm not convinced you will get much benefit from building/testing your project on windows, os x (on an intel mc), and linux/i386. Many of the advantages come from architecture differences more so than os differences (although the os differences do force you to segregate the plaform specific code from the rest of the project).

If you don't have an automated build process, with an automated test suite along with code coverage analysis (so you know how effective your automated test suite is), you should not consider multiple platforms, unless it's a business decision to support and ship on that platform.
Brian Mitchell Send private email
Wednesday, August 30, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz