This week I had to write some glue code to introduce a new feature on some existing endpoints while trying to maintain as much as the old behavior as in order to reduce friction with existing clients.

As I coded, I iterated on it trying to reduce and find ways to make it simpler. The validation needed to now take two paths and write some code to detect the new or the old thing.

Then, I needed find certain type of items on the JSON payload, if they existed, another branch opened to treat them in a special way, but only if the format was the old one, and so on.

At the end, I was unhappy with my code and the number of IF statements it had, I kept thinking, I could make this a class and have more readable methods, I could make two classes and inherit from one to code only what's different. I could split this into more functions... but at the end it was ways of obfuscating the complexity that I was unable to reduce.

I find myself a bit frustrated when code ends up like this, and I can't help to ask, if I was a more seasoned developer would I make this simpler, how would someone else approach this? did I start something utterly wrong by making this a function to begin with? Maybe I didn't analyze this correctly from the get go...

But then, I find some comfort that what I needed to do was to express a complex reality of life. We have a complicated compatibility scenario, and explaining it to another person in prose would also require an IF here and there in your sentences, then it is natural that I also cover those branches in code. The problem is not so much my code (although of course can be improved) but the complex soup we're swimming in in real life. Were the business rules simpler without special cases, surely the code would be several lines shorter.