Legacy systems are hard to change, and even harder to eliminate. You can’t simply do nothing though; as technology and user expectations change, you need to find ways to modernize and adapt the legacy system.
That’s what happened to Alicia‘s team. They had a gigantic, spaghetti-coded, monolithic application that was well past drinking age and had a front-end to match. Someone decided that they couldn’t touch the complex business logic, but what they could do was replace the frontend code by creating an adapter service; the front end would call into this adapter, and the adapter would execute the appropriate methods in the backend.
Some clever coder named this “Backend for Frontend” or “BFF”.
It was not anyone’s BFF. For starters, this system didn’t actually allow you to just connect a UI to the backend. No, that’d be too easy. This system was actually a UI generator.
The way this works is that you feed it a schema file, written in JSON. This file specifies what input elements you want, some hints for layout, what validation you want the UI to perform, and even what CSS classes you want. Then you compile this as part of a gigantic .NET application, and deploy it, and then you can see your new UI.
No one likes using it. No one is happy that it exists. Everyone wishes that they could just write frontends like normal people, and not use this awkward schema language.
All that is to say, when Alicia’s co-worker stood up shortly before lunch, said, “I’m taking off the rest of the day, BFF has broken me,” it wasn’t particularly shocking to hear- or even the first time that’d happened.
Alicia, not heeding the warning inherent in that statement, immediately tracked down that dev’s last work, and tried to understand what had been so painful.
"minValue": 1900,
"maxValue": 99,
This, of course, had to be a bug. Didn’t it? How could the maxValue be lower than the minValue?
Let’s look at the surrounding context.
{
"type": "eventValueBetweenValuesValidator",
"eventType": "CalendarYear",
"minValue": 1900,
"maxValue": 99,
"isCalendarBasedMaxValue": true,
"message": "CalendarYear must be between {% raw %}{{minValue}}{% endraw %} and {% raw %}{{maxValue}}{% endraw %}."
}
I think this should make it perfectly clear what’s happening. Oh, it doesn’t? Look at the isCalendarBasedMaxValue field. It’s true. There, that should explain everything. No, it doesn’t? You’re just more confused?
The isCalendarBasedMaxValue says that the maxValue field should not be treated as a literal value, but instead, is the number of years in the future relative to the current year which are considered valid. This schema definition says “accept all years between 1900 and 2124 (at the time of this writing).” Next year, that top value goes up to 2125. Then 2126. And so on.
As features go, it’s not a terrible feature. But the implementation of the feature is incredibly counter-intuitive. At the end of the day, this is just bad naming: (ab)using min/max to do something that isn’t really a min/max validation is the big issue here.
Alicia writes:
I couldn’t come up with something more counterintuitive if I tried.
Oh, don’t sell yourself short, Alicia. I’m sure you could write something far, far worse if you tried. The key thing here is that clearly, nobody tried– they just sorta let things happen and definitely didn’t think too hard about it.
Source: Read MoreÂ
