What Questions To Ask?
-
Hi Everyone, So I'm stumbling my way through trying to design a system that I'm working on, and I realized that just as there are patterns that are often talked about in OO design there appears to be common questions asked when thinking through and validating the design. At this point, I'm not exactly sure what they all are, but it seems I'm asking the same questions over and over in order to make sure my design works. So... what questions do you ask yourself when reviewing a design?
-
Hi Everyone, So I'm stumbling my way through trying to design a system that I'm working on, and I realized that just as there are patterns that are often talked about in OO design there appears to be common questions asked when thinking through and validating the design. At this point, I'm not exactly sure what they all are, but it seems I'm asking the same questions over and over in order to make sure my design works. So... what questions do you ask yourself when reviewing a design?
I generally ask questions like: What problem is this attempting to solve? Does it solve it? What other ways could this be done? Are they easier or a better fit? Is it necessary, or are we just adding fluff? Is this maintainable? And the questions to ask at the end: What's missing? How do we accept this (what are the acceptance criteria)?
Deja View - the feeling that you've seen this post before.
-
Hi Everyone, So I'm stumbling my way through trying to design a system that I'm working on, and I realized that just as there are patterns that are often talked about in OO design there appears to be common questions asked when thinking through and validating the design. At this point, I'm not exactly sure what they all are, but it seems I'm asking the same questions over and over in order to make sure my design works. So... what questions do you ask yourself when reviewing a design?
Along the lines of what Pete posted you can look at the Agile and RUP[^] analysis to see those and more considerations along with suggested timing of when questions need to be asked and asked again. Be sure to check out the links in that page, it's just a starting point.
led mike
-
I generally ask questions like: What problem is this attempting to solve? Does it solve it? What other ways could this be done? Are they easier or a better fit? Is it necessary, or are we just adding fluff? Is this maintainable? And the questions to ask at the end: What's missing? How do we accept this (what are the acceptance criteria)?
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
I generally ask questions like: What problem is this attempting to solve? Does it solve it? What other ways could this be done? Are they easier or a better fit? Is it necessary, or are we just adding fluff? Is this maintainable? And the questions to ask at the end: What's missing? How do we accept this (what are the acceptance criteria)?
And the question after the question at the end: What's for lunch?
-
Hi Everyone, So I'm stumbling my way through trying to design a system that I'm working on, and I realized that just as there are patterns that are often talked about in OO design there appears to be common questions asked when thinking through and validating the design. At this point, I'm not exactly sure what they all are, but it seems I'm asking the same questions over and over in order to make sure my design works. So... what questions do you ask yourself when reviewing a design?
Does it satisfy the requirements of a good user interface (assuming it ultimately leads to software someone uses and not a machine or other software). I tend to think about the requirements and the user experience first, even mock up a UI on paper. Try to eliminate as much work or complexity on the part of the user as possible so that the user can focus on accomplishing *tasks* rather than manipulating data. Once I have that decided the rest is easy because it simply has to meet the criteria of satisfying the task oriented design decisions. If you start from the bottom up on the other hand then you are faced with uncertainty at every level and ultimately could end up with a very computer programmer oriented design but not a user friendly design. (i.e. the end user get's exposed too much to the inner workings of tables and databases and how the computer and software works instead of simply being able to view it as a machine that helps them accomplish the tasks they already know and understand). This is the essential pivot point between what users percieve as "good" software and what users perceive as "bad" software.
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying." - David Ogilvy