Slashdot Mirror
Ask Slashdot: How Do You Explain 'Don't Improve My Software Syndrome' Or DIMSS?
dryriver writes: I am someone who likes to post improvement suggestions for different software tools I use on the internet. If I see a function in a software that doesn't work well for me or could work better for everyone else, I immediately post suggestions as to how that function could be improved and made to work better for everybody. A striking phenomenon I have come across in posting such suggestions is the sheer number of "why would you want that at all" or "nobody needs that" or "the software is fine as it is" type responses from software users. What is particularly puzzling is that its not the developers of the software rejecting the suggestions -- its users of the software that often react sourly to improvement suggestions that could, if implemented well, benefit a lot of people using the software in question. I have observed this happening online for years even for really good software feature/function improvement ideas that actually wound up being implemented. My question is -- what causes this behavior of software users on the internet? Why would a software user see a suggestion that would very likely benefit many other users of the software and object loudly to that suggestion, or even pretend that "the suggestion is a bad one?"
Sometimes what is an improvement to you is worsening for someone else. E.g. the australis redesign of firefox, was very highly disliked by many people. Some people are happy with the status quo and don't need a new "modern" re-do of their GUI or whatever.
Many people are very tired of their software constantly changing and shifting for no good reason. Oblig car analogy: suppose that every night when you get home, park your car and go inside there was a good chance some random mechanic would come along and start tinkering - moving the controls around, swapping out the seats, adding go-fast stripes (then removing them), maybe switching the engine or making it an automatic. It would get old really, really quickly.
That's what it feels like sometimes with software. See for example Firefox over the last few years: features coming and going for no apparent reasoning, random changes, just generally irritating. It's enough to give you a case of PSSWIS.
Because every change breaks someone's workflow. https://xkcd.com/1172/
Yes, sucking resources away from other users is one reason.
Others:
- Your feature or changes almost certainly comes with added complexity and/or bugs. People don't like that.
- People resist change just as a matter of being human. Any change needs to overcome this "static friction".
- Admitting that you have a better way is also an admission that they've been doing it wrong (or less efficiently) the whole time. People don't like to do admit they are wrong.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
But its true, so I'm going to lay it on you.
Most people do not use software for the sake of using software.
I Know. I can hear you cry and see your tears. Get over it.
Strange as it seems, they use software to get stuff done. Its a tool. They learn the tool to get stuff done. They setup up processes that incorporate the use of those tools to get even more stuff done. And then *poof*... iPhones! Woo!
If you're constantly changing the tool, you're constantly changing the way people have to get their stuff done and constantly upsetting the process and increasing the cost of getting stuff done.
Try this for a mantra:
What do we Want?
Gradual Change!
When do we want it?
IN DUE COURSE!
Change is good, I'm on board. But take care how you fuck things up in the name of progress. Understand that yes, in some peoples view your wonderful improvement is fucking things up, and they are not in error . That doesn't mean your idea isn't great, it just means you probably haven't thought it through well enough. That said...
Usually people tossing out these ideas have little idea what they're talking about, with respect to what it would take to achieve.
OK, this is turning into recreational bitching (turning into?).
I have two shorter answers to this question, one polite, one less so
I don't know if you've been keeping an eye on things, but generally "improvements" aren't.
Examples:
There is a reason why User Experience (UX) people are so hated - because they take a nice, big, fat dump on existing users to improve things the way that THEY want, and, again, tough shit if you liked it the other way, and tough shit if it breaks the software for many users, or even if it breaks the machine. It's not unlike an interior decorator trying to make a "statement" in many cases. Not unlike one of those shows where they have someone come in and "redecorate" the house and it turns out to be a total nightmare. This is not helped by the fact that with many situations, updates are now FORCED, so you can't throw the interior decorator out. In many cases, companies and organizations act as if you don't own the computer (and in many cases, the companies want to own the computer you paid for, and they treat the software like they do in fact own the machine). And even if you do, they usually manage to cripple you in some way (usually compatibility) until you're forced to capitulate - and things are usually even worse by then.
Note, however, that this does NOT necessarily just apply to the UI, in case I've overemphasized that - it works with any and every aspect of the software that can be changed. In short, in
"People resist change just as a matter of being human. Any change needs to overcome this "static friction"."
I'll tell you why I resist change in the software I use. Software upgrades often come with changes to the UI which often require that the user relearn how to use their software. There are few things i hate more then having to relearn how to use software features I was already using.
I ignore Anonymous Coward posts. If you want to discuss something, that's awesome. Log in.
When I was a younger programmer, I thought, "Features are great! Always add a feature, if it could help someone!" I overestimated the value of the feature, and didn't think at all about the costs of the feature. "I mean, how long does it take to implement this? 10 minutes? A couple days? What's that matter, vs. the utility that this would provide?"
What I didn't realize at the time was that every feature basically adds an exponential cost, and has an impact on everything else going on in the codebase. Features introduce new possibilities, and new possibilities create new state combinations, and new state combinations create new bugs and new need-to-test circumstances. New features usually have a user interface impact, several new features have a dramatic user interface impact. New features need to be supported by new or future-self programmers, who have to understand and navigate around the code. If the product is ported, the feature needs to be ported as well. New features also require additional documentation, and if the product is localized the new documentation requires new localizations.
I've heard that "the skilled Go player is reluctant to make a move." I think it's similar for the application developer, and for much the same reason.
Also maybe his suggestions are crap and the guy has an overinflated sense of his own opinion.
> maybe his suggestions are crap
Maybe his ideas are crap. There is no way to tell since he didn't give / link even one specfic example.
Maybe the way he presents his ideas is a problem. A very common problem os suggesting WHAT might be done, without mentioning WHY. You always need the why, and should lead with it. Think commercials "do you have this problem ... Our product will fix that problem for you. You'll benefit in three ways, X Y and Z." Often people suggest "let's do this" without clearly stating the problem it'll solve or the benefits of their suggestion. There is no way to tell if tje submitter does this since he didn't give / link even one specfic example.
What we DO know is something about the submitter's writing style. We know he *assumes* that his ideas should be implemented, and further assumes that we'll agree - without even telling us what any of his ideas are. Likely, he does the same thing in his suggestions - assumes that they should be done, assumes that everyone will agree that they should be done, and fails to provide even one example of what he's talking about.
That is a pretty bad assumption and very out of touch with actual development. If something really isn't worth it or would take too much time, I simply tell people that or completely ignore the suggestion if its too outrageous. However, that doesn't mean I want the users to shut up and just let daddy developer do whatever I want. I want feedback because I can't possible test everything, I can't predict all the trends for usage, and any half decent developer loves to see people using their software to accomplish things they never even envisioned when it was written (not hacking it per se, but finding use cases we hadn't thought of yet).
In fact, it is more ridiculous for the users to just immediately jump on and start bashing ideas when they have no idea how to actually engineer it or how much time it would take to implement that feature. If someone actually writes real software (not some garbage scipts they threw together either) and wants to comment concerns that is more in line, but even then, just because I write software doesn't mean I know how all software is designed... If a developer starts asking for opinions on it, different story, but people jumping all over it when THEY don't write code is much more ridiculous in my opinion.
Ideas don't cost me shit. Again, if I don't like doesn't mean I have to implement it (unless there is a contract, but that is a different ballgame then what were talking about). I'll take a glut of stupid suggestions with a few good ones over nothing at all any day.