Can't Fix? Won't Fix!

This morning I was writing to a customer to explain the "By Design" and "Won't Fix" resolutions we can apply to an issue, and I thought it would be beneficial to publish my reply to a wider audience.

When we design and implement a component, we start from a position of how we think it will be used and what its features should be to support that usage. If you like, we embed our own assumptions and biases into the component. Later on, when a customer uses the component in a different way and has problems, we're in a bind. Sometimes we're lucky: we can find a workaround that keeps the customer moving, or we can see a "simple" bug-fix that gets around the issue.

Sometimes we're not so lucky. We find that an assumption we made early on is wrong but unfortunately that assumption is baked into the design. This is a real hard one: we fully appreciate the problem and slap each other upside the head, but it's not going to be a simple bug-fix to make. We have to tear apart the component in some fashion, redesign some portion of it to avoid the problem, and somehow bring it all back together so that we preserve backwards compatibility. Good luck with that, someone's got to do it, when the going gets tough the tough get going, etc.

It's at this point where it seems we're punting the issue. We'll perhaps mark it as By Design, meaning that, yes, we see the problem, but we think the usage goes beyond what we think the component was designed for. In general, we'll also put it to one side and think about implementing a different component or a more flexible version of it in the future, where we can plan for informing customers that there will be breaking changes, for instance.

Perhaps we'll mark it as Won't Fix instead. This is a more contentious resolution, most obviously because of the phrase. (Images of the development team with folded arms, stamping their feet, screaming No Way!, come to mind.) There are two main reasons here, I suppose. The first is an extension of the By Design resolution: the component is so set in concrete that the only way to fix the issue is to redesign and rewrite the whole thing. In other words, we simply cannot fix the issue, we just have to throw the whole thing away and start over. The second is to simply say that to fix it would require us to develop some software that is not part of our main goals, in essence that goes beyond what we want to do as a company.

A couple of examples might make this clear. Our WinForms scheduler component has some issues when it comes to emulating the Office 2007 look-and-feel (which is why you haven't seen anything along those lines yet). We decided early on in the Office 2007 betas that the current design just wasn't flexible enough to emulate some of the new features of Outlook 2007. This is an obvious case of marking an issue as "By Design" or even "Won't Fix" and moving on, but we realized that such a decision doesn't match our company goals and so we're rewriting the component (there's another reason as well: we're redesigning it so that we can reuse code for a future ASP.NET scheduler). But, and this is going to be a big problem, it's likely that there will be breaking changes when the Scheduler Mark II becomes available.

Another: our eXpress Application Framework (XAF) enables you to write business applications very quickly. Our goals for this product are being met (it's still in beta), but we're getting some pushback with regard to the multi-tier aspects of the applications we create. We've shown how to use .NET Remoting and WCF (and I think even RemObjects' remoting product), but we've steadfastly refused to produce our own. Such a remoting product is just not aligned with our company goals (at least, not at the moment, but who knows?) and so it becomes a Won't Fix.

Now, having said all that, sometimes an issue will be marked as By Design or Won't Fix just because the developer is having a bad day and can't be bothered. We do try and avoid this situation because of course it's just not acceptable. So if you feel that the resolution you've received is just avoiding the issue, let me know and I'll dig into it. I don't guarantee I'll change the resolution, but at least I'll check.

Free DevExpress Products - Get Your Copy Today