How to recognize a wrong from a correct design ?

Question

I am discussing with a friend about design. He proposes a solution, and I propose a different one. My feeling is that we are both right, it's just a matter of "preferring blue to green" but I was wondering if you know good strategies to distinguish between a good and a bad design, provided that they both solve the issue. Simplicity is not a criterion, because is in the eye of the beholder. In our case, I advocate my design as the simplest, and he does the same for his own, just because each of our brains developed its own path and is now comfortable with the found solution.

Answer 1

Usually, a good design can be referenced to general design rules, depending if it's UI design, database design, etc.

If both your design follow design guidelines/rules, then they both can be good.

Answer 2

Do the equivalent of hallway usability testing - explain both designs to random people, and attempt to gauge how easily graspable each one is to them. Then compare the results.

That is of course, a highly subjective measure. You would probably be better off just agreeing to disagree.

Answer 3

My personal opinion is that there can be many "correct" designs, but sometimes depending on how things evolve, one may be more correct than another. Some things to consider:

• Which design is more readable/understandable?
• Which design is more testable?
• Which design is more flexible/more easily refactored in the future?
• Which design is more extensible to include possible future scenarios? (although be wary of falling into the over engineering trap)

Answer 4

I would disagree with your assumption that "simplicity is in the eye of the beholder". There are many methods of establishing how simple a piece of code is. Cyclomatic complexity is a well-established metric written decades ago, as well as Halstead Volume, and more recent metrics like "maintainability index" are proving to be useful tools.

Perhaps instead of dismissing simplicity, you could use it to win your argument ;)

Answer 5

There are some pretty widely used quality factors that you can use to focus your conversation. "Better" is vague.

Simpler is well-defined. It's not a preference, or an eye-of-the-beholder item. It's a simple metric.

Here's a set of quality attributes you can use to evaluate a design.

http://www.softwarearchitectures.com/go/Discipline/DesigningArchitecture/QualityAttributes/tabid/64/Default.aspx

http://my.safaribooksonline.com/9780470031469/a%5Ftaxonomy%5Fof%5Fquality%5Fattributes

http://www.clarrus.com/documents/Software%20Quality%20Attributes.pdf

http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr021.95.pdf

Answer 6

Write down all your "use cases" and at the very least, make sure that each design meets the minimum requirements. If possible, start writing some of the implementation, and try to envision the extension points and see which design is more flexible.

If both designs meet all the requirements, a great test for simplicity is to have the other developer write code to leverage your design. If you think your design is elegant, but the code to interface it starts to get really messy, it's probably not as simple and elegant as you originally thought.