Despite the title, this blog post is actually about when not to go against the grain.
BATEMAN: In '87, Huey released this; Fore!, their most accomplished album. I think their undisputed masterpiece is "Hip To Be Square". A song so catchy, most people probably don't listen to the lyrics. But they should, because it's not just about the pleasures of conformity and the importance of trends. It's also a personal statement about the band itself.
Let me set the stage:
Our monolith rails app is 7-ish years old. That's old enough to drink in code years. I've been asked to create a new kind of user that isn't tied to any particular client.
Do I...
- Prepare myself for some shotgun surgery and find every instance of
user.client? - Go with the grain and maintain the expectation that all users have clients?
Well, since I am not a smart man, I went with option 1 first. It'll be so much more elegant, I told myself.
Narrator: It wasn't.
The problem with creating a user that doesn't have a client when all the code written in the past 7-ish years expects a a user-client relationship is that it breaks everywhere and it breaks all at once. I found myself debugging authentication, background data processing jobs, front-end bugs...
I went down this path for a few days, thinking if I stomped out all the bugs I could merge my "elegant" solution. Luckily a much more wise engineer stepped in and imparted some wise words about the pleasures of conformity.
In order to add this functionality (and to not have to regression test the entire application) I needed to find a solution that operated within the bounds set by years and years of expectations. It would be so very unnecessarily disruptive to change a fundamental expectation to our application, like users having clients.
And that's okay.
Yes, as software engineers it is a virtue for our objects to be as loosely tied together as possible. However, for most of the life span of the application (and it got us this far) users having clients and vice versa was not very likely to change. For most of the life span of the application, writing code that would break if that expectation changed was totally fine.
At this point it was up to me to determine if I wanted to rebel against the expectations and shoulder the responsibility of changing years of code, or did I want to write my code with the grain of the application.
It wasn't that hard of a choice.
I used to be a renegade, I used to fool around
But I couldn't take the punishment and had to settle down
-Huey Lewis and the News, Hip to Be Square
Top comments (0)