There is a gray area between Software Engineering & Code Review regarding design reviews.

Code Review's on-topic page explicitly calls out design reviews as off-topic.

However, if your question is not about a particular piece of code and instead is a generally applicable question about …

  • Higher-level architecture and design of software systems

From our on-topic page:

Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. If you have a question about...

  • requirements, architecture, and design

It would appear that a design review is on-topic.

But it fails the applicability to programmers in general test, as a design review is essentially too localized.

Please make sure your question uniquely applies to programmers in general

Note: this verbiage was removed since this question was asked

Why do I ask?

Is this proper OO design for C++?

Was recently asked, and in the body of the question it was stated:

From what I've read, design review is on-topic for this site (and off-topic for the Code Review site).

So I'm opening it up here in Meta so we can hash out whether or not design review questions are on-topic for the site.

up vote 19 down vote accepted

I think that, generally, design review type questions are on-topic. However, the problem is how broad they are. My concern for this type of question is that most of them may be more suited to a discussion environment. I do think that there are good design review questions, but they need to be clear and specific and not soliciting general feedback. Specifically, in the question you linked to, this section has me most concerned over its viability:

I'm looking for a general review of my OO design, use of UML, and use of C++ features. I especially just want to know if I'm doing anything considerably wrong.


Any sort of feedback is greatly appreciated. Thanks for reading this.

I would expect a good design review question to focus on a particular aspect of the design (or the representation of the design, which would also be valid). I'm not sure this particular question does that well. But it's not off-topic, just too broad or unclear.

Borrowing from gnat's answer (which borrows from the guidelines used at Code Review):

Does your question contain design? Design should be embedded in the body of the post and not linked to. Design notation should be explained to ensure that it is well understood, especially if non-standard notations are used. Design should contain text, images and diagrams, and perhaps some examples of code if necessary.

Do you want the design to be good design, (i.e. not design-golfing, obfuscation, or similar)? We are practical people on Software Engineering, and many of us are professional software developers. We answer questions in the context of building production-ready systems that are understandable, maintainable, and meet other functional and quality requirements.

To the best of your knowledge, does the design work? Your design should at least be functional. You may be seeking input on improving your design, or perhaps correcting issues that are preventing you from achieving your quality requirements (such as performance or testability). However, your design should work and achieve the functional requirements of what you are building.

Have you identified specific areas of concern in your design? Simply dropping in a functional design with details isn't sufficient. What aspects of your design need improving? Are you having trouble testing your design (at any level of testing)? Is your design not performing as well as it should or needs to (and in what ways is it under performing)? Are you having trouble scaling your design? You should come with a small number of specific problems that you are trying to get resolved.

If you answered yes to all the above questions, your question is on-topic for design review at Software Engineering.

  • 6
    I think that most (all?) questions that get presented as a design review will be too broad. When you have got it narrowed down far enough, I believe that it will no longer be regarded as a review by the asker. – Bart van Ingen Schenau Mar 3 '14 at 13:47
  • 2
    @BartvanIngenSchenau That may be a true statement. I think that point is that asking about your design is on-topic, but it otherwise needs to meet the other characteristics of good questions (such as not being too broad and providing sufficient information to reduce the valid answer space). – Thomas Owens Mar 3 '14 at 13:49
  • 1
    "My concern for this type of question is that most of them may be more suited to a discussion environment." I agree wholeheartedly. So, where is this discussion environment? – Kirby L. Wallace May 15 '17 at 22:10

I prefer to use "and-clause" borrowed and slightly rephrased from Codereview.SE

  1. Does my question contain design? (Please include the design in the question, not a link to it)
  2. Did I write that design?
  3. Is it actual design from a project rather than pseudo-design or example design?
  4. Do I want the design to be good design, (i.e. not design-golfing, obfuscation, or similar)
  5. To the best of my knowledge, does the design work?
  6. Do I want feedback about any or all facets of the design?

If you answered yes to all the above questions, your question is on-topic for design review at Software Engineering.

Per my reading, question in question passed above clause.

On a more general note, blindly letting questions pass based on bare stamp "design review" wouldn't be a good idea, because there would be no way to verify research effort.

Otherwise, one could just thoughtlessly glue some buzzwords and see how it sticks: "I am considering SOA+ORM+responsive Web UI, any thoughts?" I for one would vote close braindumps like this as unclear what help you need.

Worth noting that, as pointed in comments, #6 may be interpreted as too broad, that is, focusing on specific design concern(s) would be safer.

  • 3
    My only concern is #5 and how that could lead to many answers, none of which can be objectively scored. – Thomas Owens Mar 3 '14 at 15:09
  • 1
    @ThomasOwens good catch, I need to think a bit more about this. First thing that comes to mind is to rephrase "Do I want feedback about any or all facets of the design?" to something like "What facets of my design I want feedback about?" – gnat Mar 3 '14 at 15:26
  • 2
    I guess I do have another concern. #3, given the CC-BY-SA license that SE requires when content is posted here. If you post a design that is too detailed, there could be implications. I disagree that CR requires actual project code, and I don't think we should, either. Our guidance should be 1, 2, 4, and 6. – Thomas Owens Dec 3 '15 at 13:51
  • 1
    @ThomasOwens good catch. #3 is tricky indeed – gnat Dec 3 '15 at 17:50
  • 2
    Design-golfing? Is that a thing? – Simon Forsberg Jun 25 '17 at 11:01
  • within a guidance as clarified by Thomas in top answer golfing is unlikely @SimonForsberg - nor it looks possible with my draft. I think proper golfing requires "objective primary winning criterion, so that it is possible to indisputably decide which entry should win" and we don't have that – gnat Jun 25 '17 at 11:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .