I'm sure it has happened to all of us. You're using a new application, and you know what you want to do, but have trouble finding which button or window lets you do it. You probably start by going through the drop down menus one by one, scanning through the options for something that is remotely related to what you want to do. Bingo, you find what you're looking for but the button is greyed out. You're then left guessing what you need to do to get that button to allow itself to be clicked. Maybe you need to select this item first? Or maybe have this option enabled? Perhaps you need to open a different file?
Having the user go on a treasure hunt to unlock the functionality they want from the application wastes their time and is a bad design decision on the part of the developer. This is something that is all too common in applications today, and put simply is
BAD BAD BAD.
Developers take for granted that if they want to disable a feature in a program they simply grey it out. And while it is effective in communicating that the feature is unavailable, it does nothing to tell the user why it's unavailable. You might say, "Well maybe they should RTFM before they used my application!". And while that would be a fair argument 10-20 years ago, today it's not a valid excuse. Users today don't expect to read a manual before using an application, and rather expect the developer to do a good job designing the interface to make it intuitive and easy to use on the first go. When you buy an iPod, do you get a 100 page manual outlining how to use it? No, you get a tiny pamphlet that pretty much tells you to download iTunes, plug it into your computer and have at it. That's because Apple designed the interface to behave intuitively with the user's initial expectations of how the product should work, and considering their success they're on the right track.
So what better way is there to do this? Simple, rather than greying out the button, have it trigger a message box that communicates to the user that first of all, the feature they are trying to use is currently unavailable, and second, what is it they need to do in order to make it available. From a coders perspective this isn't really anymore work. For example, suppose you have a delete button in your application. Rather than disabling the control when there is nothing selected to delete, which in C# is as simple as
mycontrol.Enabled = False; replace that line with
MessageBox.Show("You must first select an item from the list to delete.");. That wasn't so hard now was it.
Of course, this doesn't mean that greying out buttons is the wrong thing to do in all cases. There are functions that are so basic that they don't require justification as to why they are disabled. For example, greying out the save button if there are no changes to save is prefectly acceptable. Also, greying out the paste button because there's nothing in the clipboard to paste is also correct. These functions are universal to most applications and most users are expected to understand what they do.
Making the decision as to whether or not you should communicate with the user why something is disabled comes down to what you expect your users to know and find intuitive. In a professionally designed interface one of the first steps that are taken in the design process is evaluating the audience for your application. If you're designing an automated checkout system for WalMart, you would assume that some of your users may have never even touched a computer before, and therefore have the application hold their hand and guide them through the entire checkout process. On the other hand if you're building a tool meant to be used by other developers you would expect them to already understand a lot about how the application works, and would only make the user feel stupid by pointing out something that is already obvious to them.
The bottom line is, before you write the code to disable a button, ask yourself, "Will it be painfully obvious to the user why this button is disabled?". Of course it's obvious to you because you're the one designing the application, the challenge is to put yourself in someone elses shoes, and assume the things they expect from your application in order to answer this question correctly. Once you have the answer you will know whether to simply grey it out, or leave it enabled and communicate to the user why the action cannot be executed.