Interesting question.

I don't much like playing with MAXDOP as first response to an excess of XCPACKET waits. The optimizer isn't stupid but the default value of Cost Threshold for Parallelism is (or was last time I looked) and it makes sense to adjust that to something sensible first and see if XCPACKET WAIT still happens so frequently as to suggest there's a problem. Only if that doesn't have the desired effect should one play with MAXDOP.

Brent Ozar described it nicely a couple of years ago (www.brentozar.com/archive/2013/08/what-is-the-cxpacket-wait-type-and-how-do-you-reduce-it/[/url]).

I guess if all your quereis are massive data crunchers the above doesn't apply, but even then you will need to keep MAXDOP high enough to get decent response on those massive queries.

I rather like Hugo's comment. Maybe I would express it more forcibly that he did. It is pretty crazy to do performance tuning in an environment that is radically different from the intended production environment, and setting MAXDOP to 1 to do the tuning and having the tuned SQL run with MAXDOP 0 or 16 or whatever is a perfect example of that craziness.