“In computer programming, orthogonality means that operations change just one thing without affecting others.”
— “Compactness and Orthogonality”. www.catb.org
Maybe you’re familiar with the concept of orthogonality. Maybe you’re not. Either, way I find that an example is often just the thing for me when it comes to solidifying a concept.
I was recently working on a fairly challenging Agile story, and as part of that, I built a function that took in an optional ‘options’ object. I was finding that under certain circumstances I wanted to log information to the user, and other times I didn’t want to log that information from that function.
So, I created the options object and had the function check for the log property on options. If it was true I went ahead and changed the database and logged the change to the user. If it wasn’t true, I didn’t change the database and didn’t log anything to the user.
Simple right? Except I violated the rule of orthogonality, and didn’t even realize that I’d violated it until a few days later as I was in the middle of debugging my function.
My initial assumption was that if I logged, I also needed to update the database. If I didn’t log, I didn’t need to update the database.
Unfortunately, I promptly found myself in a situation where I needed to update the database without logging, and then proceeded to tie myself in knots trying to satisfy that need without changing my underlying assumption.
Ultimately, I did what I should have done from the start. I started checking for two properties on my options object. Log and update. Like magic, my problems went away.
Imagine that. 🙂