I had an interested conversation with a colleague recently, and the topic was hard-coding.  A definition from wikipedia follows:

Hard coding (also, hard-coding or hardcoding) refers to the software development practice of embedding input 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.

Hard-coding has caused quite a bit of pain for folks trying to maintain systems.  One of the issues is that changing the configuration information requires a code change, and then a redeployment of the system.  Another issue is if the configuration is hard-coded into multiple places within the system.  Then the programmer must remember all the places the hard-coding exists.  Compounded by a situation where the system is hard to deploy, this can lead to a large maintenance problem.

To get around hard-coding configuration information into the system, we often move configuration to an external source, which is a text file or database table.  This allows us to change the configuration without rebuilding the system.  The caveat is that it allows us to believe that we have removed the configuration from the system, but we must be wary of behavior that depends on specific configuration values to exists.  I’ve mentioned the location of configuration in an earlier blogpost, and I’ve also mentioned fear of deployments.

Oren Eini boldly makes the assertion that a system is simpler to maintain when configuration is hard-coded in one place within the system.  Coupled with an automated testing and deployment process, changing configuration can be just as simple and predictable as possible.  Oren asserts that hard-coding as much as possible enhances maintainability.  He then defends his position with an example in a subsequent post. 

I agree with Oren.  The first draft of some functionality should hard-code everything.  Then subsequent revisions will cause some information to be factored out into mediums that can be maintained while suppporting all the requirements in scope.  The requirement cause us to make decisions about what information to hard-code and which information to soft-code.

Hard-coding as harmful or not is not an absolute.  When you dig deep into the requirements for a system, you will uncover specific information that doesn’t work as a part of the codebase.  That information has to be elsewhere in a softer configuration medium.

Conclusion:  hard-code it until hard-coding it doesn’t work anymore.