As for putting the full solution as a low priority bug, to be honest I like to close off bugs if I can. We’re still a small company with lots of growth, and especially lots of growth in terms of application features. We already have more than 5 years of features development planned assuming our current resources, and several more in the pipeline that we know we can’t get to until then.

Not to mention the fact that we receive a lot of feedback from our current customers, and prospects, asking us for other new features! We generally try to implement to most requested features first, and the list is very large. There’s never a quiet moment here, and that’s what I like about smaller companies

You are also forgetting that not fixing the issue does not have $0 cost. You are paying tech support people to answer this question every time it comes up. You need to either spend time training them on this issue, document it and train support how to find it, or ignore it and pay for them to learn on their own when they hit it. You have the cost of management spending time evaluating options, discussing, and deciding not to fix this – usually this involves several people who make more than developers. You have programmer time spent everytime a bug report is filed doing research to decide if it is the CMYK issue or not (can be significant if there is a bug with similar symptoms or in the same area).

And then you have the full $1000 cost of developer time if you ever change your mind and decide to fix it later.

Better to just spend 1 day developer time, especially if you have the developers, and they aren’t working on anything higher priority. Otherwise, just queue in your bug tracker as a low priority item, and let it work its way through the process.

Your comment is VERY interesting for me. You pointed exactly the situation in which I think it’s appropriate. And not only that, knowing the effort, you mention that it’s not worth it in my situation. That’s very interesting coming from someone who’s gone through the effort!!! Thank you for your comment.

Btw, do you mind if I ask how much total effort it took you to implement that functionality? Where my estimates in-line with what reality, assuming of no initial knowledge of how JPEG’s are encoded?

If I were in Steph position, I’d hate to spend my money in applying the “right” fix on to something that is affecting a small user base and adds little value to my software. I agree with Steph in this case.

That’s very close to what we’ll do. But documenting it alone isn’t enough for a shrink wrap public application. Imagine if Microsoft Word just documented such bugs? You also need to provide the user with feedback, show where the error occurs, provide them with a way to solve it, make it very friendly, and so on…

Yes, you’re right that only using this logic can make many bugs uneconomical. However once you start to factor in other costs such as design debt, this quickly changes the equation.

The main difference with this bug was that the solution appeared to be VERY xpensive (just look at the size of Mozilla’s implementation and they didn’t even fully solve it. I’m sure there’s a lot of hours involved in this solution alone with a lot of different experts (open source).

Now considering the massive expense for the small payoff, it doesn’t make much sense… Normally bugs aren’t nearly that expensive to fix, and those that are, are generally due to other underlying issues that need to be resolved anyways.

You know what, you’re absolutely right!!! I did * 0.05 where I should have done 0.0005 (just out of habit). You actually brought the point home even more! Now the bug fix is costing twice the price of the software. If you look at total lifetime of customer, assuming upgrades are discounted 50%, then you need the customer to stay with you at least 3 years to break even. And that doesn’t include the cost of acquiring the customer (marketing), or supporting them (technical support, etc.). And this is just for one bug fix. If all bug fixes were like this, you could easily bankrupt a company.