Over the past few months, I’ve been thinking about ways to become a better software developer, specifically in terms of Firefox extension development. I’m listing the ways that I came up with here; most of it can be generalized to the development of any end-user facing program or application, but I wrote it with extension development in mind. (I initially was going to call it “How to be a better programmer”, but as it turned out, the most important things I came up with had little or nothing to do with writing code.)
- Keep your ear to the ground.
Nothing is worse than finding out weeks (or months) after the fact that there’s a bug in your software that you never knew about. Nobody e-mailed you about it, you never came across it, so what were you to do? If you had signed up for Google alerts on your name/your extension/your website’s name, you might have heard about it from someone who blogged about it (“FeatureFox is terrible. It doesn’t even detect my COBOL widgets.”), but didn’t know how to report it as a bug.
Having Google e-mail you when your name or extension or website is mentioned in a blog post can be invaluable in getting feedback that you otherwise might not have read. (I also find it helpful to use TweetScan to sign up for an RSS feed of tweets that mention your extension. Twittering is the new blogging for many users, especially if it’s just a quick gripe about a buggy extension.)
- Give your users a place to talk to each other.
If you have a popular extension, that can mean that 100,000 users or more have it installed – one person doing customer support for 100,000 users will get old fast. I’ve found that if the users have a place to talk to each other (a comment thread on the extension’s home page, a support forum), oftentimes, the more savvy users will be able to take over a portion of this support duty by helping out a new user who may be in the dark about how to use a certain feature of your extension. Additionally, several users working together may be able to uncover the roots of a bug more easily than just you and a single user working on it. (“We’re all running Linux on a Mac with both Firefox and Seamonkey installed and we’re all using a non-standard profile directory? That’s a weird coincidence…”)
- Start a public bug tracking system.
If you’re not using some kind of bug tracking system (and I don’t include your e-mail inbox as a “system”), you’re not really invested in the success of your extension. Although many extensions are quick one-offs to add a new feature to Firefox, keeping track of issues reported by users is key, as 99% of software grows larger than originally anticipated. A public tracking system adds accountability, it gives other users a chance to chime in on a bug that they’ve experienced but didn’t actually report, and it frees up your inbox without casting valid bug reports by the wayside. (I recommend Google Code; it’s easy to use, has a nice issue tracker, and the support so far has been great.)
Release early, release oftenThe old saying “release early, release often” certainly applies here, but I’d like to warn against releasing too early. Uploading an extension to Mozilla Add-ons that only adds a non-functioning item to the Tools menu just to get it out there will do more harm than good, since users will intall it, see that it’s worthless, and uninstall it. Not only will they uninstall it, but they’ll be more hesitant to download it in the future.
Make sure your first release is functional, even if its function is small. It’s key to get users to download it, but it’s just as key to get them to keep it installed. From that point on though, release as often as you can, since everybody loves a good upgrade.
- Talk to your users
Whether it’s by blogging, Twittering, or creating a thread in a support forum, start a conversation with your users. To many Firefox users, software development is magic – the idea that a person can type up some computer code and make their browser do great new things is mysterious and wonderful, and being able to interact with that person allows them to participate in the magic. The most enthusiastic users (and sometimes the ones with the best ideas) are often those who would have no idea of how to actually write the software behind the features. (Perhaps the fact that they are unencumbered by the burden of implementation is the cause for their enthusiasm…)
- Be responsive
This fits in with the previous point, but it’s more specific. Once a user has posited a question in a support forum or a blog comment, the clock starts ticking. If it takes you a week to respond about why X or Y doesn’t work in your latest release, you can bet that by the time you do answer, that user (and a dozen others who wondered the same thing) have spent the 30 seconds it takes to uninstall your extension because you didn’t take the 60 seconds to respond to them.
On the other hand, timely responses give your users more faith in your commitment to the project. For example, check out this comment left on my blog after I quickly replied to a user about a problem with TubeStop.
- Participate in the development community
Mozilla has a great community of developers, and you’re doing yourself a disservice if you’re not participating. The Mozilla IRC channels and the mozdev.org mailing lists, for example, are both great resources for connecting with fellow developers to brainstorm over weird bugs or just talk about software-related topics. I like to keep this rule in mind: there’s always someone out there who knows more than you about extension development, and more likely than not, they’re on irc.mozilla.org.
What do you think? What would you add? Anything you disagree with? Reply in the comments, and I will, of course, respond.
