I found, that some very famous app (I'm not disclosing name intentionally) has a "problem", when writing meta-data of a file and the file turns out to be read-only. Program doesn't handle that too gracefully.

It does not check, whether a file is read only upon opening meta data dialog box. Thus, it allows the user to fill out (quite long) form, enter quite large amount of data without even checking if it will be able to save it. It only checks, if the file is read-only, when saving meta-data (attempting to do so). And if it finds that the file is actually read-only, it only displays a warning to a user and... closes the dialog box, thus causing user to lose data.

For me, this is an obvious bug, that it is beyond any discussion.

Since creator of that program, is my e-friend, I've immediately contacted him, writing (as usual) "Hey, just spotted another bug in your program". His reply simply shocked me, as he claimed and started to convince me, that this is not a bug, it can be only treated as an additional feature, that user may want (talking about my proposition to add some warning, that file is read-only and thus writing meta-data is impossible).

He even went as far (I think) as writing:

read-only file is a user problem, not a bug in a program

It was Saturday, a working and tiring day for me. I thought to myself, that maybe there isn't enough hot coffee in my blood system, so I contacted some of the developers, that I've been working with on a various projects. All the replies were the same: "A certain bug, nothing to discuss further".

I replied to that app's author and my friend, giving him a dumbest example I could come with:

Imagine yourself, that you are writing something in Word, save the document, Word tells you, that it can't write file, because it is read-only and... closes the document, losing everything you wrote since last save. Would you called that an extra feature and no data loss? (...)

And you call it a feature and my problem? I know many people ready to crucify you for such feature! :)

In the reply to that, I heard, that the comparison is not very good, because I don't write in meta-data so many text like in a Word document, so the "loss" is irrelevant. I'm completely lost, with both hands down!

As I said, for me this is a certain bug beyond any discussion. But maybe I slept over some radical revolution in the way, how we define a bug, so maybe someone would kindly enlighten me about that. Who of us two is right, and if it is program's author -- then why?

  • As Karl implied in his answer, don't call it a "bug", call it a "bad user experience" that the developer can improve on. – Bobson Dec 16 '13 at 17:08
  • 1
    @all: I thought my question would bring a little bit more interest. But a downvote is something, that actually surprised me. Would the downvoter take care to express, what he or she doesn't like in my question? – trejder Dec 16 '13 at 18:52

It depends on your point of view. Here are a couple articles that discuss the topic. Developers see bugs as a mistake they made when translating requirements into code. Users also see deficiencies in the requirements as bugs. Developers get defensive when you say they made a coding mistake when really the mistake was a missing requirement, even if they're the ones who should have noticed the missing requirement.

The real answer is it doesn't matter what you call it (aside from contractual obligations). The user's experience with the product is ultimately what matters.

  • Thank you for a short, but explain-everything answer. Person, I'm referring to, forces me to call it a "feature", not a "bug", because that takes the pain of fixing it out of his shoulders. Would this be, what you call "contractual obligations"? – trejder Dec 16 '13 at 18:51
  • 1
    @trejder - That would depend on what's specified in the contract. If the design document doesn't specify what is to happen when an error occurs while saving (or an error occurs in general), then it's neither a bug nor a contractual obligation. Possible alternatives are "poor design", "bad user experience", "feature request", "UI suggestion", "error recovery", and so on. – Bobson Dec 16 '13 at 18:55
  • @Bobson Sorry, but I think, I didn't underlined that enough. How we're going to name this particular case, will lead us to an answer, whether program's author should or shouldn't fix it? Calling it a "bug" would insist fixing it. Calling it "poor design", "bad user experience", "feature request", "UI suggestion", "error recovery" could be easily "shot back" by program's author, that he doesn't share this feeling and isn't going to fix this. This is the key in my question -- whether such thing should or shouldn't be fixed? – trejder Dec 16 '13 at 19:03
  • 3
    @trejder - Define "should". Should he under a contractual obligation? Only if the contract requires it to behave differently. Should he because it's wrong behavior? Only if it's actually wrong (in the definition of the one who gets to decide whether it's wrong or not). Should he because it causes a bad user experience? Only if he cares about user experience. And so on. The answers will vary depending on whether it's done on contract vs. paid software vs. a FOSS project, among other things. – Bobson Dec 16 '13 at 20:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.