Hardcoding is Job Security (For Everyone But You)
If I find a Cost Center ID written directly into your XSLT, we are going to have a problem.
We need to talk about Technical Malpractice.
It usually happens at 2:00 AM. A payroll integration fails. You open the error logs. You dig into the code that your expensive implementation partner wrote three years ago.
And there you find it. The smoking gun.
<xsl:if test="cc='100-2495'">They hardcoded a specific Cost Center ID directly into the logic.
Why did they do it? Because three years ago, that was the only Cost Center that needed the special tax rule. It was fast. It was easy. It worked for the deadline.
But today, you reorganized. That Cost Center doesn't exist anymore. And because that logic is buried in the code (not in a configurable table) the system didn't just break; it exploded.
In the Department of First Things First, we have a rule: Data drives Logic.
If you are writing specific IDs, names, or dates into your code, you aren't building a system. You are building a trap.
The "Consultant's Shortcut"
Hardcoding is the "Sugar" of the Workday ecosystem. It gives you a quick rush of energy (the integration works instantly!), but it leads to a massive crash later.
Consultants often love hardcoding because:
Speed: It saves them the 15 minutes of creating a Launch Parameter or an Integration Attribute.
Job Security: When business requirements change next year, you can't fix it. You have to call them back (at $250/hour) to open the code and change '100-2495' to '100-2496'.
That isn't a partnership. That is a subscription to mediocrity.
The Fix: Abstract Everything
If you are a Product Owner or Architect, I want you to open your studio integrations or your advanced calculations and look for "Magic Numbers" (specific IDs).
If you see them, rip them out.
The First Things First Standard:
Never put a specific value in the code.
Always put it in a Launch Parameter, an Integration Attribute, or a Lookup Table.
If the rule changes, a functional analyst should be able to update the table in 30 seconds. They should not need to deploy a new .clar file.
The Kitchen Table Reality
I caught Justin committing "Physical Hardcoding" this weekend.
He was building a massive LEGO fort. It was impressive. But then I noticed he had a bottle of my expensive, BSI Super Glue.
Me: "Justin, what is the glue for?"
Justin: "The tower kept falling over when Toby (the yellow dog) walked by. So I glued the bricks together. Now it's sturdy."
Me: "That is true. It is very sturdy. But what happens when you want to turn the fort into a spaceship next week?"
Justin: "I can't. It's a fort forever now."
Me: "Exactly. You have hardcoded the bricks, and you’ve glued your fingers. You have committed the ultimate sin of LEGO. Now luckily your dad has some super glue un-cure around here. Let’s get your fingers unstuck, but the solvent will melt your LEGOs."
He stared at the glued bricks, followed by his fingers. He realized the permanence of his decision.
Justin: "Can we buy new bricks?"
Me: "No. You must live in the fortress you glued."
The Takeaway
Hardcoding feels like stability in the short term. "It just works!"
But your business is not a glued-together fort. It is a living thing. It changes. It reorganizes. It acquires (and divests) companies.
If your code is glued together with hardcoded logic, you cannot pivot. You can only break.
Audit your code. Remove the glue. I know there’s some un-cure around here somewhere.
— Mike
Director HR Tech | Chief LEGO Architect
P.S. If you are a consultant and you hardcode a worker's name (e.g., Advisor = 'Steve') into a business process condition rule... I will find you. And I will make you fix it for free.