@TotherAlistair) August 1, 2014
I don't intend to argue Alistair's contention one way or the other, but I invite you to set aside some time to read David Parnas' paper "On the Criteria To Be Used in Decomposing Systems into Modules", which I have embedded in this article. Do not let yourself be put off by the quaint-sounding title. If you prefer, think of it as titled "The Essence of Modularity".
I care about this paper because I strive for modularity in designing software systems and I find that programmers routinely lose sight of both the what modularity offers them and what it means. I value modularity as a way to drive down the cost of changing software. I value that because most of what we do as programmers consists of changing software, and so it strikes me as a sensible place to economise.
If you can't take the time to read the whole paper now, then let me direct you to a particularly salient part of the conclusion.
We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
Enjoy the paper. In case the embedded viewer doesn't work for you: click here.