A rose, by any other name, might be a cactus.
If you come from a development background, you know that there’s an incredible amount of discussion about the importance of naming variables. Seriously, Googling “the importance of naming variables” results in 8.1 million hits, while the same phrase with regard to pets nets a paltry 6.7 million.
Clearly, a whole lot of people care a whole awful lot about what they name their variables and methods – so let’s take a moment to think about how we can make Rule Applications more maintainable by taking a bit more care with names.
What’s in a name, anyway?
As discussed in a previous post, a well-structured application will generally have logic encapsulated into helper Explicit RuleSets within their appropriate Entities to make troubleshooting and maintenance on the Rule App easier.
Having all the heavy-lifting logic hidden away is great and all – but what good is that if you can’t figure out what’s hiding where? For that reason, having a standardized naming pattern is another critical factor to having maintainable Rule Apps. The specifics around what that means will vary from organization to organization, but here are some ideas to start with.
- RuleSets that coordinate the execution of child rule sets should have the suffix “Controller” (IE ApplicationValidationController)
- RuleSets that enact logic should start with a verb (IE ValidateAddress, DetermineElligibility, CalculateInterestRate)
- Names should uniquely identify exactly what’s being done with no additional context (IE rather than CalculateInterestRate, CalculateMortgageMonthlyPaymentInterestRate)
- Long names can be made easier to read with underscores (IE Calculate_Mortgage_MonthlyPayment_InterestRate)
- If there is an accepted abbreviation, use it (IE Calc_Morg_MPmt_IR)
Seeing Calc_Morg_MPmt_IR in a rule app would make it pretty obvious what was going on, right?
Giant, flashing, all-capital, bright red BUT.
Let’s say your workforce is intimately familiar with the bewildering “naming convention” created many moons ago when the mainframe system you’re migrating from was created. Sure, “bp_38.012v” tells the average layperson absolutely nothing of value, but to everyone working on the system, it CLEARLY is the policyholder beneficiary declaration validation flow for accounts in Wyoming. From the perspective of someone moving in to update the system, every muscle will twitch and brain cell will scream to change it to something that makes logical sense.
BUT.
If everyone in the company knows what “bp_38.012v” is, why rename it to “Validate_PolicyHolder_BeneficiaryDeclaration_WY”? Sure – it’s absolutely accurate and precise, and makes the system completely usable by anyone outside the system – but those aren’t the people who will be building the Rule App and maintaining it on a daily basis. For those key stakeholders, having to read 47 characters is worse than having to read 10, for very good reasons.
One way to approach the situation would be to see if there’s an in-between state that will work for everyone, or perhaps a longer-term path forward to slowly adopt changes as new items are introduced rather than changing everything all at once. On the opposite side of the spectrum, if you’re able to get buy-in, rip the band aid off and introduce everyone to the new naming scheme – while being sure to explain WHY the change is being made, and how that will make their jobs easier. Neither of those acceptable? Sometimes, the right answer is to stick with what people know.
Striking the balance between “good practice” and legacy usability is an important concept to put some thought into – the short-term adoption and long-term maintained of the system depend on it.
