Hardcoding Considered Harmful - or is it?

  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. 


Hardcoding + procedural code = bad news » JT on EDM Posted on 1.13.2009 at 6:51 PM

Pingback from Hardcoding + procedural code = bad news » JT on EDM

Reflective Perspective - Chris Alcock » The Morning Brew #264 Posted on 1.14.2009 at 2:37 AM

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #264

Link Listing - January 13, 2009 Posted on 1.14.2009 at 8:00 AM

Link Listing - January 13, 2009

Link Listing - January 13, 2009 Posted on 1.14.2009 at 8:01 AM

ASP.NET Building Data Centric Web Applications using ASP.NET Dynamic Data [Via: Rachel Appel ] Resizing...

Dew Drop - January 14, 2009 | Alvin Ashcraft's Morning Dew Posted on 1.14.2009 at 1:35 PM

Pingback from Dew Drop - January 14, 2009 | Alvin Ashcraft's Morning Dew

Friday Links #34 | Blue Onion Software * Posted on 1.16.2009 at 4:04 PM

Pingback from Friday Links #34 | Blue Onion Software *

Weekly #0 (beta) | loosely coupled Posted on 1.22.2009 at 1:34 PM

Pingback from Weekly #0 (beta) | loosely coupled


Wardell said on 1.13.2009 at 4:30 PM

Good post! I agree with your conclusion, you have to do whats best for the given situation, improper use of hard-coding can cause future headaches, but so can over use of scripting, by over complicating apps and taxing server resources.

Damir Zekić said on 1.13.2009 at 4:41 PM

This post reminded me of "Soft Coding" by Alex of The Daily WTF: thedailywtf.com/.../Soft_Coding.asp

I, too, believe that the applicatoion logic should remain in the source code. Going down the path of soft coding will only make us work more trying to reach a goal, that cannot be accomplished: write a tool which will allow non-programmers to change the application (so we won't have to). Programmers should be the ones who alter the application and its logic. I don't see anything wrong with that.

James Taylor said on 1.13.2009 at 6:53 PM

the problem is not hard coding but what you hard code in! jtonedm.com/.../hardcoding-proc

Damien Guard said on 1.13.2009 at 10:43 PM

Turning a const into a configuration file read can be a bit of a pain during development and once again follows the YAGNI principle to remain where it is until you have useful scenarios.

You'll also be in a better position to decide where it should live and in what context to the other configuration information.


Jeffrey Palermo said on 1.14.2009 at 1:48 PM


I left a comment on your post as well. As with any principle, it takes a skilled person to apply it appropriately.

DarrenWang said on 1.15.2009 at 12:43 AM

hard coding is good or evil , it depends on where, when , how u use it, I think

John Rockefeller said on 1.15.2009 at 8:59 AM

I typically like using a config file, usually an include at the top of my php script that has all of the settings inside. Then there's only one place to change it.

This idea that you can see things like this in the code is dumb:

if ($pageID = 1000) {


} elseif ($pageID == 1001) {


} else {



What's the significance of 1000, 1001? Are you going to leave a comment? Typically I find in these cases there are no comments left behind because the person coded the project with the idea that he/she would be the only one looking at it and they would always remember what each one meant.

What a disaster. Such an example would be much better served by a constant, set up in a config file, included at the start.

Jeffrey Palermo said on 1.15.2009 at 9:17 AM


your specific example makes sense. I would not want to hard-code something of that nature. A skilled person has to make determinations like this daily.

Inder P Singh said on 1.17.2009 at 11:43 PM

In my opinion, a skilled programmer should strike a balance between soft coding and hard coding. Soft coding to the extreme tends to make the source code overly complex and difficult to maintain. I agree with @John. Wherever hard-coded data is present, there should be a brief comment to explain the significance/ source of the data. This would ensure that such data could be moved to a softer medium later, if appropriate.

Craig Bowes said on 1.20.2009 at 9:31 AM

I like this post and your previous one about separating data from configuration. When I took your Agile class, there was several places where I was surprised you hardcoded a collection workflow objects instead of driving it from the database or a configuration file, but in retrospect it makes sense now. Since its a behavioral part of the system, you don't have to rely on certain data being in web.config or a table. Plus each item is strongly typed and unit testable.

I still use configuration files for certain things. URLs, mail servers, web services, email addresses, connection strings obviously, file system paths and anything that might change from one server to another or when moving from dev, test, qa and production. I try to limit these to values and not behavior. I've noticed a lot of third party tools such as Url Rewriting actually have you define rules in the web.config and this can be a pain since its not strongly typed, programmatically changed or easily unit tested.