Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A couple recent questions focused on "well designed applications" and "poorly designed applications". Looking at the responses it appears to me that it might be easier to recognize and define poor code and poorly designed applications than it is to define what good code and good/correct application design is. What do you think?

share|improve this question
2  
I think it's just easier to critisize than praise. –  LennyProgrammers Mar 3 '11 at 14:59
add comment

7 Answers

up vote 5 down vote accepted

A classic adage is "A good design is not when there is nothing to add to it, but when there is nothing to take away". I don't remember who said it though, but it is true. A good design is simple and clean, there are no superfluous parts in it, yet it is open to extensions at the same time.

Note that recognizing these traits ultimately requires a deep analysis of the structure of the code. Whereas recognizing some common traits of bad design is easy (think huge classes, long methods, inconsistent / nonexistent naming conventions...). Of course, one might say, it is possible to have code with a great design but poor names, or other code smells. Or bad design but clean, easily readable code. However, our practice has taught us that sloppy or hasty work creates both bad code and bad design, and vice versa: people who create great design also put the same level of effort into most or every detail of their code.

Another factor is that there is so much more bad code and design around than good. So we simply have probability working against us, thus we get more experienced in recognizing and dealing with bad code than with good one (which probably makes us prejudiced as well). And I would tend to think that people working on great code are more likely to stay there for longer time, thus there is less fluctuation in those projects. Which further lessens the chances of stumbling upon such code.

share|improve this answer
4  
"It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove." en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry –  LennyProgrammers Mar 3 '11 at 15:00
    
@Lenny222, thanks for the source reference! –  Péter Török Mar 3 '11 at 15:01
add comment

I think it is more along the lines of we think all software is bad. There is actually a blog about this on Coding Horror. Most software is work for hire and the people doing it fall into in to one of the following buckets as to why they are writing bad software.

  • Unskilled but fakes it well.
  • Is more interested in the MMO he is running on his laptop.
  • Is more interested in his side project then his real job.
  • Burned out and doesn't care anymore they will just change the spec tomorrow.

Now I am not saying all developers are this way. But when the developers are this way you see bad software.

When they are not this way is when you see magic happen.

I will add one more thing to this. Developers will also usually do what is easiest for them in the UI of the program which sometimes makes for a bad UI where the user is concerned.

share|improve this answer
add comment

In general everyone knows what they DONT want to do or be done, so in programming happens the same thing:

Programmers who had suffered bad design problems and had to make it better, understand what things made their work harder so they can see then faster. Also this programmers tend to avoid that code no matter what because they know how hard is to fix it later.

Its a matter of experience i think: More experience, poor design apper faster when analyzing code.

share|improve this answer
add comment

I think you can honestly say you have a good design when there is nothing left to take away from it and it is easy to understand what it does at a glance.

Is it complicated? Refactor into smaller components.

Is code repeating itself? Refactor.

share|improve this answer
add comment

Ideally you should be able to quantify application design/architecture. There are various software engineering statistics ( cyclomatic complexity, cohesion etc) that you use as a measure, these metrics are available using Visual Studio ( i am sure there are other tools for it too)

Application architecture can also be evaulated using various techniques (architecture review boards, ATAM method), one good article can be found in microsoft architecture journal here

share|improve this answer
add comment

I think in part because a well-designed application or database just works without any fanfare, so you hardly notice it. Flaws, on the other hand, are very noticable.

share|improve this answer
add comment

It's easy to spot some bad designs right away. It's tougher to spot the ones that on the surface look good, but aren't. And that's why you can't spot good design... it may not be when you look deeper.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.