If your meeting absolutely positively must happen on a known weekly no-meeting day then there's really only three cases I can see:
1. You are bad at planning
2. You are bad at communicating
3. Something really, really bad happened and people will understand breaking policy
There's a big difference between "no meetings ever" and this.
Sadly there is a particular type of person who discovers the day that nobody is supposed to go to meetings is the day when everybody is free and the meeting rooms are available. And then starts scheduling meetings for that day.
This is the same kind of person who discovers that people, and rooms, are "available" from 12-1pm, and 6pm-
After too many days of back-to-back meetings from 10am to 3pm I've taken to creating a repeating lunchtime meeting with myself. Then I discovered the people who don't care if you're available or not...they consider themselves important enough that you'll drop everything for their meeting.
All meetings are optional - it just depends what you're prepared to pay for missing them.
In this case, I'd say there's no/negligible cost to missing the meetings on a no-meeting day, unless the entire group of people have decided that it is worth breaking the no-meeting rule. Of course, you should let people know that you won't be there in advance...
Engineers typically go the other way though: always write email and never meet. Then they wonder why their project goes south because the specs are incomplete or the users aren't happy.
I think it's largely a knee-jerk reaction against bad meetings - hour long no-point crapfests - but they don't have to be like that.
Agreed. On my team at Kabam, we have meetings, but
1) They are as small as possible, typically including just 2 or 3 people.
2) Are always optional.
3) Typically last around 15 minutes.
It helps to have plenty of space/rooms where you can just pull someone aside to hash out a quick issue, and a mature, responsible team that doesn't need baby sitting to get stuff done.
I want to take on of your points and go on a bit of a tangent about meetings. Specifically, this one: "They are as small as possible, typically including just 2 or 3 people."
I think everybody's goal should be to make meetings as small as possible. If you don't know why everybody there is there, then either they're redundant, superfluous, or lost.
One thing I like to stress in my meetings that I run is that everybody knows why they are there. Even if that's just to listen. Too often, people think that because they were invited to a meeting, they need to say something. This is what generates hour-long bullshit meetings. Sometimes, you just need them to shut up, listen, and take notes.
I've found that if, when you set the meeting, you send a note to them after the invite with, "Hey, I know you're busy, but I'd like you to listen in on this so you understand what's being discussed. I'll get your feedback on it after the meeting." Works wonders and keeps meetings short.
Some meetings useful, even helpful. But holding a useful meeting is not easy, which means there are many bad meetings. And that's what we should all avoid. Not meetings all together, but bad meetings.
I've been to great meetings that were facilitated well and had clear, productive goals. Those we should keep. And fortunately, when meetings are productive, there don't need to be as many of them.
But those hour long no-point crapfests, yea, no one needs those.
I haven't found a strict ordering, though, for which is better at tougher issues. Sometimes face-to-face is much quicker, especially if it's hashing out high-level disagreements or overcoming misunderstandings about motivations and general directions. Sometimes for architecture or deciding on features or cuts as well. But when arguing more complex technical points, I prefer LKML-style discussion, where you intersperse code and text, and have time to properly research a serious reply.
