Wed 9 Aug 2006

Focus

I've been spending a fair amount of time over the past couple of weeks thinking about features and guidelines and things that might work and things that shouldn't. Whilst wandering the web on Monday night, I came across an link I had made to an article on the Creating Passionate Users site. In particular, this graphic:

(Image used under Creative Commons license, from here )

This strikes a chord with me. It also helped me pull together what I had been thinking about. It did not help me write it down coherently, but let's see how this goes. Let's go for a (long, rambling) wander from the world of commercial software services to the world of open source project development. With references to writing from people with far more clues than me.

[Aside, or advance warning, at least: I'm not quite sure who the audience for this post really is, but if you find yourself thinking "why aren't they listening to me?" when trying to contribute to software development (whether as a developer, a writer, a bug triager, whatever), it may provide some food for thought. At a minimum, it should clarify some of my prejudices.]

Users are an funny collection of people, particularly when you are building a framework or middleware service. Especially when you are building both frameworks and end-user products.

At the last company I worked at, I was fortunate enough to have a lot of interaction with both "users as developers" — companies wanting to use the services we provided (APIs for payments and bill presentation) to add features to their own websites — and "end users", for want of a better word. This last group I intend to mean people who are the ultimate users of the product, not building anything of top of the product. Of course, end users use a different set of services/products to developer users, but we built both.

I really have been very lucky in this respect. As a result of some of the work I've done over the last few years, I've sat down and worked with IT developers and business managers in some of the largest banks in the world, a large yellow and purple search company (down towards the bottom of an alphabetical list), local governments, national business, and small volunteer organisations. I'm pretty sure that isn't a completely normal set of experiences and it is certainly interesting work (although I'm using the past tense above, this is something that continues today in some of my gigs).

I say I was fortunate in the sense that it was good experience. I have learnt a lot. It is knowledge I use almost every day. I do not mean to say "fortunate" in the sense that it was always easy or pleasant. In those sort of situations, you get a lot of feedback. Some of it is even positive. Generally, pleasing users, particularly as the your user base expands appears to be hard. You may actually be doing a good job, but you don't always hear about it. Since pretty much all software builds on other software, I've been in the "developer as user" camp as well. I can confirm that, from that perspective, I am just as bad as the next guy: when a supplier sucks, I usually wanted to share my opinion with somebody. It was not quite as frequent, and it took a lot longer to become natural, that I really had to tell somebody how good something was.

There must be a law of business that says unhappy people give more feedback than happy people. There is definitely some validity to the idea that criticism has ten times the effect of praise — something that was brought home to me time and again when I was managing small or larger groups of people, but is relevant even in more or less formal business relationships. Think about that the next time you're a satisfied customer; try to correct the balance.

There's also a flip-side to this about how developers and companies can be more receptive to and less reliant on positive feedback. However, this post is going to be enough of a sermon already without me getting behind that pulpit right now.

Back to users: it's not infrequently said that 90% of software development is for internal use. I have no idea about the accuracy of this number, but let's use the 90% fraction as a proxy for "lots". If that is the case, then a very large number of developers do not get exposure to users in the wild. Sure, all software has users and it often pays to think of even intra-company development as delivering a product to a client, albeit an internal one. However, there are still differences. Internal users will often put up with more rough edges than the customer. They will often be instructed to use the product regardless (the always unpopular "user base by fiat" approach) and they often do not pay for the product outside of internal accounting funny money. Custom software (internal development frequently fits in this basket) that is asked for up front often doesn't leave the end user with a real choice of alternatives. So, again, they are more likely to "suck it up and make do" if they really need the result.

So dealing with users is hard, not always rewarding and it is a somewhat specialised area. Not every software developer gets to play in that field. Is it any wonder, then, that we often make hard going of this in Open Source software?

A publicly developed project accepts whatever volunteers it can take. The maintainers try hard to welcome all contributions, keeping in mind that different developers will have different experiences, expectations and motivations. It's a constant juggling act. Trying to balance the priorities of accepting contributions to build the project with the needs of the largely silent user base (and, let's be serious: if you think all your users are active participants on your users' mailing list, you need to wake up now). "He who writes the code makes the rules" is an oft-trumpeted credo in open projects, but I'm far from convinced it's a universally valid principle.

In the GNOME project, there have been multiple times when the usability team and the accessibility team have had to fight very hard to prevent something from going in that is deemed "cool" by the limited community of developers (not exactly a representative group of users by any means). Conversely, there have been times when a feature has been excluded with the claim that "our users don't need that", without (in my opinion), necessarily having irrefutable logic behind the decision other than implicit trust in the person making the proclamation. At other times, there has been cap-in-hand pleas for somebody to implement a feature that was greatly needed by those groups (or the documentors, or the translators). Of course, you can't force anybody to volunteer to do something and if nobody wanted to pick up these features, they either languished or somebody had to fund the development. There's a whole other essay in the "give thanks to.." department on that point (for now, if you're a GNOME user, just be very, very thankful to the organisations at the bottom of this page). I'm actually a pretty big sucker for the guilt trip — if somebody makes a good enough case and it's not being picked up, I'll often try to shuffle things around and see what can be done. But some stuff is just fundamentally hard. Or time consuming. Remember the volunteer portion of the commitment: this is development we do for fun, outside of the other work that pays the bills.

[Note: I'm using the GNOME project as an example here. Partly because it's been a couple of years since I made anything more than trivial contributions and partly because it is, by far, the project to which I have devoted the most hours over the years. I probably have a more balanced view of my experiences there than with, say, my current obsession.]

This balancing act between accepting available help and wanting to keep quality and relevance up to a certain level requires good maintainers and, to a great extent, a largely mature community who can still function despite hearing "no" from time to time. Sure, the person saying "no" might well be wrong in a "no for all time" sense, but my experience has been that they usually get the short- to medium-term stuff right and that's where the real game is. For an Open Source project, if you don't have a medium-term plan, you certainly don't have a long-term future, because you quickly discover you don't even have a short-term retention of your users (okay, that's pretty lame, but the alliteration was just too tempting).

Which brings me (finally!) around to the.. well.. not to my conclusion as much as to the point where I hope some people might think about the problems I've mentioned a bit differently than they did before and might want to push on to other thinking along these lines. To that end, some fairly recent blogosphere contributions on the similar ideas:

• The original graphic I post is from Ignore the competition over at Creating Passionate Users.
• Just today, the same site posted Are your users stuck in "P" mode?. The reference is to "P" mode on most digital cameras and it's about whether a product's potential is really matching up with its use. [Read the comments, too; particularly the early ones have some good thoughts.]
• I have some follow-up posts to do here, talking more about some rationales behind solutions to the difficulties I've mentioned. However, a good way to think about it for yourself is to read You can out-spend or out-teach and You ARE a marketer. Deal with it. from the same site.

Finally, sometime between draft number one and draft-whatever-I'm-up-to-now of this post, Jeremy Zawodny posted some thoughts about working at Yahoo!. Actually, his post was in response to a post by Matt McAlister on the same topic, but I don't subscribe to Matt's feed. I think Jeremy's thoughts more closely match my own (both in a general and specific sense) than Matt's. It was a complete fluke that these posts crossed my radar today, but the problems they mention are somewhat similar to the things I mentioned above and they bring things back nicely to the corporate world I started out in, all those many paragraphs ago.

Topics: software/django, software/GNOME