No, hacks do not necessarily follow lack of privacy. Over time, I have found that people tend to hack when: 1 - They can't do something 'the right way' because

No, hacks do not necessarily follow lack of privacy. Over time, I have found that people tend to hack when: 1 - They can't do something 'the right way' because the contract won't let them. 2 - They don't know how to do something 'the right way' because the contract is insufficiently documented (or worse, outdated). 3 - They prefer 'the first way' to 'the right way' (in a rush, not give a damn, etc). To avoid 1) you need to have created an absolutely rock solid design that covers all use cases. To avoid 2), your documentation must be excellent. To avoid 3), there must be 'only one way'. Unless you comply with all of the above, and can also prevent the ability to copy& paste / duplicate your code, you perfectly hidden internals will not save your project from someone who wants to write dirty code. In fact, hidden internals only really help with 3) there. But, hey, they may not prevent all of it, but at least they will help reduce it, right? Maybe not. In practice, hen programmers don't have the mental safety net of hidden internals, my perception is that they tend to produce simpler designs, with lower amount of state and lower amount of dependencies among pieces of that state. Which in turn tend to improve the situation against 1,2 and 3 above.