There is a cost to everything-private, which is that downstream consumers of your software hate you because now they have to get PRs merged for every little thing that you didn't anticipate. Actually it probably makes the problem worse because we're just going to patch your shit and access the private fields anyway.<p>The functional programming and especially the data driven schools of thought tackle the same problem more elegantly.
The author talks about a piece of software as if it were a closed system, where disorder would inevitably increase. This is not the case, disorder in software can be decreased by doing work. However, the business requirements will inevitably become more complex over time, and there will come a point where the cost of adaptation of the software is higher than the cost of starting over with a design that better accomodates the current requirements. Inability to adapt is observed in ageing organisms also.
> <i>In the attempt to make this move, the first step will be to find all the places in the code-base that make use of this public property and fix those so that they don’t do this anymore. If the tooling around the project is amazing, there will be some static code analysis to use; but most will end up having to grep the entire code-base </i><p>Isn't "find all usages" a pretty basic feature in modern IDEs? If you're working in a single self-contained codebase this really isn't very hard to do.<p>IMO a lot of the teaching around best practices in OO programming doesnt differentiate enough between things that matter in authoring libraries versus self-contained proprietary code. When everyone is committing to the same repo certain types of encapsulation and abstraction aren't always as critical as they're made out to be.
This is a real thing, not an analogy to physics, called Technical Debt<p><a href="https://en.wikipedia.org/wiki/Technical_debt" rel="nofollow">https://en.wikipedia.org/wiki/Technical_debt</a>