WE DEVELOPERS ARE AFRAID OF OUR USERS

Someone mentioned this a while ago, and although my first reaction was outright refusal, after a while I had to accept it:

We developers are (or at least this one is) afraid of our users.

Why do I say this? Because it’s true. I can show you at a simple example:
I started a small project that did little more than scratch a personal itch I had. It was barely configurable, didn’t perform very well and was kinda hacky but it got the job done. I was happy.

Then I went and published it in the hope that is was useful for others. And boy, did it ever.

It got a massive code submission from a single individual and several smaller ones from other people. I’m very flattered by that, because it got mostly rid of the “hacky” and got rid entirely of the bad performance. People also added a bunch of cool features and interoperability with similiar tools. User numbers rose. I have been contacted by ISPs that use it on their customer-facing side. That felt good.
And bad. Very bad.

I got afraid a bit. I freaked out a bit more. What if I made a mistake that I didn’t notice during testing? Might I destroy a bunch of data other people relied on?
Sure, I could always say it’s GPLv2, you’re responsible for backups, yadda yadda. It wouldn’t change the fact that people would be mad at me. I don’t want people to be mad at me.

Also, I got more than a hundred issue reports. You might think that’s a good thing, but it eats into time. It eats into motivation. It eats into the ability to make decisions.
See, every time I get motivated to work on that project, I think: Before I work on new features, I should work on those bug reports. No point in something that might end in feature-creep when there’s people who can’t use the software at all. So I check the bug reports. Try to reproduce them. Sometimes can’t because I don’t have access to the server software they’re using. Ask the users for more information. Think about possible reasons. Check people submitting patches (thank you! Even when I don’t merge them (in time… sorry for that…)). Check the patches if they make sense, are useful AND correct. Contact the author for clarifications, documentation, intent.
That might take several hours and at the end of it turns out that most of the problems are configuration errors on the users end. The patches to the documentation are simply incorrect. Users not answering requests for more information. The patches I want to merge have been neglected for long that they don’t apply cleanly anymore (again, sorry).

At the end of two hours I feel exhausted and have got nothing useful done. I feel bad for that and put the project away again. Then I feel bad for that.

There hasn’t been a proper release of that project in forever. I could probably tag one today and it’ll work like a charm for 98% of the people. But the 2% will come and open issues that I might not be able to fix and the cycle starts anew.

It’s a project that probably grew beyond one person doing it in his spare time. But that’s where it still is.
So if you rely on it, or want to use it and just wait for a new release: I’m sorry and remember:

We developers are scared of our users. At least I am.

EOF

Category: blog

Tags: braindump developers users fear