I have had the case where I wrote an immutable class and then later someone modified it so that a few of the properies were no longer immutable. That developer

I have had the case where I wrote an immutable class and then later someone modified it so that a few of the properies were no longer immutable. That developer then complained that his changes broke a bunch of unit tests and that perhaps we shouldn't write immutable classes because they are too fragile and make it difficult to reason about and use the class in code. I disagreed with his view, but his view was no less true than my own. We had completely conflicting and incompatible coding philosophies. This made me think about something(and perhaps it is a horrible analogy), but how would you play a game of chess if every few moves you had to let someone else make your move for you? Would the strategies that worked and allowed you to win by yourself in the past start to fail with this new constraint? Would you have to abandon certain types of plays or would you spend your time cursing the Gods because the other players couldn't see your strategy nor you theirs (even if you tried to discuss it)? Or perhaps you would realize that the problem is that chess is simply not a game that is meant to be played this way. In the end, we had more success using clearly defined boundaries and trust rather than a collaborative process based on overlapping responsibilities and communication. I'm not making a universal claim, I'm just telling my story.