How to motivate adaptive an shifting class access modifiers

Question

At the new client, we had a discussion regarding access modifiers for classes, methods, members etc. One opinion was to keep things as private as possible, only allowing for protected (internal, public) level when necessary. The opposite opinion was to "let things flow" and apply public access level throughout all (or at the very least most) of the classes.

The argument for the former is to prevent misusage by malicious and/or ignorant developers. Also, a general just-in-case precaution.

The argument for the latter is the ease of usage powered by trust for other developers skills and intentions.

The classes in this particular case will be used internally within the company (or maybe even more limitedly, within the division or the team). Still, it's interesting if that's a sufficiently strong argument to support omitting the usual approach of least necessary accessibility.

Without advocating one view or the other (although I do have a strong and clear opinion on the subject), I'd like to get feed-back from other developers in this matter. (The experience and efficiency level of the team, are left out intentionally, since I regard all our members as technically competent).

As I realize it might be unclear what situation I'm talking about, I'd like to emphasize the following. One of the team's members raised the point that under certain circumstances, such as trusted and skilled teammates, localized usage, responsible and competent use cases etc., there's no advantage to follow the convention, whereas the disadvantage is the restraint on productivity. Under the conditions the member referred to, there's no gain to fetch by following decoupling, SOLID etc. However, I wonder if that's a sufficiently strong argument to allow omission of the design principles (in such cases) or if we should respect the conventions in any circumstances, just in case.

Answer 1

It is a red herring to turn it into a question of "trust" or "competency". Access modifiers are a question of encapsulation, and encapsulation is a tool to manage complexity. You want encapsulation regardless of the level of skill of the developers.

It is not like there is a certain skill level above which you don't need to use good development practices like encapsulation, separation of concerns and on. Rather it is the other way around, that skilled developers know how to use these principles, which is why they are more productive than novices.

Note: If you have malicious developers you are in big trouble, and no amount of access modifiers will help you. Access modifiers is not a security measure. In languages like Java or C# you can still call private methods through reflection, and in Python it is no more than a naming convention.