The site formerly known as The Daily WTF has an article entitled Soft Coding which contains the following excerpt

Most programmers consider “Hard Coding” to be a Bad Thing: it’s hack-like, inelegant, and all-around lazy code. And as such, many programmers try their damnedest to avoid it. Unfortunately, this quest of avoidance often leads towards a much worse path: complication, convolution, and all-around unmaintainable code. It’s a path I like to call Soft Coding.

Before I discuss the finer details of Soft Coding, I’d like to briefly define Hard Coding. It’s the practice of embedding “things that shouldn’t be in source code” directly inside of source code. The definition is intentionally vague: while most would agree that database connection strings and logfile directories don’t belong in source code, there’s a lot of gray area. Take, for example, this following code:  

private void attachSupplementalDocuments()
{
  if (stateCode == "AZ" || stateCode == "TX") {
    //SR008-04X/I are always required in these states
    attachDocument("SR008-04X");
    attachDocument("SR008-04XI");
  }

  if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

  if (coInsuredCount >= 5  && orgStatusCode != "CORP") {
    //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
    attachDocument("AUTHCNS-1A");
  }
}

I can already feel some of you cringing: Magic Numbers; String Literals; eww, that’s a lot of Hard Coding! However, not a single character in that example is Hard Coded: there is nothing that “shouldn’t be in source code” in the above code. The function simply implements a very clear and very specific business requirement with very clear and very specific code. Anything less and it would be Soft Coded.

I think it is a laudable goal for The Daily WTF to branch out into describing best practices instead of simply gloating at bad code. I assume this is motivated by some of the comments by Jeff Atwood in his post What's Wrong With The Daily WTF. However the problem I have with this article is that it conflates the difference between hard coding and using magic number (or magic strings).  

From the Wikipedia definition of hard coding:

To hard code or hard coding (also, hard-code/hard-coding, hardcode/hardcoding) refers to the software development practice of embedding output or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.
...
EXAMPLE: Fixed installation path
If a Windows program is programmed to assume it is always installed to C:\Program Files\Appname and someone tries to install it to a different drive for space or organization reasons, it may fail to install or run after installation.

EXAMPLE: Startup disk
Some "copy-protected" programs look for a particular file on a floppy disk on startup to verify that they are not pirated. If the computer is updated to a newer machine, which doesn't have a floppy drive, the program now can't be run, since the floppy disk can't be inserted.

From the Wikipedia definition of magic numbers:

The term magic number also refers to the bad programming practice of using numbers directly in source code without explanation. In most cases this makes programs harder to read, understand, and maintain. Although most guides make an exception for the numbers zero and one, it is a good idea to define all other numbers in code as named constants.

This is preferable for several reasons:

• It is easier to read and understand.
• It is easier to alter the value of the number, as it is not redundantly duplicated. Changing the value of a magic number is error-prone, because the same value is often used several times in different places within a program
• It facilitates parameterization.

Hard coding is bad because it assumes that information which should be flexible is actually fixed and unchanging. On the other hand, using magic numbers is a code maintenance problem which does not necessarily mean that the program is inflexible.