AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
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
Drag