Perspective Unspoken

My perspective on Git, Docker, Python, Django, PHP and other stuff

How to know when to hard code

Hard coding has always been a bit of a bad word for me. Hard coding for the uninitiated means….

“Coding in such a way that you have to edit the code to get different behaviour”

I’ve always loved dynamic solutions. Hard coding almost always feels like it’s the wrong answer… I can always hear that voice telling me I’m going to regret it later. Was always difficult to do it without calling myself lazy, inept or dirty. Truth is though, hard coding can really save serious time. When you hard code you often don’t have to worry about persisting changes, which may very well mean not worrying about database migrations, functions to store and retrieve, access control, and the list goes on and on.

However… I’ve come across some situations where I’ve had to resort to. It took some time to grow on me, but I’ve come to admit that there are times “hard coding” is quite called for. Here are my top 5 questions I consider before deciding whether to hard code something or not.


How likely is change?

Firstly, think about how likely the need for change is. If the requirement isn’t going to change anytime soon in the future, then it’s probably not a bad idea. Think about the dependencies and their capacities to change. How far back in history would your code work? Is it related to some standard, constant or maybe a process in a company that’s deeply ingrained? If you can find deeply rooted dependencies or align your code with something else that doesn’t change much… you’re probably fine.


Does the scope of the project allow for a dynamic solution?

The project scope is a very important consideration. Especially when you didn’t see the cross roads coming into the project. That has happened to me several times. I had no idea I’d have to make a choice between hard coding and implementing some dynamic solution until I started working on that piece of functionality.

Nobody likes delays, but customers love exceptional quality. It’s important to find the balance. Ensure that the dynamic alternative is properly considered and scoped. Then, ensure that the solution can be implemented within scope and agreed deadlines. If not, the proper way to go about it is to have a discussion with the project manager and eventually your client. If the project scope doesn’t allow for it and there’s no mutual agreement to accommodate the development of a dynamic solution.. bite the bullet and move on.


What’s the descent rate into the rabbit hole?

Well… if you decide to hard code, does that put you in a corner? How much of the system is likely to be built on that piece of code that’s hard and fast? How much of your code will be shaped and fashioned by that decision to hard code a function or part of a module?

If you find that a lot of code that follows has to work on the assumption that your hard coding brought about in the first place, then stop.  Especially if it keeps happening. You’re going to regret it quickly when you realize you need to make a change but you have all these dependencies now.


How hard will it be to undo?

Following from the last question, you’re generally OK if there’s a way to do the implementation where there aren’t too many dependencies and it’s easy to undo or change direction. Think about how other modules will use the code that’s hard and fast. Think far and wide… ensure that whatever you’re hard coding won’t be too hard to undo.


What’s the impact of the dynamic alternative?

Carefully consider the real value of the alternative. Be careful not to confuse this question with “how novel is the alternative?”. It’s not the same thing. How much benefit is gained from coding something dynamic instead? Is there tangible gain to the end user? Are there considerable benefits to the system architecture?

Don’t make the mistake on focusing on the design of the dynamic solution. It will wow you. You will be flattered. But is it necessary? Is it a nice to have or a must have? How critical is it? How does the system benefit if you do it? How about if you don’t?

The ideal is to find a solution that has a large impact and doesn’t take eons to code, but that’s rarely the case. Anyway.. that’s why I left this question for last.


Deciding whether to hard code or not is largely a case by case scenario. However, it’s a choice that you may live to regret if it’s not carefully considered.

Share your thoughts!

jaywhy13 • May 16, 2016

Previous Post

Next Post