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.