Back To Blogs
Josh Simmons 16th Feb 2018

The importance of avoiding hardcoding

As everyone knows, it is important to take the necessary time to plan out various parts of a project before any development commences. This will usually involve making estimations for how long each section will take to be developed.

One aspect which will greatly affect the time for estimations, and therefore needs to be properly considered, is how dynamic you intend the process to be regarding how it gets certain data. The reason this can greatly affect the time is that you have to make decisions on how value data will be used by the process and whether the necessary data will be “hard coded” into the project, meaning that values are directly entered into the code, or if you will have a “soft coded” solution which retrieves the values from an external source.

Hard coded solutions to these aspects usually will be done more quickly, but mean that it will require more work in the future to change if it is required, as the development team will need to be tasked to make the change and the process will go through a full release cycle again. Soft coded solutions generally will take longer because more parts of the system will need to be designed and built to accommodate the data that is needed by the process, but it does allow for certain updates in the future to be performed quicker.

For example, you are working on a project which requires you to develop a new expense claim process for the business employees to use. The business has a policy which determines that if a claim total is over a certain amount, it will first need to go to the finance team for approval before going to the employee’s manager. You would need to plan how you will design the process to accommodate this business rule.

You could hard code the process to use the amount stated in the current policy to determine where the claim goes. This would be a quick approach for the initial release. However, if the policy ever gets updated and the amount required for the finance team’s approval changes, then the process will need to go through another development cycle to get this new value added, tested and deployed with the process. If the rule gets changed multiple times throughout the year, it would mean more and more resources are being used on such a small change.

You could also take a soft code approach to this where you store the amount in an external area, like a database table, and have the process retrieve this data and then determine where the claim goes. This will take longer initially as the external table will also need to be created, populated and tested. With the data coming from an external source you could also create a separate management form to allow the appropriate business users to change the amount themselves. While this all takes a lot more time at the start, and increases the estimation times, it means that if the amount gets changed multiple times in a year, the time taken to make each change is greatly reduced.

As you can see, during the project planning it is important to take potential future changes into consideration. When you provide the estimates you may need to justify why certain things take as long as they do; knowing and being able to justify the need for longer time to proceed with the soft code approaches will help you demonstrate to the business how the overall process will be more adaptable to the needs of the business in the future.

Related Blogs

Moving from bad habits in Excel to best practice in low-code

I like Excel…I mean I’m one of those weird people who really likes Excel. I have used it to do everything from building Tetris to creating tools which support business critical processes in FTSE100 companies…

Find Out More

Setup of configuration data for Mendix apps

When you get to work on your first Mendix project, an important part to consider is how you move applications between environments for the first time and the initial setup that may need to be done to configuration data. This will not have necessarily been relevant to any local applications you may have developed due to you naturally setting up the config data as you were developing it.

Find Out More

Extending the functionality of Mendix applications with USB-powered hardware

Users typically interact with a Mendix application using either a mouse & keyboard or through a mobile device such as a mobile phone or tablet. However, there are many ways in which these interactions can be extended.

Find Out More

Optimising Mendix objects to avoid unnecessary application downtime

I have been supporting Mendix applications for more than two years and application downtime caused by mismanaged Mendix objects, is one of the biggest problems we face when ensuring Mendix applications continue to run in an efficient and stable manner.

Find Out More

Designing a good, reusable API

An application programming interface, or API, is described as “A set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other service.” Essentially any code you write which could be used or called from somewhere else is an API - If you program, then you are an API designer.

Find Out More