The Insurance industry is filled with nuances, edge cases, and weirdnesses. When our customers ask us to describe one of those edge cases, we often do “one off” customizations.

Most of those customizations are handled in the flowcharts of our Interactive conversations by Production Specialists, who use our proprietary authoring tools to build these conversations. While members of the Production team are not engineers themselves, they are wizards at understanding logic, and some even have light backgrounds in programming. On occasion, these customizations cannot be handled “out of the box” with our authoring tools, and require specific engineering in little pockets of code we lovingly refer to as “code cells”. When working with those customizations, we want it to work for one specific customer, not everyone.

A member of our production team recently had a question about how to implement this:

Production Specialist:

Many times, these customizations only apply to certain users who are eligible for a certain plan. So let’s say this user needs to be looking at “The Best Medical Plan Ever Made” in order to see this customization. However, there are multiple plans (ID: 123, ID: 456, and ID: 789) that can see this customization, and all of them share that name.

if (medicalPlans.plan.id === 123 || medicalPlans.plan.id === 456 || medicalPlans.plan.id === 789) {
   // DO THE CUSTOMIZATION
}

However, there’s a second approach we could use, which is a little more readable and saves a little code:

if (medicalPlans.plan.name === "The Best Medical Plan Ever Made") {
   // DO THE CUSTOMIZATION
}

So, the question: Which approach is generally more advisable when coding?:

To refer to an immutable ID of an object that would change year to year?
Or to refer to a mutable name of an object that would carry over year to year?

Engineer: 

Identifiers uniquely identify things.

There are all kinds of ways of implementing that unique part, but the end result is that you cannot have two things with the same identifier.
That word, “unique”, is the key here.

Consider fields like “names”, which are not identifiers and also not unique.
There’s nothing behind the scenes enforcing that their value doesn’t get duplicated.
Bob Smith could name his child “Patrick” and Alice Smith could name her child “Patrick”.
Both children’s names would be “Patrick Smith”, but their SSNs would be unique. Their SSN is an identifier, their name is not unique.

Similarly within the ALEX world, anybody could name their plan “The Best Medical Plan Ever Made”, and then anybody could have that customization fire.

Production Specialist:

Awesome. I had a fairly significant opposition to the latter approach — it’s a mutable name, and if it gets changed, the customization breaks. Unfortunately, a lot of my peers still want to use the name, because it’s easier to read and carries over year to year.
How do we kill this mindset that using a mutable name is easier? I can’t spin a compelling reason even if my heart knows it’s wrong.

Engineer:

Try giving them a counter example…say the customer wants to change the name from “The Best Medical Plan Ever Made” to “The Best Ever Medical Plan”.

If we write the customization using the name, changing it would break the customization. We’d have to go back and modify the customization. Stuff would be temporarily broken.

If we identify it by id, we don’t have that risk.




Tagged with: