Thursday, February 6, 2014

The dangers of hard coding

We have all been there.  Something gets hard coded when it does not need to be, or when it does not make a whole lot of sense, and it makes your life a lot more difficult than it should be.  Today was one of those times for us!

We had a responsibility created to serve business needs, but they later wanted to segregate duties and when they did we found out that the upload report designed had the responsibility_id hard coded into the report which made it impossible to run out of another responsibility.  Great idea, bad execution because we were not given a way to make it dynamic with profile options or some such plan.

So the business decided to go forward with the new segregation of duties responsibility anyways, but let an administrative account have both responsibilities which was tightly controlled.  No problem right?  Until a new manager came along, did an audit of the responsibilities, and removed the responsibility that was needed to run the upload report from the segregated duties responsibility.  Oops.

The lesson here is that if you need to hard code something, do it in such a way that it is soft coded.  Make updates possible so down the road when a parameter, e-mail address, or responsibility_id in our case have to change the people that follow you can do it without having to take your name in vain while they re-code your work.  Even better?  Allow a framework so changes can be centralized and manipulated easily without messy table level updates!

No comments:

Post a Comment