I’ve been thinking a lot lately about backwards compatibility.
“Back-compat”, as we web-geeks often call it, is the idea that when you update software it doesn’t “break” things in unexpected ways. For example, if you update something on your website it doesn’t all-of-a-sudden make things look or behave differently on the website.
It’s a fine line. After all, updates are supposed to change the way things work. Patching up security changes the way it works (hackers don’t get through anymore). Adding features changes things. Refactoring for code performance is a change. Ideally, these changes happen “under the hood” and, if users notice anything, it’s something they’ll count as a benefit: “Wow! My website loads way faster now!”
Sometimes, though, changes result in unexpected and unwanted side-effects: “Ever since I installed this update, the fonts on my site are different. I liked the old ones better, and want them back.”
On some occasions, breaking backwards compatibility can’t be helped. A legacy feature was nice, but it opened a critical vulnerability, or it blocked further development of something even more useful.
Good software minimizes those occasions. Every change reflects both what is necessary to make the software more secure, performant, and useful and the end user’s expectations based on past experience with the software.
As a software developer, I tend to spend a lot of time thinking about how to write great (clean, performant, secure) code. But what makes great software is not just the code, it’s the experience of what the code does in the eyes of the end user. Most of the time, I’m working with software that’s already in use somewhere. That means writing great software is not just writing great code. It means putting myself in the end user’s shoes and experiencing what the code does. What change will I see when I upgrade? Will I like it, or wish I could go back to the old version?
It’s tempting (because it’s much easier) to hack away at it and tell myself, “If I were writing this from scratch, I’d do it this way. It’s better. It’s easier to make the machine do this. Users want and do all kinds of crazy things you don’t expect. They should do it the way I want.”
The truth is, yes, users want and do unexpected things that may seem crazy, and maybe are not good for them. As a software user, I do too. And the truth is great software can handle all that crazy, keep its users safe even from themselves, and even teach them gently what’s a better way to get what they really want.
Once I walk a mile in my end users’ shoes, then I can go back to the code and consider how to write it better. If I’m doing development well, I can clean up this mess, extend this functionality, make it go faster, and do it in a way that my end users can trust that the only surprises will be: “Oh, wow! That’s so much better now!”