Archive for November, 2010

Thinking ahead

Thursday, November 18th, 2010

Ericsson has launched, during 2010, a blog geared towards new ideas and different perspectives. One of the main goals of ‘Thinking ahead‘ (the name of the blog) is to foster open debate around the future of communications and how these will impact our lives. I think this is a good idea, especially that both bloggers from inside and outside of the company are invited to share their vision.

Now I’m one of those bloggers. My first post – about computing swarms – just went live and more will likely follow. Check it out and feel free to comment, either there, here or in both places 😉

1+1 of modeling

Tuesday, November 9th, 2010

Ericsson has been a big supporter and user of modeling techniques – a large share of our 3G systems were developed using modelling tools. Myself, I spent a fair amount of my time at Ericsson using modeling to write code.
Recently I was wondering quite much about what modeling really brings to the table. Is it higher programmer productivity? Efficiency of resulting code? Portability? All of these at the same time? What can modeling offer that you won’t find in competing technologies?
Modeling inherently means that a graphical environment is used to describe the system at various levels of abstraction. I believe this is one of the major benefits of modeling: it’s much more easier to grasp the high level structure of a complex system from a diagram that is integral part of the system itself than from reading actual code or relying on likely outdated descriptions. This quality of modeling is hardly ever disputed – and for me, it was always the most imediate benefit. Obviously, it positively impacts programmer productivity: as the learning curve is easier to climb, programmers are quicker at getting at the point of producing code. But once there, can modeling help them further? Not really. Further benefits come from using higher level action code languages – something that can be easily matched by textual languages.
What about efficiency of target code? We were able to generate quite efficient code that basically matched the performance of hand-crafted code. But, here’s a little secret: much of this efficiency is down to two factors. First, programmers still wrote substantial amount of action code that is preserved as such; but, more importantly, we actually used a specific application model – the actor model – best suited for the type of spplications we were developing. Modeling obviously helped with generating most of the default code (state machine, message passing etc), thus the programmer was able to focus on the actual problem rather than implementation details.
Portability. Well, again, modeling in itself won’t help you, sorry to say that. The programmer has plenty of opportunities to ruin it when writing action code – unless the action language is preventing it. Which brings us back to the need for high level languages, which is again orthogonal to modeling itself.
So, what’s in it for modeling? At the end of the day, it’s the possibility to visualize software in different ways that reduces dramatically the cost of grasping and reasoning about a complex system. The other properties ascribed to modeling – efficiency, portability, some aspects of productivity, automatic code generation – are actually the results of using high level, domain specific approaches that hide non-essential details in the run-time system and the compiler; however, combining these with modeling provide a powerful combination.