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?
closed as primarily opinion-based by durron597, Dan Pichelman, user40980, user53019, user22815 Jul 4 '15 at 17:11
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
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.
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.
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.
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.
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
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.
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.