I wonder how much the software state of the art is advanced by software developers as opposed to software maintainers. When you are working to refactor softwar

I wonder how much the software state of the art is advanced by software developers as opposed to software maintainers. When you are working to refactor software written by others, things like "private methods" are a gift. If you are trying to refactor some piece of code, you only have to make sure that the callers within the said class are modified to guarantee that the codebase is not broken. I don't think a lot of people understand that maintainers in the real world do not have the time to read and understand every line of your code. And the toughest part of doing software maintenance is figuring out how much you can safely ignore. I feel qualifiers like "private" were designed to help with this problem. I also severely dislike the architecture proposed by the author with loosely coupled services talking over a socket. This style of code is only maintainable if you understand the entire system inside and out. For example, lets say the maintainer receives a ticket that says 'Report X has wrong data'. She will start investigation with the question : 'Why does it have wrong data ?'. She will walk back up the call tree looking for why and eventually learn that the data coming off the socket is wrong and that is where the trail ends (unless there is a document describing who is responsible for putting said data there). I have faced this issue in real life. I can understand when this style of decoupling is necessary to improve modularity, but it does not have a positive maintenance impact.