In general, the answer typically involves formal specification and formal methods that check the code against these specifications, combined with testing and coding standards that result in analysable code.
The explicit separation of hypothesis generation and argumentation / evaluation of alternatives is good advice.
It's also helpful to take an iterated "2 pass approach" the argumentation/evaluation phase: first have everyone state their arguments, then isolate the important criteria upon which the proposed alternatives truly differ (e.g., team familiarity, fitness to application area) and try to establish how these are related and make sure these criteria are related to the end goal (e.g., quality product delivered on time and at cost). Then throw out any arguments that aren't related to the most salient criteria and iterate. This is a useful decision making process even when you're arguing with yourself.
However, divorcing advocate from advocacy is not always a good idea because it assumes everyone in the room has the same set of experiences. This is never the case; people often suggest a particular solution precisely because they understand that solution (or a proposed alternative) well enough to have an experience-backed opinion; others in the room might not have the same experience, and so are unlikely to make the same arguments for/against a solution as other team members.
In general, the problem isn't argumentation. Argumentation, broadly defined, will hopefully always happen whenever two mutually exclusive options are on the table. It is unavoidable unless you're willing to engineer by coin flip. The problem is ego and lack of respect and empathy.
When team members respect and have empathy for one another, argumentation won't lead to these problems. Similarly, a lack of respect and empathy or an inflated ego cannot be solved by mediation of particular arguments; it's a larger issue that should be dealt with on its own terms.
In general, the answer typically involves formal specification and formal methods that check the code against these specifications, combined with testing and coding standards that result in analysable code.
More references:
https://www.cs.umd.edu/~mvz/cmsc630/clarke96formal.pdf
http://research.microsoft.com/en-us/um/people/lamport/tla/fo...