My the Ephox bloggers have been busy this evening 🙂
Rob posted the second of his monthly braindumps about his new job, the poor guy has been stuck on our support team for far longer than we originally intended but he seems to be coping well. Although you can have my copy of Eclipse when you tear it from my cold, dead fingers 😛
I had to think for a second about why I liked his post so much, and I realised that we haven’t had a whole lot of feedback on how the team compares to other companies in the industry. Normally when you ask someone how they are going in a new job they don’t explain all the nitty gritty details you get from a well thought out blog post, and Rob is not only providing that he’s confirming many of my own experiences with the tasks our team performs. I hope he keeps posting them.
The most interesting part for me was his comments on just how hard it is to produce EditLive!. I’ve been full-time on the Java product for well over a year now so I’m used to it, but I had it easy because a lot of his comments also apply to our ActiveX product that I worked on for 4 years before switching. The difficulties become painfully obvious when you are on the support team and find out that not only do we have a huge range of users to support but it’s very hard to juggle all of those balls in one codebase.
It’s worth noting that carrying pain from support is a very important part of what we do as developers – but I’ll save that post for another day.
We have many amusing stories that float around the office of customers who underestimate the difficulties involved, one guy told us “you’re charging too much! I can develop this myself in a month” only to come crawling back 3 months later, another claimed that all Java applets can be made cross platform and if you need platform specific code then your applet sucks.
I say that if your applet doesn’t have platform specific code then you have a very simplistic view of the world. If we limited EditLive! to code that was purely cross-platform, some of our best features would have been impossible and our list of supported browsers would be much much smaller. Try writing an editor applet for browsers that don’t support LiveConnect and tell me how far you get, or creating dialogs that use Windows conventions when you’re trying to support OSX customers.
Don’t forget the bugs you have to work around in old JRE versions, customers with thousands of client users really don’t like being told “upgrade your JRE” and I believe someone did a happy dance when we finally decided to drop JRE 1.3 support. EditLive! pushes the limits of what is possible with the Swing Text APIs, and in many cases beyond the limits to support some of the HTML our customers use.
There is a reason we have so many enterprise customers and consider ourselves to be the best in-browser WYSIWYG editor bar none. We’re not afraid to explore strange and wonderful ways to support our customers or implement new features, and our extensive Java experience gives us the power to make it happen.