Musings from The Software Underground

This weekend I read two blog posts containing some of the things I've been meaning to write about for a while, which is: the hows and whys of requesting new features from us, the developers of the products you use and love, and what actually happens behind the scenes. First up is a Brent Simmons post at inessential.com. Brent, whose posts sometimes seem to inspire me to action in my own blog, captures things pretty well in this nutshell:

Imagine you’re in my shoes: you’re me, for a minute. Think about feature requests, for example—you have a list several hundred items long of really, really good ideas. You’ve heard pretty much everything multiple times, though now and again you do hear new ideas. Which just makes the list longer!

Then of course there are bugs to fix, schedules to meet, tests to run, docs to update, user interfaces to design, lots and lots of things. Most of your time is spent just sitting in a chair, coding, because that’s the only way things get done. (Oh, and then there’s email. And writing blog posts. And so on.)

I honestly couldn't have put it better. Your one feature, though important of course, to the developer falls somewhere on this BIG list of items, with the requests of a lot of other people. For me, things often get ranked based on number of requests. I'll admit features are also sometimes ranked by how badly I want to implement something as well, my own pet features if you will. (Hey if you can't do that as an indie developer, what's the point? You might as well be working for someone else and making a lot more money).

Brent goes on to describe the email messages that he, I and probably every other developer with an email address has seen: ones that try to influence the developer into adding the sender's feature. I've actually had a couple of the "being mean" approaches, and honestly, I don't understand what the person thinks might get accomplished. You catch more flies with honey is just as true when trying to influence developers. A nice, clear and concise message containing what you want, and how you would use it will work much, much better than "I'd buy your program if only..." or "until your application does X it's useless" messages, believe me. Good reading overall, and I recommend all non-developers check it out.

The second post from this weekend is from the Paul over at Rogue Amoeba. It's titled Pistols At Dawn or How Not To Request A Feature, which is actually from December of 2004. My how things change, and how things stay the same.

I love the list that begins the post:

This is simply a treatise on a topic familar to all developers, to which they may point as needed. It begins with a 3 things to keep in mind when asking for a feature:

1) Be aware that you don't represent all of our users.
2) Don't browbeat us.
3) Our job isn't as easy as it looks.

It goes on to detail again how difficult adding new features really is. It's much harder than the lay person would believe, especially if you are a developer interested in keeping a nice balance and design to your application.

The gruesome truth is that every addition has a ripple effect. Changes often expose little-known bugs or subtley corrupt the overall design. As an application grows, it becomes more and more unwieldy, a veritable Jenga tower of features, flaws, and fourteen hour days. Every change is a tremor that shifts the balance of the application.

True. True. I've been accused by one user of working at a "glacial speed" but really I only take the amount of time that is necessary to actually design and implement new features properly. You might be surprised at what can go into the design of even a small feature. Sometimes I build prototypes, sometimes I try implementing a nearly fully-realized feature only to decide that it doesn't work "quite right." I refuse to have features that appear to be "tacked on." Could I work faster? Definitely. Would the quality be as good or better? Absolutely not. I honestly believe in software as art, and art cannot be rushed. What Paul says next sums up the mindset I have as well:

We need look no further than Microsoft Word to see that it's easy to add lots and lots of things. There's a great word processor buried in there somewhere, but each and every user has to work to dig it out from under the 80% of features they'll never used. Instead of this jambalaya style of design, we strive for a simpler, more elegant (and Apple-like) approach. Our software may not do everything, but everything it does, it does well.

So true Paul, well said.

I'll end with what Paul from Rogue Amoeba ends with, which is a great conclusion:

Finally, recognize that it's never as easy as imagined to add a feature request. In fact, it's usually much harder. Ideas are great, please submit them - just give us the ability to say "we'll consider it" without needing to defend our very honor.

So, ask away, please send in your feedback, it's definitely appreciated, but know that a lot goes on behind the scenes from the time a request is received to when it is actually implemented. If you don't see it right away, know that it's most likely somewhere on "the list" and will be addressed at the proper time.