In real life I've seen many projects go wrong because people modularized it in the wrong way -- often connected with a naïve faith in "encapsulation" (Complex bugs, performance problems, and crackers don't respect encapsulation.)
For instance, SOA has had a new lease on life lately, for good reasons. I picked up a system that had four layers involved with doing a request; each of these layers had different serialization/deserialization logic (two submodules) and at least one submodule that would actually do the work.
Debugging a problem in the system often involved a wild goose chase across 12 submodules and often changing something simple (like adding a new data field) would require all 12 modules to be changed.
Even if you have a good batting average and you manage to make these changes right 90% of the time it's close to certain that making a change to that system would create a new bug.
The underlying social problem isn't that "people want to do things quickly", it's that people don't see simplicity as a virtue and don't see complexity as a problem. If they valued speed, they'd pursue simplicity because you can make changes much more quickly in a simple system.
> you can make changes much more quickly in a simple system.
IME: Doing N features hackishly takes O(n^2) time; Doing them properly takes O(2n). The problem is when management sees a project as a series of several n=1 tasks, instead of one n=n project.
Thank you for the detailed commentary. Fighting for simplicity is rough because the virtue doesn't always have a champion, while every new complexity increasing function has one. At my last firm, every feature had management committee sponsorship. Simplicity? A dirty word.
Like Dexen says, the surprise is in the non-linearity. The sudden transition from a sparsely connected to a widely connected system comes somewhat unexpected (at least to me :-) ).
