macrobug

Whilst at the device manufacturer, I had an opportunity to let a small team borrow some of my tools. They used them to solve a real, tricky problem.

Don’t get too excited - Macrobug is still vapourware. This was a special case because:

1. Since we were all working at a device manufacturer, we didn’t need special access to Symbian OS.
2. The tools used were some of my early Perl prototypes - not my recent Java-based code. That’s just because my current codebase is Eclipse-based.
3. I was there so was able to fix the bugs that became apparent during the process.
4. I didn’t charge for the privilege :-)

Nevertheless… hopefully this has shown at least a couple of engineers that Macrobug tools are invaluable - I think they would have been looking at this particular problem for another couple of days otherwise.

Better still, those engineers are in two different companies, so I’ve now got useful contacts in both those organisations, who will hopefully listen when I come a’calling in the future…

Lessons learned

For the past eight weeks I’ve been working on-site at a Symbian device manufacturer. As well as providing enough money to keep me in jaffa cakes, it’s given me helpful pointers about the directions my tools should take, if I want to sell them!

In particular,

1. I’m too premature in targetting Carbide. Originally I was thinking that I’d have stuff to sell about a year after starting Macrobug, which is about when Carbide would be fully rolled out everywhere. Nine months into that year, there’s very little sign of Carbide roll-out at this device manufacturer, and even once it has rolled out, I actually think many engineers will prefer their tools old-style and standalone, rather than as Eclipse plugins.
2. Targetting WINS won’t do. I knew it wouldn’t be sustainable forever, but at this manufacturer at least, the emulator has a very low profile. Nearly everything is done on target. I know other manufacturers work the opposite way round, but then again, those who choose to work mainly on hardware are probably those who are going to have the biggest problems and therefore be most in need of my tools!
3. Real-time tracing may not be necessary. I was able to use many of the same techniques to analyse events after they’ve occurred.

So what does this mean? Well, I can use my existing code base to produce three ‘levels’ of tool sophistication:

• Command-line utilities
• Standalone GUI tools (probably based on Eclipse RCP)
• Eclipse plug-ins for Carbide.c++

So, from now on at least, I’ll be trying to write my code in a less Eclipse-dependent fashion, so that it can be used from standalone tools too. I’ll gradually be translating my various libraries to more generic Java code as well. And of course I’ll be trying to get everything to work on static dumps of trace data, either from the emulator or hardware, rather than a continuous real-time feed from the emulator in Carbide.

Having said that, Eclipse is still terrific and it’s the future of Symbian OS development. It’s just that I’ve realised I can’t ignore the present!