Programming Horror

A story from my day job. I submitted it to the Daily WTF. Fingers crossed that they'll accept it.

In order to facilitate development of frontend apps that rely on my employer's antediluvian monolith codebase, a team of developers at the company came up with a backend for frontend (BFF) service that would allow developers on other teams (such as mine) to quickly make frontends that use the monolith's logic and data. The service uses a schema-driven UI approach, where developers make forms by specifying the input elements (along with some related layout and validation logic, also schema-driven) using JSON schemas. This also includes specifying classes on the element for styling purposes. Who wants hot reloading when tweaking styles for a frontend app when you can instead make a JSON schema in a separate DotNET codebase that needs to be compiled (this is sarcasm)? As gross as that aspect is though, it is not today's WTF.

Right after lunchtime today, I saw a post from one of my colleagues in the team's Teams channel saying (verbatim) "I am gonna take off this afternoon. The BFF has fried my brain and I need to unwind a bit." Curious to see what he was talking about, I went to the company's BitBucket to review the PR he just made. While looking through the schema he made, I saw a strange validator he had to use:

{
    "type": "eventValueBetweenValuesValidator",
    "eventType": "CalendarYear",
    "minValue": 1900,
    "maxValue": 99,
    "isCalendarBasedMaxValue": true,
    "message": "CalendarYear must be between {% raw %}{{minValue}}{% endraw %} and {% raw %}{{maxValue}}{% endraw %}."
}

When I was reviewing the PR, I thought this was a bug. The max value is obviously lower than the min value. A closer look at the schema seems to support this idea:

• The value for the type field implies that the value for the input must be between 2 different values, presumably minValue and maxValue

• The eventType field value, "CalendarYear", implies that the accepted value must be, well, a calendar year

• isCalendarBasedMaxValue being set to true suggests that maxValue should be a calendar based value (and none of our customers were born nigh 2 millennia ago)

• The message would produce the patently absurd "CalendarYear must be between 1900 and 99."

Considering all of this, surely setting maxValue to 99 must be a bug in the validation logic. It certainly is for the logic that produces the error message. However, upon asking my teammate who paired with the dev that opened the PR, I learned that the max value is actually the number of years in the future relative to the current year. What the schema is actually saying is that valid values for the year selected must be between 1900 and 2124 (99 years after the time of this writing).

This is its correct usage. This is not a bug. It was designed to be this way. It was at that moment that my mind also melted.

I couldn't come up with something more counterintuitive if I tried.