I was listening to someone at Microsoft talk about their product recently. I can't disclose which one it was, but lots of people use this product and are impacted by changes. The particular thing that caught my attention was that the presenter noted there was a breaking change in the new version for some people. This wasn't a huge change or one that would affect a lot of people, but it was a breaking change for a few.

Another attendee asked this question: I would tend to do xxx instead of what you showed, so why would you do this?

It wasn't an antagonistic question, but more curiosity. However, it was a good question since any changes that cause breakage can be disruptive to other people. The thing I noticed was that the questioner's frame of reference was completely different than the presenter's. The questioner couldn't imagine writing code in this way.

As I work with more and more customers, I find that many of them get tunnel vision in that they approach their work or code in one of a few ways and don't think widely about other approaches. In general, I think that's a good way to work as we ought to use patterns and avoid anti-patterns in our work. The more we all code in a similar structure and style with the same patterns, the easier it is for any person to maintain the codebase (or infrastructure).

Of course, we have to be willing to add new patterns when we find them and drop older patterns that no longer work (and perhaps refactor the code). That's another hard thing for humans to do. We rarely want to let go of patterns and who has time for refactoring?

At Microsoft, they have to consider lots of different ways to look at code. I saw awhile back one of them writing that building Windows was like ordering pizza for a billion people. You'll never get it perfect and someone will always be upset. I get that. I couldn't imagine making changes to something like Windows, where every little thing upsets some group of people and sometimes those are a very loud minority.

Many of us approach the world in similar ways, and we can appreciate or understand small differences. When we meet someone who sees things very differently, then it becomes hard to reconcile their view with our own. In code, this often means we want to use different patterns than others, which creates a less maintainable codebase.

Communication continues to be one of the hardest parts of building software (and most endeavors). Part of our communication should be to try and understand others' points of view, get them to understand ours, and come to a shared understanding of how to approach problems. That shared understanding is what helps us build better teams.