On Support

Simon Willison points to a Forrester Reasearch publication (being offered for $49) that cites Greasemonkey as a reason for corporate IT departments to delay or avoid Firefox deployments. For those unfamiliar with Greasemonkey, it’s a plugin for Firefox that allows users to create custom JavaScript to be attached to invidual web pages, changing their functionality in much the same way that user style sheets can change the appearance of a web page.

Simon calls the report FUD, which it may be, and defends the right of corporate web users to employ such means:

…tools like Greasemonkey are a fantastic way of fixing issues with the atrocious interfaces found in many “enterprise” web applications.Workers who use Greasemonkey to improve their productivity by fixing problems with internal applications should be applauded.

While I have nothing against Greasemonkey, this statement gave me pause. It reminded me of a parallel situation I have seen often as a corporate developer- Excel VBA Macros. Working for a financial institution, many of my non-IT co-workers are advanced power users of applications such as Excel- but they are not programmers. Many is the time that I (or my department) have been called because some business process is broken- only to learn that the process is one we’ve never hear of. Most often it is an Excel solution that uses VBA macros, which usually begin as a recorded macro and grow over time, and that was developed by an end user. When we are called in, often the original author is no longer with the company (interns are notorious for building these things). The end user only knows how to push a button, and has no idea what to do when they see a VBA error dialog.

Why do these grassroots solutions break? Ignoring for a moment the questionable nature of Excel in general and VBA macros in particular, there are still many factors. Foremost is the fact that these users aren’t developers. These solutions generally have no error checking (or worse, on error resume next, VBA’s way of saying, “Don’t stop just because it’s broken”). These solutions are often built from a recorded macro, and so they have all of the implicit assumptions the user made when recording the macro. Just because your query returned data in column K doesn’t mean it always will. Another major factor is lack of awareness- the users don’t know when things external to the app will change- DB schema, filesystem paths, etc- and the IT department doesn’t know that some guy in accounting has a macro that will break when the upgrade the file server next weekend and change the server name. In addition to these problems, there’s no Q/A, no source code control, and no documentation.

So when the inevitable day comes, when Joey Intern is long gone back to college, when the third or fourth person to inherit this spreadsheet gets and unexpected error or incorrect results, what do they do? They call the helpdesk, of course. The helpdesk has no record of such an app and no documentation on how to support it. Yes, they can support Excel, but they have no clue what the macro send_daily_faxes does or how it works. So they send the problem to the developers- whoever has VB and/or Excel experience. Now we (development) have to support something we’ve never seen, not written to corporate standards, with no documentation.

The developers will calmly tell the user that this is not supported, that we have no idea where it came from or what it does. Sometimes they have to accept that, and if the need is sufficient, make a request for the development staff to build a tool which does the same thing (as they should have dome from the beginning). Sometimes, the developer has to bite the bullet and kill the better part of a day figuring what to fix so he can fix it. After all, if this thing has been used for the past three years to send faxes to clients each day with important financial info, we can’t just call the client and say, “Sorry, your daily fax was sent with an unsupported tool. We’ll build a new tool in month or two.” Even then, we try to schedule work to replace that macro with a supported solution.

I hope the parallels are obvious. While writing custom JavaScript for use with Greasemonkey is more complex than recording (and extending) an Excel macro, there are those who will try it. Every such modification that becomes critical to daily operations will eventually be shared and/or handed down, and one day they will break. Who will fix them?

Both comments and pings are currently closed.

2 Responses to “On Support”

  1. Matthew Gertner Says:

    Greasemonkey: an Historical Perspective<br/>

    Your analogy between Greasemonkey and VBA macros is quite apt. In both cases, corporate IT departments are likely to condemn the practice (i.e. although I haven’t read it, the Forrester report doesn’t sound like pure FUD). At the same time, there is a legitimate issue of user empowerment which conflicts with, but is not necessarily trumped by, the interests of the IT people.

    I just wrote an essay that takes a slightly different tack to make a similar point: http://www.allpeers.com/blog/essays/greasemonkey.htm

    I look at the original goals of the XML movement and how they are being threatened by HTML hacking. I should stress that I have as much fun hacking HTML as the next guy, but I believe that we need to be pushing this trend towards a cleaner, XML-based approach in any way we can. I make one concrete suggestion for improving the existing chaos in the Greasemonkey world. Even if this doesn’t resonate with the Greasemonkey community, I hope it will spark some additional ideas.

  2. Uncle Roger Says:

    Another issue with such a plugin<br/>

    Note that I am completely unfamiliar with Greasemonkey and have not read the linked articles. However, in reading your post, something comes immediately to mind:

    If you have a web-based application that requires user interaction, it sounds like Greasemonkey could be used to automatet that, circumventing checks and balances put in place by the developers. In most instances, it is probably for the best (improving productivity and all that) but there might be situations where that would be highly undesireable.

    Consider the password remembering feature of firefox and others. If you’re on your computer at home and you want it to remember your slashdot login, that’s probably a-okay. If, however, you’re at the local cyber-cafe, you probably don’t want the next customer to be able to log in to your bank account automatically.