Where to Change | Victor Bodell

I had an experience the other day at work with regards to systems complexity that I wanted to reflect on more thoroughly.

A discovery was made that an end consumer was seeing a faulty value of an entity that my team is responsible for. Or in plainer terms, a web href-value was wrong that my team owned the implementation code for.

The most straightforward (pragmatic?) option could have been to simply update the value at the very fringe, closest to the user in terms of a react presentation component that translated into the site javascript and html. Luckily (?) for us, the system was slightly (or very much) more complicated than that.

The react component of course had no knowledge whatsoever of the underlying domain object it was presenting. As we like to say in the business, you want dumb kids so that you can pass them any crap and they’ll take it at face value (not to be confused with parenting, in which case I hold a very opposite stance). So that was out of the question. The next feasible candidate would be in the translation layer in the web service. Typescript code fetching from a backend service that could potentially override the value and get the correct href passed down to the presentation component and thus the client. But I have a strong urge to resist code that looks like

let value = fetchFrom(someService);
if (value === someSuperSpecificIncarnationOfValue) {
  value = mySuperModifiedUltraValue
}
return value

Not that it’s always wrong or bad. But it screams complexity: Why is this changed here and not elsewhere? Why are we only looking for this value and not others? Why is the upstream producer in the wrong? Why would I ever force future me to have to consider 5 different places where this value might change?

So I decided to go one level deeper before surrendering to an inline override. And I went to the upstream consumer (not that hard, since my team owns that service too). I thought I had it, we were defining the value in question in some in-memory map that we could easily change. But I was wrong. Our value was actually coming from another source system. And now we were starting to move towards the fringes of the system setup as I knew it. Outside here be dragons, or in particular, I knew that the point I was now at would most likely lead me to the infamous LEGACY SYSTEM of 25+ years that held everybody and their grandma in constant limbo because of how behemothly complex the system was. Not much luck getting anything out of there alive…

Ok, so maybe it’s worth painting a picture of where we’re actually at

flowchart TD A((fa:fa-user Client)) -->|Get href| B[Web system fa:fa-globe] B --> C[My team's Upstream API] C --> D[fa:fa-truck Primary domain data provider] D -->|exiting domain| E[The Legacy system fa:fa-dragon]

As you can see, the complexity grows quickly, and this is still simply considering that one href value. I thought the battle was lost, but pulled a final hail Mary to look inside the belly (GUI) of the dragon. And there it was! A field that might actually very well mark the source of truth of the value in question, and the admins have altered a different but similar value that didn’t force the main href to be passed as correct, it just looked like it at a first glance in the dragon GUI.

So even though I probably spent 2-3 times as long figuring out the whole chain and identifying the root problem, my future self is also extremely happy since the old adage of “code will be read x times more than written” arguably still holds true. For today at least.

That was a long rant to a short problem. But I wanted to get the fact that I saved complexity that day off my chest and into the history books. Task completed.