It would seem this should be obvious, anymore. I pick up a decent number of billable hours due to values being hard-coded in applications. Now, I actually mean two different things here.
Using Constants for Values that Should be Generated
Some values simply should be generated by the application dynamically, rather than hard-coded as constants. As an example, I just fixed a web application which had some off-the-shelf event calendar. The data entry form for this app had the year drop-down list hard-coded to include the years 2004-2010. So, a couple weeks ago, they got a bit flummoxed. And I got a half-hour of billable work fixing it.
This one should be obvious; Those years should have been generated by the server-side code. Or at very least, just use a text box with the current year entered by default. It seems that someone in 2004 could not see beyond the year 2010. Wow.
Coding Values that Should be in Configuration/Resources
Sometimes you can't generate the values at all. For example, database connection strings, custom application messages, and the like.
Very often, I suppose people just think, "Oh, this information probably won't ever change." In a post-Y2K-bug world, that sort of short-sightedness seems just plain silly. What happens when your employer gets a fresh, brand-new database server many years down the road? If you have put your connection string in a standard configuration location, it'll be easy to update the application to use the new database.
But if not; Well, people like me will get more work. And people will wonder what else you didn't do correctly...
Whenever Possible: Generate or Configure!
In conclusion, I make a plea to developers out there: Please use code to generate values whenever possible. If not, make sure that anything which could change (and take a long-view!) can be altered in the application without the need for rebuilding.