Monolithic Design?

Nice definition of MonolithicDesign taken from  http://c2.com/cgi/wiki?MonolithicDesign :

Characteristics of MonolithicDesign:

• Functionality implemented by part of the system cannot be reused without using the entire system.
• To make one part of the system work, other parts must be "tricked" by using them, even if they aren't logically needed. (For example, you might need to "pump" a file reader, even if your data is coming from another source.)
• Initialization of the system may be tricky or laborious.
• Change to the control flow is impossible.
• The only escape from MonolithicDesign is to spend months refactoring and rewriting the system into independent modules.

Factors leading to MonolithicDesign:

• A bad sense of aesthetics. (This above all.)
• Procrastination of refactoring.
• Premature optimization, especially a tendency to performance perfectionism or Puritanism.
• Not writing for reuse.
• Tunnel vision or attachment that limits your vision to one architecture, one flow paradigm, one memory management technique, etc.

How to prevent MonolithicDesign:

• Code for survivability, not optimal fit. The more perfectly something is adapted to its environment, the less it can tolerate change in that environment. When you find yourself expending insane effort to maintain a perfectly static environment for your perfectly adapted code, you are probably dealing with MonolithicDesign. When you write modules that can be used independently from each other in varying architectural contexts, you are protected from MonolithicDesign.
• Refactor often, and focus on eliminating dependencies. Examine the relevance of every module that you are forced to use.
• Take advantage of opportunities to work with a variety of paradigms and techniques, so that you learn to recognize and eliminate unnecessary limitations in module functionality.
• Practice proactive laziness; i.e., expand your vocabulary, not just your repertoire. Developer 1 writes a program that must perform task X. Developer 1 writes the program and says, "Now I know how to write programs that do X;" he has expanded his repertoire. Developer 2 writes a program that must perform task X. Developer 2 writes a module to do task X, uses it in his program, and says, "Now I have a module that does X." Developer 2 has expanded his vocabulary, because now he can accomplish X by invoking the name of his module. When developer 1 needs to write a new program that does X, he will be tempted to tack the functionality onto his first program, bloating and complicating that program and starting the trend toward MonolithicDesign.
• ReduceCoupling