Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.
tote_b5 | 17 July, 2008 23:07
I've read a great article about multi-platorm development today. I've already been involved in the development of multi-platform solutions and I saw big sacrifices made for the sake of common codebase. Not all code could be shared this way, of course, there was thicker/thinner layer(s) on the top of common code. Generally the maintenance/improvement of common code was slower compared to one-platform-only cases and the code was less efficient, too. I was not convinced that it was worth doing it this way at all.
Having said this, I fully agree with the analysis above. I would add, though, that multi-platform development requires either highly-skilled developers with solid knowledge of each platform they're developing for or a team of developers writing code 1 man/platform with very good communication
within the team. Either choice could be right or wrong depending on
many factors, like complexity of solution, developer skills, proper
specification, etc.
Btw, Simon Judge has also added his valuable remarks to this topic.
Cheers,
Tote
tote_b5 | 18/07/2008, 09:31
Agile approach would help here, too, I think. Breaking down the features to smaller tasks, the milestone(s) to few weeks long sprints would enable prototyping, which is essentially what the customer also wants. We just have to convince them!
As to Simon's comment on the easiness of committing breaking code to source code repository, Continuous Integration could help here. Using a background service whose sole purpose is to "digest" newly committed code and let the team know the build result _instantly_ is really efficient.
Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.
Oh no, not "Big upfront design"
Sorcery-ltd | 18/07/2008, 09:16
I have to agree almost entirely with Simon Judge's criticism of the original article there. Anyone who's actually tried what Morten is advocating will find that the project wasted 2 or 3 months at the beginning designing details when they didn't have sufficient knowledge of the problem.
In my opinion (obviously I agree it depends on the project size, but assuming a small to medium project - large ones should be broken down into a series of small projects!) doing a quick prototype and then throwing it away and designing the real thing is likely to get the best result.
Unfortunately this usually only happens when some of the developers have done the "prototype" as a real project for someone else. With time to market pressures as they usually are, when the prototype mostly works someone always wants to turn it into the real thing as quickly as possible - producing a maintenance nightmare!
Mark