What is the first thing that you think of when you think about good software design? Extensibility? Interface programming? Loose coupling? Simplicity? TDD? Everyone has an opinion on what makes a good software design, may it be a thorough use of design patterns, conforming to coding standards, or just easy to understand… everyone has an opinion. It’s not hard to find lists of good elements. Just Google for it and you might come up with this list:

10. Considers the Sophistication of the Team that Will Implement It
9. Uniformly Distributes Responsibility and Intelligence
8. Is Expressed in a Precise Design Language
7. Selects Appropriate Implementation Mechanisms
6. Is Robustly Documented
5. Eliminates Duplication
4. Is Internally Consistent and Unsurprising
3. Exhibits Maximum Cohesion and Minimum Coupling
2. Is as Simple as Current and Foreseeable Constraints will Allow
1. Provides the Necessary Functionality

We all want to create good designs… something elegant and beautiful yet works perfectly. It should be easily understandable, or maybe diligently complex (hey, some people just like complex designs). Either way, whatever good design is, we want it.

But how about bad design? We seem to always know it when we see it (usually because it’s any design other than our own) and can immediately point out each area that is “incorrect”. But what are the real characteristics of bad design? What is something that you definitely do not want in your design?

How about Rigidity?

Is your software difficult to change? Does one change in one class in one module result in a cascade of changes throughout the class, throughout the module or even throughout the application? If modifying your application even minimally becomes an enormous task, you might have a rigid design.

Is your design Fragile?

We aren’t talking about the leg lamp here. We’re talking about design that breaks easily and often. Does making another small change in one component break something in another component? Do unexpected parts break when making unrelated bug fixes? Well then it just might be fra-gi-le.

Is it as Immobile as that car on blocks down the street?

Have you written some classes for your application that are banished to be stuck there forever? Are they coupled tighter than those two weird kids at prom? If so, your code is immobile my friend.

How Viscous is it? I said viscous, not vicious.

Do you write code that makes it easy to do the right things and difficult to do the wrong things or is it much easier to cut and paste the same thing a million times rather than reuse the original code?

Is it Complex just for the heck of it?

Is your code complex just to prove how smart you are? Or maybe to secure your job at Initrode so that the new class of freshouts can’t steal it away? Or maybe because you just don’t know any better? Well, that’s needless complexity at its best.

Does it Repeat, Repeat, Repeat, and then Repeat some more?

Is your motto “copy and paste away”? Have you ever realized that one of your for loops needs an extra check and then shed a tear when you realize that you need to make that same change in 42 other files? Did you skip over the DRY design principle when cramming for your software design exam in college? If so, then you’re bound to repeat your mistakes in life… as well as in your code.

Is it and by that I mean Opaque?

Can no one else understand you code? Does everyone groan when they have fix bugs in your old code? Do you groan when you have fix bugs in your old code? Your code may just be opaque then.

There are many ways to design a software system; some are good and many, many more are bad. Next time you design anything, whether it be a complete system, an application or just a component, make sure you smellcheck it and deodorize if necessary.