With regard to project management, your typical progress chart connects tasks according to dependencies. By merging two modules into one, you introduce a connection for code that has nothing to do with the thing which precedes it in the dependency chart. In project management, this is one example of a pathological connection. Or at least that is how I remember it from 40+ years ago when I was a department manager and actually had to diddle with progress charts and topological sorting.
Say you are building modules to do text parsing and the boss says, "Include the routines for linear regression support in that parser module." Later in the schedule, one form depends on regression. Another form depends on text parsing. But now in that schedule, two forms depend on the same something that is only partly involved with either. If you had kept the regression and parsing routines in separate modules and allowed them to have their own independent start/end dates, the regression form would not have depended on parsing code, which it doesn't use anyway.
The problem, of course, is that when you create that double-barreled dependency, BOTH forms suddenly align to the same start time, and necessarily, one of those two forms now has a later start time than it should have. Therefore, collapsing the number of modules to contain the same number of function/sub entry points can introduce delays that shouldn't be present. And of course, splitting the dependencies means you should have kept the modules split, too. Because it is a project no-no to say "project point X now depends on half of a routine being finished."
