You need to explain what is unique about software development: that as a software developer you need uninterrupted time.
Software development requires holding many pieces of a complex puzzle in your head all at once. It's enormously challenging to assemble all those pieces. As a developer, once you've got those pieces together, then you're furiously trying to solve the problem while you can still keep it in your head and have the clear insight. If you interrupt a developer while they're in that state, then you're forcing them to think about something else, which drives all of that out of their head, and they're back to square zero. Even if it's just a 5-minute interruption, when you walk out, it can take them a quarter hour or more to recover where they were and get back into the same mental state.
Have you ever noticed how developers, once they get into the flow, often seem immersed in some fugue where they don't notice the outside world for hours on end? Maybe your favorite developer emerges 6 hours later, looking a bit dazed. Do you know why that happens? It's because of the flow state. Getting into that flow state isn't easy, but once you're in it, you lose track of the outside world.
For this reason, it's not the number of meetings that matter. It's the effect it has on the amount of uninterrupted time that developers have.
You can still have meetings without undue negative effect on a developer's productivity, if the meetings are scheduled very carefully. For instance, if you make Monday "meeting day" and schedule all meetings on Monday, then Monday becomes basically a write-off for software development, but at least the developer still has four other days a week for productive work: 80% productivity. On the other hand, if you schedule two meetings a day, one at 10:30-11:00am every day and another at 2:30-3:00pm every day, that's about the worst torture you could do to a software developer. Sure, it's only 5 hours of meetings a week -- but you've just killed any hope of having a prolonged uninterrupted period where one can focus on software development. That's deadly for productivity.
Finally, I'll note that this phenomenom is somewhat specific to software development. It doesn't apply to most managers or business folks. That may be one reason why many managers are unfamiliar with this issue or why it may not occur to them without prompting.
You know your manager best, so you will know best how to communicate with your manager. What you don't want to do is come off as whining, or trying to avoid meetings because you hate meetings (yes, we all hate meetings, but your manager has probably scheduled them for a reason). Instead, you want to emphasize that your interests are aligned. It's about helping you to be more productive: something your manager probably cares a lot about. Then, if your manager steps up to the plate by helping you get more uninterrupted time, you need to deliver: you need to actually be more productive. If you do it right, everyone walks away happier.
For more, see the following:
The Joel Test: 12 Steps to Better Code, 8. Do programmers have quiet working conditions? - Here Joel explains why it is so important for developers to have private offices and quiet places to work without interruptions. It's because interruptions kill productivity, for software developers.
Where do These People Get Their (Unoriginal) Ideas? - Joel talks about why it's so important to be able to get into the flow and stay in the flow.
Getting Things Done When You're Only a Grunt, Strategy 5 Get Away From Interruptions - Here Joel is giving advice to fellow developers about how to avoid interruptions. (The hidden subtext, which Joel doesn't need to explain, is why avoiding interruptions is so critical to productivity, for software developers.)
A Nerd in a Cave - Rands talks about his "nerd cave", which is just a fancy way of saying a comfortable place that helps him get into the flow state and stay there.
Meet the Life Hackers - This talks about productivity and the cost of interruptions. It quotes a claim that, when someone is interrupted, it takes 25 minutes to get back to the original task. That's for non-developers; I expect it'll be higher for software developers.
P.S. If you want to get advanced, read Rands in Repose on meetings. But that's an advanced topic, for later.