Are there any heuristic methods out there used to figure out if there are flaws in a design? Or is it pretty much a subjective skill that comes with experience? Often I see engineers go for the first design that comes to their head and then adjust according to the results, this gets the job done, but it's time consuming. I'd like to know what the gurus at SO think.
A:
We normally do a review, that the person making the design must present it to other architects, and they get to try and poke holes in the design.
A fun way to do it, which also teaches the team how the system is supposed to work, is to:
- Divide the system into layers / modules
- Each person on the team is assigned a module (hat with a name)
- Then try and do things (use cases), say login a message (piece of paper) with the username and password is given to john (the UI) which gives it to James (the business layer) ....
You cannot do this for everything, it would take too long. But if something is overly complicated it should show up here, or if someone gets a message an says "I do not know what to do with this" it is an indication that something is missing.
On the technical side, if it is technology that we have not used before, we will build a proof of concept of a thin vertical of the system. This also serves as an example to the coders of how to program the system.
Shiraz Bhaiji
2009-08-05 17:17:10
A:
Use cases are your friend. They help you figure out where all the data needs to live, and what messages need to be passed between modules. If you see too much data is being passed, it may be time to redraw the boundaries of your modules.
Prototyping is also helpful. It's coding but it's usually throwaway. This is another good way to catch the gotchas that you missed. These tend to be more technical issues that you've overlooked in your model... threading issues, IO issues, data structure choices.
patros
2009-08-05 17:31:34
To evaluate a design I'd rather go with the name "tracer bullet" insstead of prototype as a lot of people think "UI-prototype" and a UI-Prototype will rather not evaluate your application design.
pmr
2009-08-05 17:36:29
+2
A:
Personally, I often use Alloy to gain more confidence in my designs - here's an article on it (and other tools of its kind) that describes it pretty well. Not all people believe in this stuff and it's certainly not for everyone, but it has helped me each time I touched it and even when I don't use it knowing how it would analyze my stuff helps.
Part of design is indeed some subjective skill I think. I always try to reduce the concepts in a design to a minimum. I prefer to write a simple, minimal core and put one (or two) layers on top that map concepts to the underlying layer. Sometimes there's more than one minimum set. Whether the right choice was made is usually not clear until people walk up with new requirements that you didn't think of in the original design. Then I like to think back whether it would have been easier or more difficult to add if I'd chosen the other minimum set. Recent projects indicate that I slowly get a good feeling for this :).
So yes, I guess experience matters. I don't think you can get really good at design until you've made quite a few mistakes.
I really like the suggestion with the presentation of the design. I had often thought about this in the past. I think you really need a good understanding of the design if you want to present it to others (at least, in a way so that everybody understands what you're about to do).
Rüdiger Hanke
2009-08-05 17:46:12
A:
I'd say no, no real methods, it's something that comes with experience.
The problem with early peer review is you end up optimizing the wrong problem.
You optimize for a problem as far as you understand it, and then the business comes along and changes the requirements on you. You end up wasting that expensive review resource.
Beth
2009-08-05 17:49:23