A "Bad Design" ???

You might have presented plenty of software design for peer review and the peer might have certainly asked you this question: “Why’d you do it that way?” and also might have told you this: “That’s not the way I would have done it”. 

Well, this has happened to me, and I am sure it might have happened to many other engineers out-there. Everyone has their own criteria for defining what is a "Bad Design", that one may agree or may not agree, but all will agree that any software that full-fills it's requirement but has following three traits has a "Bad Design":

• Rigidity -  It is hard to change because every change affects too many other parts of the system. A design is called rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules.
• Fragility - When you make a change, unexpected parts of the system break. Fragility is the tendency of a program to break in many places when a single change is made. Simple changes to one part of the application lead to failures in other parts that appear to be completely unrelated. 
• Immobility -  It is hard to reuse in another application because it cannot be disentangled from the current application. A design is immobile when the desirable parts of the design are highly dependent upon other details that are not desired. 

Basically, the inter-dependency between modules makes a design rigid, fragile and immobile.

Well, we can say that,  it would be difficult to demonstrate that a piece of software that exhibits none of the above traits (i.e. it is flexible, robust, and reusable) and that also full-fills all its requirements, has a bad design. Thus, we can use these three traits as a way to decide if a design is “Good” or “Bad”.