Good Design

Someone asked me on a phone interview how I recognize a good software design. I think I managed to mumble some kind of response after blabbering a bunch of “uuh” and “aah”. I didn’t get the job, obviously, but since then I’ve never put the question to rest. It kept hunting me, distracting me like an annoying fruit fly that just won’t go away.

So I put a lot of thought into this and managed to get only as far as realizing that the following are signs that you have a good design:

• The code is readable. By reading it, you can extract knowledge from it with a minimum of effort.
• The code is reusable.
• The code is easy to change.
• The code is succinct and to the point.

Maybe I need to call the guy up again and tell him all of this. “Hey, it took me a month, but here’s what I think is essential in a good design!” Sure, it all looks like common sense. But that also means it is pretty rare. I find it incredibly hard to live up to those four intuitive guidelines. Sometimes I even forget that they exist!

Finally, I got my feelings validated a day or two ago when I read a blog post that mentioned the four qualities of BAD design (I apologize, but I can’t find that post anymore!):

• rigidity
• fragility
• immobility
• viscosity

Rigidity means your code is hard to change. Fragility means a change will break everything. Immobility means your code isn’t reusable. Finally, viscosity means that your stuff is hard to read and understand.

Wow, that’s exactly what I was thinking about! Now let’s get to work and apply all of this on a daily basis, shall we?