Since I took over our Epicor system here, I’ve been on a quest to remove all hard coded values from all of our custom stuff. Like…what were the previous devs/admins of the system thinking??? Exactly the same scenario. Hard coded customer ID’s, sites/warehouse codes, part numbers. It goes on and on. I work to enhance the apps to add that general functionality to be controlled by the users, therefore they dont have to come to IT with “I need customer x to have this same function/logic as customer Y”. I develop the solution from the ground up and give the user’s the framework to make changes they need on their own.
3 Likes
Present Jose concurs with future Josh 
6 Likes
words
totally agree with @timshuwy, i respect other people’s opinions, but do not agree with what they stated of excuses for using hard coding, also do not agree that the time difference is massive, it is obviously longer but robust and will save time in the future for the designer himself and others as well.
3 Likes
One man band but I want my end users to maintain stuff not least as I expect to move on and not be replaced. Agree with Tim, add UD fields or use the many data analysis grouping fields so that users can maintain themselves.
1 Like
I feel it’s a pretty fair excuse. Interest of time is significant and you have to take into account the time spent on a minor change vs something that provides PI/CI. Again, optimally everything would be dynamic, but if I’m making a rule for a customer that is outside our market space and we likely won’t have more of them I’m not wasting the time, until 1. it’s necessary and 2. we have worked with them more so when I do customize it we don’t have to throw half of it away later. I’m of the belief users only think they know what they want, you can only ask so many questions to get them where you think they need to be and the first cut will still be 50% off the mark.
We live in an imperfect world and if you can tell me you have everything coded 100% configurable with nothing at all hard coded in I would be quite surprised.
Tim’s example would literally be the difference between 15 minutes and 4-5 hours (including damage control). By the time you do process discovery(vs a quick band-aid), add the UD fields and regen (maybe regen again becuase the first time decided it didn’t want to work), document the fields for CAB, fight with the two customizations because #anchors, deploy the customizations to production, listen to everyone bitch because their personalizations broke, train them on what they need to maintain that they will never remember (which is fine because it may never be used again) you will have blown 20x the time that could have been spent streamlining a production process.
My work queue P1. Every minute counts and if it’s a minor NVA rule i’m not going to give it the time of day over PI/CI.
Hi @jgiese.wci,
i am not going to argue with you mate, you have much greater experience than me, i am only saying my opinion, in my 8 years experience in designing ERP solutions, always had to go back and update/improve/ or upgrade my design to do more stuff or to cover uprising changes, and always found that configured design is the best solution even for small project, i only use hard code if there is an emergency catch up as temporary solution until i finalize my solution, then i go back and replace it.
Not really looking for a fight lol, I’m just trying to make sure, as much as the golden goose of perfection sounds nice, people think about the needs of their company and what will get them the best bang for their buck. I will do things to my detriment and for sure not to the standard I would like them to be just to ensure what I’m working on has the ROI for my company that is required to keep us moving upward and onward. Sometimes we nerds can get so buried in the solution at hand we will forget about the literal bottom line. Just a balance is all I’m trying to convey.
3 Likes
me neither, i agree 
I agree with Josh(and also Tim, of course) as programmers/managers/etc. we should try to overthink about what the user is trying to obtain. Users are quite miopic when expressing their needs and even that particular mental process to attain that info. I have some users that ask pretty specifc things and I end drilling them with questions to see if the process is a one time thing or if it looks it will be something that will spread for more cases.
That being said, the fact is that sometimes I have prepared “nice” configurable solutions for problems that end changing their parameters and render the solution useless. That is a risk also and we could argue that then I didn’t do a good job at obtaining the actual requirement and developing the solution, but I am pretty sure that we all have been there.
Sometimes(depending) it is better to deliver a first entry development so the users end up defining the final and “real” permanent solution.
3 Likes
Sometimes, done is better than perfect. As so eloquently put in Agile terms.
2 Likes
Sounds like you need to farm some of this work out to that REST pro contact.
I used to be horrible about documentation, hard coding etc… it always haunted me down the road. If anything, i have learned so much over the last two years since i started Agile Scrum project management, not only from iterative development, but gathering requirements that can be somewhat nebulous from USERS (four letter word), architecture a bit upfront pays dividends for everyone, users, other developers (future self) and lends credence to IQ/OQ/PQ which is all about delivering something that works and is scaleable as business needs always evolve and sooner or later someone will be revisiting that work down the road. All good thoughts here…
1 Like
THIS
1 Like
Reminds the to ask Epicor to remove the 36 Check Limit Hardcoded and 10000 rows per Multi-Company Run Hardcoded. 
When you load in 3million parts, you can wait a few days for all the MC stuff to propogate properly from Master Company.
When you hardcode Volume:
1 Like
Hey… hardcoding of things like, “MFGSYS” Site id, and other features when you create a company are my favorite complaints… you can’t have that as a Rant either… it is my rant… hahahhaah
(Glad everyone is feeling better now that they have ranted a bit).
1 Like
Oh, that’s right. This was Tim’s rant about hardcoding values…
Yeah, it doesn’t take much time to code a User-Code entry lookup for many hard-coded situations. 
1 Like
