I’m starting to believe that developers of very small applications (widgets, applets, plug-ins, etc.) are not taking software quality seriously. The fact that their own codebase is small doesn’t mean that they have fewer defects per line of code. Further, often their “mini-apps” live inside large, complex software products with complex interaction behaviors. The simple apps may not get exercised simply at all.
The quality of mini-apps is becoming a big problem because there are simply so many of them. The categories I have in mind specifically are:
- Browser toolbars and plug-ins for all major browsers: lots of crashes there
- Applets: even major players such as AOL, which bought XDrive have issues.
- Widgets: JavaScript errors and cross-browser behavior differences are not part of a great user experience
- Desktop software add-ins, e.g., the ones for Microsoft Office.
For example, recently I’ve come to the opinion that Outlook add-ins are uniformly buggy. It used to be that Plaxo and LinkedIn would routinely fight over objects and crash Outlook. My solution was to put them on a separate Outlook instance running inside a virtual machine. I use them when I need to but I don’t let them run all the time. My email processing performance improved noticeably. The virtual machine trick is something I do a lot for non-essential apps and especially mini-apps. For example, I blog using Windows Live Writer, both because it is built by friends and because it is the best blogging editor out there. However, it only comes with the IE toolbar whose many extensions are not the most robust out there.
Recently, I had a problem with Kaspersky’s anti-virus mail add-in and Nobex Contacts kept causing access violations on shutdown. Yesterday, I discovered that the source of a rather peculiar email behavior was a bug in the Getting Things Done add-in I was using to help me adopt Inbox Zero. I’ve since removed it from my system.
Why can’t folks write better Outlook add-ins? I’m curious to try Xobni but not if they haven’t invested seriously in QA.
I recently tried Xobni for Outlook and liked its functionality, especially its search and related emails concepts, but after a week it started messing up – I couldn’t reply to emails – so I uninstalled it.
At least their uninstall asked why I was doing that, and one of the options was “Crashing Outlook”!!
Don, how was it performance-wise?
Simeon, performance was great – during install it indexes your entire Outlook system, which took about half an hour in my case. But once finished with that, it was instantaneous in every respect. It’s a nice system, still in Beta and still a bit buggy.
I’m pretty sure the Outlook plug-in model is at least partly to blame. Outlook doesn’t keep the plug-ins out of the main thread and every plug-in can process events for new messages in a serial queue. Most plug-in developers will only worry about their own plug-in.
In addition Outlook is the type of app that many people keep open all day so little things like leaking memory add up quickly.
I ditched Outlook 3 months ago for Gmail apps for domains and have been mostly happier though I do miss some things.
Greg, you are definitely right that the plug-in model in Outlook was an afterthought. It still doesn’t excuse people from writing poor software IMO. Just the opposite–if you know you are going to live in a “mission-critical” knowledge worker app with a bad plug-in model, you should be twice as careful.
I have a love/hate relationship with Gmail. Can’t see myself using it as my mail client thought there are many things about it that I like a lot, e.g., focus on labels/tags/categories.
The size of the code base doesn’t really matter when it comes to security. A big vulnerability is a big vulnerability whether it is in a small or large applications. I don’t like to measure vulnerabilities by density. That is giving a free pass to developers of feature rich bloated code.
That said, while it is very difficult to make a large complex app vulnerability free, small apps have a fighting chance. You are correct that typically they don’t try. There are many reasons behind this. Small app vendors are usually making money in non traditional ways and may not have the resources to fund a QA staff. Their is little risk to their business if there is a vulnerability found in their applet.
On the other hand there is a lot of risk to the businesses of people who provide a platform for applets and widgets. It is usually the name of the platform provider that gets dragged through the press. It is reported as an “Internet Explorer toolbar vulnerability” or a “Facebook applet vulnerability”. Platform providers should be incented to rate the code they allow on their platform so there is a security threshold to cross. This will protect the value of their platform by protecting their users.