I just had an interesting [to me] interaction on Twitter that got me thinking:

Ignoring the original issue - that iTunes cover flow doesn’t handle similarly named albums properly - the “workaround… fix… same same” thing got me.

To a person who doesn’t develop software, I bet a workaround and a fix are the same thing. To people who develop software, they’re very different, and the distinction is important.

What’s the difference?

A workaround means a problem has been identified, there’s no official solution for it, but if you do some sort of temporary change on your end you can get things to function within reason. It may not be 100% correct behavior, but it’ll get you past the problem - in a way, you need to change your expectations to accept a workaround as a solution. In this case, the workaround would be for me to modify the metadata on all of my music to “fool” iTunes into behaving correctly. The important bit here is that the change is applied to how you use the product, not the product proper. The problem in the product still exists and the use of a workaround is expected to be temporary.

A fix means the problem has been officially solved so, once applied, the expected behavior will be the actual behavior. In this case, if the issue was fixed then I wouldn’t have to change the metadata on any of my songs - the iTunes cover flow would work properly. The important bit here is that the change is applied to the product proper. The problem in the product no longer exists because it’s actually been fixed.

This doesn’t sound like it’s a big deal, but from a language precision standpoint (particularly for a software developer), it’s huge. If someone files a defect on one of my products and I provide a workaround, I’m still expected to fix it.

(Note that this is no reflection on Alex, who’s a smart guy and friend of mine. It just got me thinking, is all.)